[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] blktap, qdisk, xl cd-eject, and xencommons

On Tue, 2013-04-30 at 13:27 +0100, George Dunlap wrote:
> On 04/30/2013 11:21 AM, Ian Campbell wrote:
> > On Tue, 2013-04-30 at 11:02 +0100, George Dunlap wrote:
> >> The second is problems with xl cd-insert and eject, initially reported
> >> by Fabio Fantoni, and then (accidentally) reproduced by me.  The
> >> problem turns out to be libxl using blktap for cdroms.  Basically,
> >> AFAICT, the whole cd-insert cd-eject thing completely doen't work if
> >> blktap is used to provide it; and it's not a simple fix.
> >
> > cd-insert/eject are suppose to operate on emulated CDROM, which blktap
> > simply isn't in a position to provide, even if it was capable of doing
> > so. So this is certainly wrong IMHO at some level.
> >
> > All emulated disks have a PV counterpart. Many (all?) PVHVM drivers
> > choose not to unplug the emulated CDROM and use it in preference to the
> > PV version (since this way they get proper media change events etc) but
> > I don't think they are required to behave like this.
> >
> > In principal it's not wrong to provide the PV face of a device from a
> > different backend to the emulated one (e.g. we do blkback+qdisk all the
> > time for disks), but in the interests of simplicity it seems like the
> > obvious thing to do is to unconditionally use qdisk for both faces of an
> > HVM guest's CDROM.
> Right -- so I guess from a release perspective the best thing to do 
> would just be to have tools/libxl/libxl_device.c:disk_try_backend() fail 
> for TAP if disk->is_cdrom is true?

Without having consulted the code that Sounds Plausible, yes.

Is the underling problem understood though? In principal PV=blktap
+EMU=qemu should work, is this just some confusion on libxl's side when
reading the xenstore entries? I we sure we can't trigger that confusion
for other uses of blktap -- e.g. disks.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.