Re: [Qemu-devel] [PATCH v3] Stop VM on ENOSPC error.

[Gerd Hoffmann <kraxel@redhat.com>]

Ian Jackson wrote:
> Anthony Liguori writes ("Re: [Qemu-devel] [PATCH v3] Stop VM on ENOSPC error."):
>> Ian Jackson wrote:
>>> Once again, this feature should be optional.
>> Why?
> 
> Well, three reasons, one general and theoretical, and two practical
> and rather Xen-specific.
> 
> 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 fundamental issue is that you can't signal ENOSPC to the guest via
IDE protocol because that is an error condition which simply can't
happen on real hardware.  You can only signal EIO, which is something
very different, and the OS likely goes into "Oops, disk broken" mode.
Which probably isn't what you want here ...

It might make sense to signal ENOSPC to the guest with a paravirtual
disk.  Then the guest knows what really happened has at least the chance
to do something more reasonable in response, although I suspect most of
the guests out there today wouldn't.

> 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.)

With LVM volumes as storage you shouldn't run into ENOSPC error
conditions in the first place, and the patch should be a no-op for you.

cheers,
  Gerd