Re: [libvirt] [RFC PATCH v2 2/3] qemu: RDMA migration support using 'rdma' URI

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.