From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRtfF-0000iK-J4 for qemu-devel@nongnu.org; Wed, 20 Feb 2008 13:27:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRtfD-0000hj-Iy for qemu-devel@nongnu.org; Wed, 20 Feb 2008 13:27:29 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRtfD-0000hg-Cc for qemu-devel@nongnu.org; Wed, 20 Feb 2008 13:27:27 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRtfD-0001Tq-15 for qemu-devel@nongnu.org; Wed, 20 Feb 2008 13:27:27 -0500 Date: Wed, 20 Feb 2008 18:22:52 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] bdrv_flush error handling Message-ID: <20080220182252.GH14209@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080220163155.GA5520@shareable.org> Reply-To: "Daniel P. Berrange" , 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 Cc: Paul Brook 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. Shooting it dead on any I/O error doesn't give the host admin any choices at all Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|