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.
