From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPEpU-00068J-J9 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:31:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPEpP-00067O-WD for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:31:34 -0500 Received: from [199.232.76.173] (port=34264 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPEpO-000678-R3 for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:31:31 -0500 Received: from cerberus.snarc.org ([212.85.155.21]:48341) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPEpO-0003jG-AN for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:31:30 -0500 Date: Tue, 20 Jan 2009 11:35:17 +0000 From: Vincent Hanquez Subject: Re: [Qemu-devel] [PATCH v3] Stop VM on ENOSPC error. Message-ID: <20090120113517.GA384@snarc.org> References: <20090118110509.GG11299@redhat.com> <18804.27240.886522.337700@mariner.uk.xensource.com> <4974A704.3070605@codemonkey.ws> <18804.46780.936806.748045@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18804.46780.936806.748045@mariner.uk.xensource.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 Mon, Jan 19, 2009 at 05:22:04PM +0000, Ian Jackson wrote: > The theoretical reason is that a guest is in a better postion to deal > with the situation because it knows its access patterns. Often the > response to a failing write in a mission-critical system will be some > kind a fallback behaviour, which is likely to work. Stopping the VM > unconditionally is not something that the guest can cope with. The guest isn't in a better position to do something here. In a first place, the guest see a "hardware" disk of size X, that the host is providing. the host need to do what is necessary to provide it (or at least try to). the guest has absolutely no idea about the fact this harddisk isn't a true harddisk or that it should be treated specially (expecting ENOSPC at any point). > But in the Xen context, a Xen VM is not a `task' in the same way. > (Xen users make much less use of the built-in cow formats for this > reason, often preferring LVM snapshots or even deeper storage magic.) > We expect the VM to be up and stay up and if it can't continue it > needs to fail or crash. That's *your* opinion. as long as there's a mechanism to notify the management part, so that it can try to do something, pausing the VM seems sensible to me. -- Vincent