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

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140404/21020296/attachment-0001.sig>