From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRuCg-00085h-PQ for qemu-devel@nongnu.org; Wed, 20 Feb 2008 14:02:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRuCf-00085P-E9 for qemu-devel@nongnu.org; Wed, 20 Feb 2008 14:02:02 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRuCf-00085M-9F for qemu-devel@nongnu.org; Wed, 20 Feb 2008 14:02:01 -0500 Received: from wx-out-0506.google.com ([66.249.82.235]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRuCe-0000iO-QJ for qemu-devel@nongnu.org; Wed, 20 Feb 2008 14:02:00 -0500 Received: by wx-out-0506.google.com with SMTP id h31so2263107wxd.4 for ; Wed, 20 Feb 2008 11:01:51 -0800 (PST) Message-ID: <47BC790D.40409@codemonkey.ws> Date: Wed, 20 Feb 2008 13:01:33 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] bdrv_flush error handling References: <18364.19722.241175.337829@mariner.uk.xensource.com> <47BC5415.4020102@qumranet.com> <18364.22321.98451.446676@mariner.uk.xensource.com> <200802201646.05521.paul@codesourcery.com> <18364.23313.189546.386460@mariner.uk.xensource.com> <20080220163155.GA5520@shareable.org> <20080220182252.GH14209@redhat.com> In-Reply-To: <20080220182252.GH14209@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: Paul Brook Daniel P. Berrange wrote: > On Wed, Feb 20, 2008 at 04:31:56PM +0000, Jamie Lokier wrote: > >> Ian Jackson wrote: >> >>> Paul Brook writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error handling"): >>> >>>> Disk full is a fundamentally unfriendly situation to be in. There is no good >>>> answer. Reporting errors back to the host has its own set of problems. Many >>>> guest OS effectively just lock up when this occurs. >>>> >>> I think that's fine, surely ? A locked up guest isn't very nice but >>> it's better than a guest shot dead. >>> >> Well, a guest which receives an IDE write error might do things like >> mark parts of the device bad, to avoiding writing to those parts. If >> the guest is running software RAID, for example, it will radically >> change its behaviour in response to those errors. >> >> Sometimes that's what you want, but sometimes it is really unwanted. >> If the host runs out of disk space, ideally you might want to suspend >> the guest until you can free up host disk space (or move to another >> host), then resume the guest, perhaps manually. >> >> Is savevm-upon-disk-full a realistic prospect? >> > > In the 'out of disk space' scenario you wouldn't need to save the guest - merely > stop its CPU. This gives the host admin the opportunity to hot-add storage > to the host & then resume execution, or to kill the VM, or to free enough > space to save the VM to disk / live migrate it to another host. > I agree. Stopping the CPUs and spitting out a big fat warning message would be the best thing to do. For the average user, this would give the opportunity to free up some space if possible. Regards, Anthony Liguori > Shooting it dead on any I/O error doesn't give the host admin any choices > at all > > Dan. >