[libvirt] [PATCH V1 1/4] Add support for QEMU -add-fd support detection

[Daniel P. Berrange]

On Wed, Jan 30, 2013 at 09:39:25AM -0700, Eric Blake wrote:
> On 01/29/2013 05:16 PM, Stefan Berger wrote:
> > On 01/29/2013 06:24 PM, Eric Blake wrote:
> >> On 01/29/2013 09:52 AM, Stefan Berger wrote:
> >>
> >>> Index: libvirt/src/qemu/qemu_capabilities.h
> >>> ===================================================================
> >>> --- libvirt.orig/src/qemu/qemu_capabilities.h
> >>> +++ libvirt/src/qemu/qemu_capabilities.h
> >>> @@ -165,6 +165,7 @@ enum qemuCapsFlags {
> >>>       QEMU_CAPS_SCLP_S390          = 124, /* -device sclp* */
> >>>       QEMU_CAPS_DEVICE_USB_SERIAL  = 125, /* -device usb-serial */
> >>>       QEMU_CAPS_DEVICE_USB_NET     = 126, /* -device usb-net */
> >>> +    QEMU_CAPS_ADD_FD             = 127, /* -add-fd */
> >> Okay, so you are taking the approach that we insist on command line
> >> support (qemu 1.3), not just the QMP command existing (qemu 1.2).  It's
> >> easy to probe whether 'add-fd' QMP exists (query-command), but harder to
> >> determine if command line support is present when using just QMP with
> >> the current state of qemu.
> >>
> > Would you then not use -add-fd on the command line but hotplug those
> > devices instead?
> 
> We have two options:
> 
> 1. Try to support both qemu 1.2 and qemu 1.3.  For qemu 1.3, we can use
> the command line (which feels simpler to me), but for qemu 1.2 we would
> have to do everything through QMP.  This means that we'd have to write
> code that does not attach _any_ -drive arguments, and instead start
> 'qemu -s', hotplug all the drives, and then start the domain.  But if we
> can get things working for 1.2 via hotplug only, then there is no need
> to use the command line for 1.3 - use a single interface for it all.
> This method is easy to probe - does the 'add-fd' QMP command exist in
> 'query-commands'?
> 
> 2. Not support fd passing unless targeting qemu 1.3 or newer.  When
> targeting 1.2 and older, use the command line as always, and state that
> qemu will use open() and the user has to use virt_use_nfs.  With 1.3,
> use -add-fd on the command line, so that we don't have to worry about
> hot-plugging disks after 'qemu -s' on initial start; we'd still have to
> wire up QMP command support for hotplug, but at least we don't have to
> refactor the command line computation into delaying things to hotplug.
> Since there is no 'query-config-schema' command in 1.3, we'll have to
> hack in some other capability check; for this I have two ideas: a)
> straight version check (if 'query-version' reports 1.3 or newer, assume
> -add-fd exists); this does not backport well.  b) during the initial QMP
> probes, if 'add-fd' exists, try calling 'add-fd' with a specified
> fdset-id argument and /dev/null as an fd; qemu 1.2 will reject the call
> (in that version, qemu insisted on managing set ids itself; you could
> only pass fdset-id when adding to an existing set); qemu 1.3 and later
> will accept it (the management app libvirt can choose its own allocation
> pattern for set ids).
> 
> I'm leaning towards 2b, so I'll code that up as part of my QMP work.

I vote for 2nd option - do not try to support QEMU 1.2.

Effectively QEMU 1.2 is just 50% of the solution - QEMU 1.3 is the first
place where you have 100% of the solution. While you might be able to
hack around the limitations of QEMU 1.2, this is effectively dead-end
work - it is easier just to tell people to upgrade to newer QEMU.


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 :|