[libvirt] [RFC PATCH 05/30] qemu: block: Extract formatting of props for 'file' backend

[Kevin Wolf]

Am 20.04.2018 um 10:50 hat Peter Krempa geschrieben:
> On Fri, Apr 20, 2018 at 10:41:50 +0200, Kevin Wolf wrote:
> > Am 20.04.2018 um 09:56 hat Peter Krempa geschrieben:
> > > Is there a special need to use 'host_cdrom' explicitly if the CDROM
> > > drive is used? That would complicate things since we don't know when
> > > that will happen.
> > 
> > You don't get the full CD-ROM passthrough functionality with
> > host_device. Specifically, if you eject the virtual drive, the physical
> > drive will only be ejected with host_cdrom, and the same is true for
> > lock_medium.
> > 
> > I think we may also make an attempt at detecting physical media change
> > ocassionally with host_cdrom, but I doubt that this is working reliably
> > anyway (the driver function is .bdrv_is_inserted, so it would be polling
> > rather than processing an event; and I'm not sure when it's called).
> 
> Hmm, okay, it seems that we in fact should use it. Is there any drawback
> if host_cdrom is used with a device which is not a CDROM? (e.g. a
> logical volume containing the image?)
> 
> Basically the question is whether we need to add some "smart" handling
> or we can just assume that if the guest device is a block-backed CDROM
> we can use that.

Hm, looking at the code, it seems that failure is silently ignored in
.bdrv_eject and .bdrv_lock_medium, but .bdrv_is_inserted is implemented
like this:

    ret = ioctl(s->fd, CDROM_DRIVE_STATUS, CDSL_CURRENT);
    return ret == CDS_DISC_OK;

Which probably means that a block device not supporting that ioctl won't
be functional at all because the block layer will return -ENOMEDIUM
almost everywhere.

Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180420/d3e7b0f4/attachment-0001.sig>