Re: [Qemu-devel] To O_EXCL or not to O_EXCL open host_cdrom

[Daniel P. Berrange]

On Fri, Apr 08, 2011 at 12:33:27PM +0100, Stefan Hajnoczi wrote:
> Amit and I were discussing the pros and cons of using O_EXCL to open
> host CD-ROM devices on IRC but this discussion could benefit from more
> input.
> 
> Linux block devices (like /dev/sr0 CD-ROMs) can be opened with O_EXCL
> and only one userspace process will succeed at a time.  This prevents
> programs from interfering with each other.  The polling daemons, hald
> and udisks, use O_EXCL and mount does too.
> 
> Today QEMU does not use O_EXCL and will therefore access host CD-ROMs
> while they are in use by other programs.  This also means that
> programs can be started on the host while QEMU is already running that
> may interfere with the virtual machine's ability to access the CD-ROM
> (for example by ejecting it).
> 
> Therefore, it sounds reasonable to switch to O_EXCL to prevent
> interfering with other programs and to prevent other programs
> interfering with QEMU.
> 
> On the downside, it will no longer be possible to share a host CD-ROM
> between multiple virtual machines or to mount it on host while passing
> it through to a guest.  These scenarios are not safe because on of the
> clients could eject the device, spoiling the party for everyone else.
> However, it is a handy feature for putting installation media into a
> machine and installing several guests at the same time.

Two things strike me here

 - Host CDROM device vs ISO image files have different behaviour
   by default, since they use different internal block drivers.
   If the app wants to share the host CDROM, then perhaps it
   should be force QEMU to access it with the 'raw' block driver
   instead of 'host_cdrom'. Thus "eject" would just result in
   the drive file being closed & filename blanked as for ISOs

 - If the -drive specification has  readonly=on (thus O_RDONLY to
   open(2) call) , I expect QEMU (or the kernel) to forbid the
   "eject" command on the host CDROM. This should prevent two guests
   interfering seriously with each other.

So I think using O_EXCL would be OK, in the case where the block
driver was  host_cdrom and readonly=off.

> The other concern I have about using O_EXCL is that we expose
> ourselves to race conditions if there is ever a need to re-open the
> device.  When QEMU closes its file descriptor another program may be
> scheduled to run and open the device with O_EXCL.  Now QEMU will not
> be able to open the CD-ROM anymore.  From the guest perspective this
> could be at an odd time and we'd have to start failing requests.
> Today we do not re-open host CD-ROMs though so this isn't a pressing
> problem.

Ideally the kernel support would be enhanced such that we don't need to
close & reopen the file, so we can avoid the failure path.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|