From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRvcw-0002aC-JO for qemu-devel@nongnu.org; Wed, 20 Feb 2008 15:33:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRvcu-0002Vg-IK for qemu-devel@nongnu.org; Wed, 20 Feb 2008 15:33:13 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRvcu-0002VJ-8q for qemu-devel@nongnu.org; Wed, 20 Feb 2008 15:33:12 -0500 Received: from [64.218.2.170] (helo=ox.hobi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRvct-0005Q7-RF for qemu-devel@nongnu.org; Wed, 20 Feb 2008 15:33:12 -0500 Received: from ricklap (adsl-68-23-60-237.dsl.chcgil.ameritech.net [68.23.60.237]) by ox.hobi.com (Postfix) with ESMTP id E79F6E4D for ; Wed, 20 Feb 2008 13:55:50 -0600 (CST) From: Rick Vernam Subject: Re: [Qemu-devel] [PATCH] bdrv_flush error handling Date: Wed, 20 Feb 2008 13:55:48 -0600 References: <18364.19722.241175.337829@mariner.uk.xensource.com> <20080220182252.GH14209@redhat.com> <47BC790D.40409@codemonkey.ws> In-Reply-To: <47BC790D.40409@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802201355.48502.rickv@hobi.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wednesday 20 February 2008 01:01:33 pm Anthony Liguori wrote: > 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. agreed. > > Regards, > > Anthony Liguori > > > Shooting it dead on any I/O error doesn't give the host admin any choices > > at all > > > > Dan.