On 04/04/2014 11:47 PM, Eric Blake wrote:
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.
I had no idea there was so much backporting =).
Acknowledged. Will have to get a patch upstream to fix this - there is
currently no (current) method in the migration capabilities to conditionally
enable them depending on the existence of a particular feature.
I'll have to cook something up with a #define which only makes the
capability visible if the feature was compiled in.....
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list