From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IBQk7-00082m-D9 for qemu-devel@nongnu.org; Thu, 19 Jul 2007 03:48:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IBQk5-00082a-K4 for qemu-devel@nongnu.org; Thu, 19 Jul 2007 03:48:10 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IBQk5-00082X-GY for qemu-devel@nongnu.org; Thu, 19 Jul 2007 03:48:09 -0400 Received: from trojan.mobilesoft.com.au ([203.222.155.155] helo=mail02.main.mobilesoft.com.au) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IBQk4-0001AY-RV for qemu-devel@nongnu.org; Thu, 19 Jul 2007 03:48:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C9D6.00E38B13" Content-class: urn:content-classes:message Subject: Re: [Qemu-devel] Crash: When Host HDD is full Date: Thu, 19 Jul 2007 17:25:43 +1000 Message-ID: <1184829943.19246.14.camel@sphinx> In-Reply-To: <7fac565a0707121339x6bec00ddpcb31f7943ce698ab@mail.gmail.com> References: <7fac565a0707110819k635d398fl273d8d5a0afd2d3f@mail.gmail.com> <200707120807.41162.mikeonthecomputer@gmail.com> <4696530A.2010000@qumranet.com> <20070712162236.GE20008@redhat.com> <7fac565a0707121339x6bec00ddpcb31f7943ce698ab@mail.gmail.com> From: "Adam Bolte" 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C9D6.00E38B13 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>From a usability perspective, I also would expect this to be the = correct behaviour. Non-technical users using, say, Windows (in full-screen mode) on a GNU/Linux desktop need to know that their HDD is full and they must free up space - not have the guest complain about cryptic HDD errors and failed writes (assuming the guest OS can even be trusted to do this). Pausing the VM and notifying the user of no free host storage space is also the same behaviour as other virtualization products, so this might already be the expected behaviour from the user's POV. At the very least, I feel a switch to enable this behaviour would be appropriate. -Adam On Thu, 2007-07-12 at 23:39 +0300, Alexey Eremenko wrote: > Pause VMs is the only realistic option. This is the correct option, > because it ensures that guest is still alive. > Other options might crash the guest, like Windows BSOD. Worse yet is > that guest may think that it's hard disk is bad, and will start > marking it's sectors as bad-blocks. >=20 > When the VM is paused, the user may take action to free some disk > space and unpause guest manually. >=20 ------_=_NextPart_001_01C7C9D6.00E38B13 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Qemu-devel] Crash: When Host HDD is full

>From a usability perspective, I also would expect = this to be the correct
behaviour. Non-technical users using, say, Windows (in full-screen = mode)
on a GNU/Linux desktop need to know that their HDD is full and they = must
free up space - not have the guest complain about cryptic HDD errors = and
failed writes (assuming the guest OS can even be trusted to do = this).

Pausing the VM and notifying the user of no free host storage space = is
also the same behaviour as other virtualization products, so this = might
already be the expected behaviour from the user's POV.

At the very least, I feel a switch to enable this behaviour would be
appropriate.

-Adam


On Thu, 2007-07-12 at 23:39 +0300, Alexey Eremenko wrote:
> Pause VMs is the only realistic option. This is the correct = option,
> because it ensures that guest is still alive.
>  Other options might crash the guest, like Windows BSOD. Worse = yet is
> that guest may think that it's hard disk is bad, and will start
> marking it's sectors as bad-blocks.
>
> When the VM is paused, the user may take action to free some = disk
> space and unpause guest manually.
>

------_=_NextPart_001_01C7C9D6.00E38B13--