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.
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
Attachments:
- signature.asc (application/pgp-signature — 604 bytes)