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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list