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