On 7/19/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
Regarding the user's point of view described above, I concur that a
switch would be a good compromise. However given that someone using
CVS head is likely to read the mailing list and all other users
upgrading should read the release notes,
Am 19.07.2007 um 09:25 schrieb Adam Bolte:
>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 th
>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
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
On 12/07/07, Daniel P. Berrange <[EMAIL PROTECTED]> wrote:
On Thu, Jul 12, 2007 at 07:12:58PM +0300, Avi Kivity wrote:
> Mike Swanson wrote:
> >On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
> >
> >>Problem 1:
> >>When Host HDD is full, all guests simply crash. Tried with dynamically
>
Paul Brook wrote:
Qemu might freeze the guest when it gets -ENOSPC, and say, retry every
second or wait for user input on the monitor.
Better would IMHO be to report an IO error to the guest and allow that to
decide what to do. If you're bothered about robustness and reliability
then ar
> >> Qemu might freeze the guest when it gets -ENOSPC, and say, retry every
> >> second or wait for user input on the monitor.
> >
> > Better would IMHO be to report an IO error to the guest and allow that to
> > decide what to do. If you're bothered about robustness and reliability
> > then arbitr
Daniel P. Berrange wrote:
On Thu, Jul 12, 2007 at 07:12:58PM +0300, Avi Kivity wrote:
Mike Swanson wrote:
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing .VMDK hard disk.
It sh
Paul Brook wrote:
Besides, most
filesystems reserve some space for the superuser, now unless there's a
cross-platform way to figure out just how much space that is, you'd still
be getting errors despite having 5~10% of the filesystem technically
free.
Qemu might freeze the guest when it g
On Thu, Jul 12, 2007 at 07:12:58PM +0300, Avi Kivity wrote:
> Mike Swanson wrote:
> >On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
> >
> >>Problem 1:
> >>When Host HDD is full, all guests simply crash. Tried with dynamically
> >>growing .VMDK hard disk.
> >>
> >>It shouldn't happen. F
> > Besides, most
> > filesystems reserve some space for the superuser, now unless there's a
> > cross-platform way to figure out just how much space that is, you'd still
> > be getting errors despite having 5~10% of the filesystem technically
> > free.
>
> Qemu might freeze the guest when it gets
Mike Swanson wrote:
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing .VMDK hard disk.
It shouldn't happen. For example, both VirtualPC and VirtualBox pause
all VMs, and gray their displays when
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
> Problem 1:
> When Host HDD is full, all guests simply crash. Tried with dynamically
> growing .VMDK hard disk.
>
> It shouldn't happen. For example, both VirtualPC and VirtualBox pause
> all VMs, and gray their displays when something like
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing .VMDK hard disk.
It shouldn't happen. For example, both VirtualPC and VirtualBox pause
all VMs, and gray their displays when something like that happens.
Host: Fedora 7, 64-bit, Qemu 0.9, AMD Opteron.
Prob
14 matches
Mail list logo
