On 04/04/2014 12:19 AM, Michael R. Hines wrote: >>>> @@ -2561,6 +2570,10 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr >>>> qemuCaps, >>>> if (qemuCaps->version >= 1006000) >>>> virQEMUCapsSet(qemuCaps, QEMU_CAPS_DEVICE_VIDEO_PRIMARY); >>>> + if (qemuCaps->version >= 2000000) >>>> + virQEMUCapsSet(qemuCaps, QEMU_CAPS_MIGRATE_QEMU_RDMA); >>>> + >>>> + >>> And here we need a better check for rdma migration. What if someone >>> compiles QEMU without RDMA support? >> Better than hard-coding it to a version string is to probe the results >> of query-migrate-capabilities and only setting the capability if the >> resulting list includes rdma-pin-all, as that will serve as a reliable >> witness of qemu being new enough to support rdma without an x- prefix. >> > > These comments I don't understand: Why can't we depend on the > version number here? Isn't that what it was designed for? No. Features get backported downstream all the time, to something that ostensibly fails the version number check. For example, RHEL 6 qemu claims to be 0.10, but has backported many features that are much closer to upstream qemu 1.7. Libvirt basing a feature check on a version number will guess wrong if RHEL 7 backports the upstream qemu 2.0 feature to whatever 1.x version of downstream qemu lives in RHEL. Whereas probing for the _feature_ (by calling query-migrate-capabilities and looking for rdma-pin-all) will work for ALL qemu builds, regardless of whether that qemu calls itself 2.0 or not. > > If someone compiles QEMU without RDMA support - why does > libvirt need to know about that? Shouldn't the admin know what their > hardware is capable of - otherwise, if they try to specify > "rdma://hostname" > as a migration option, they will get a failure - which would be the > correct behavior - they tried to do something without verifying > that their hardware was capable of handling it. Getting an error message from qemu about an unsupported option doesn't always read very well - having libvirt query qemu to see if the option is supported, so that libvirt controls the error message when it is not, often leads to a nicer user experience. > > Checking the capability list won't help here either: It will still be in > the list > even if we don't compile QEMU with RDMA support. And if someone > sets the capability anyway, it will just get ignored by QEMU since > RDMA support was not available at compile time. If rdma-pin-all appears in the query-migrate-capabilities output of a qemu binary compiled without RDMA support, that is a bug in qemu, and should be fixed, preferably before qemu 2.0 is out. The whole point of feature detection is to be a reliable way of learning whether the feature is present and supported. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list