Re: [Qemu-devel] [PATCH 3/5] raw-posix: keep complete control of door locking if possible

[Paolo Bonzini]

On 02/10/2012 03:56 PM, Markus Armbruster wrote:
> Paolo Bonzini <address@hidden> writes:
>
> > On 02/10/2012 01:49 PM, Markus Armbruster wrote:
> > > With manage_door off:
> > >
> > > * cdrom_lock_medium() does nothing.  Thus, guest OS operating the
> > >   virtual door lock does not affect the physical door.
> > >
> > > * cdrom_eject() does nothing.  Thus, guest OS moving the virtual tray
> > >   does not affect the physical tray.
> >
> > That's because manage_door off means "we couldn't get O_EXCL to
> > work". udev will affect the physical tray and we cannot really compete
> > with it.
>
> Understood.  I'm just describing behavior to make sure I understand your
> patch, not criticizing it.

Sure, just expanding on the rationale.

> > For virtio-scsi+scsi-block, we definitely want O_EXCL to remove the
> > device from udev and the in-kernel poller.  That's because GESN
> > reports events only once, and we do not want the host and guest to
> > race on receiving events.  But in order to open with O_EXCL we need to
> > unmount (GNOME3 doesn't have an unmount menu item anymore, which is
> > why I did it myself in patch 5/5).
>
> Program A unmounting a filesystem that some unknown program B mounted
> for its own unknown reasons doesn't feel right to me.  Even when program
> B sucks as badly as Gnome appears to do.  Especially when program A does
> it automatically, silently, and without a way to switch it off.

Well, first it's a CD-ROM, so it won't cause data loss.  CD burning 
programs use O_EXCL so QEMU will not stomp on anyone's feet while the CD 
is being written to.

Second, it's the user who asked to use the CD-ROM in a guest.  It makes 
sense to imply he does not want to use it in the host.

Third, if there are open files or such, the unmounting will fail.

And in fact in most cases you won't notice the auto unmounting.  Say 
you're installing a guest (most common case of IDE CD passthrough).  The 
installation program will usually eject the disc before rebooting.  If 
you put it back in after you stop the VM and QEMU has exited, ta-dah, 
the disc will be remounted.

> You've made a good case for why we really, really want managed_door on.
> With managed_door off, both software and humans basically run around
> confused.

Kind of.  In most cases you don't care at all about the tray (for 
example when installing a VM from a "real" disk).  You care about the 
tray if the guest starts using it, for example Anaconda's infamous 
auto-eject after testing media.  Right now sometimes it's hard to 
convince the guest that you actually put the CD back.  But if the tray 
is not managed, you'll never get an auto-eject and you don't have to 
convince anyone about anything.

> Why do we even offer managed_door off then?
> And isn't the automatic, *silent* fallback to the rotten user experience
> of managed_door off a recipe for support calls?

Regarding silence you have a point.  On the other hand, when starting 
via libvirt everything will be silent. :(  This is another point in 
favor of automatic unmounting, which will usually just work.

It may make sense to fail completely if the unmounting fails, but then 
we need to do more effort to grab the disk (e.g. try /bin/umount if 
udisks fails).

Paolo