Re: [Xen-devel] Questions about hvm domU default devices with upstream qemu

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 5 Sep 2013, Fabio Fantoni wrote:
> Il 05/09/2013 16:04, Stefano Stabellini ha scritto:
> > On Thu, 5 Sep 2013, Fabio Fantoni wrote:
> > > > > About qemu default empty and unusable floppy and cdrom I have already
> > > > > reply at
> > > > > start of year that qemu traditional does not have them.
> > > > > The tests were with xl only if I remember good, now I checked also on
> > > > > old
> > > > > production server with xend and qemu traditional. I confirm that hvm
> > > > > domUs
> > > > > is
> > > > > without empty floppy and cdrom also in that case.
> > > > > 
> > > > > cd-insert works (tested with xl and upstream qemu). cd-insert does not
> > > > > works
> > > > > only with qemu default empty cdrom because is undefined on xen side.
> > > > So HVM domUs do NOT have a cdrom drive by default with qemu-traditional.
> > > Exact.
> > > 
> > > > Do they have an empty cdrom drive by default with qemu-xen?
> > > Yes
> > > 
> > > > Is the lack of a cdrom drive the reason why cd-insert doesn't work by
> > > > default (unless you specify an empty cdrom drive in the VM config file)?
> > > Yes.
> > > xl cd-insert command works with cdrom devices already present on domU
> > > defined
> > > on xl file configuration.
> > > The cdrom can be empty or not, the only exception is the empty cdrom added
> > > default by qemu that is not usable with cd-insert because not defined on
> > > xl
> > > file configuration.
> > I see. That should be fixed, by either removing the empty cdrom drive or
> > making it work properly with xl cd-insert.
> > I don't have a strong opinion on this. Given that qemu-traditional
> > doesn't have a cdrom drive by default, it might make sense to do the
> > same on qemu-xen.
> 
> I think the best choice is to remove the qemu default empty cdrom, if possible
> without another workaround as for floppy but considering to change the method
> hvm domUs starts qemu.
> I think that is probably better to add on qemu start command only components
> already defined xen side in order to avoid creation of unusable components
> added by qemu itself or mismatches on both sides.
> 
> Another actual problem is that is difficult to know if the qemu binary that
> should be used on xl create has the features/components requested and if they
> are compiled. Actually on xl create we can have only qemu log file after domU
> create failing.
> Why not expose all features/components of a given qemu binary and let xl or
> other toolstack (not only xen) query them before start qemu itself?

You are right, it would be nice to be able to know exactly what the qemu
binary supports. However it's difficult to do because Linux distros are
free to choose any QEMU version they like and any set of compile time
options they want for qemu-xen.
As a consequence we would actually need to start QEMU and issue QMP
commands to figure out what is supported.  It would slow down VM
creation too much, so we would probably need to do this at host boot
time and store the settings somewhere on disk or on xenstore.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel