[libvirt] [PATCH 2/6] Added public API to enable post-copy migration
Cristian KLEIN
cristian.klein at cs.umu.se
Thu Sep 25 12:54:02 UTC 2014
On 2014-09-25 14:21, Jiri Denemark wrote:
> On Thu, Sep 25, 2014 at 11:42:16 +0200, Cristian KLEIN wrote:
>> On 2014-09-24 14:32, Jiri Denemark wrote:
>>> On Tue, Sep 23, 2014 at 16:09:57 +0200, Cristian Klein wrote:
>>>> Added a new `libvirt` migration flag `VIR_MIGRATE_POSTCOPY` and the
>>>> necessary code to pass this flag to qemu as migration capability.
>>>>
>>>> Signed-off-by: Cristian Klein <cristian.klein at cs.umu.se>
>>>> ---
>>>> include/libvirt/libvirt.h.in | 1 +
>>>> src/libvirt.c | 7 +++++++
>>>> src/qemu/qemu_migration.c | 43 +++++++++++++++++++++++++++++++++++++++++++
>>>> src/qemu/qemu_migration.h | 3 ++-
>>>> 4 files changed, 53 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
>>>> index 6371b7b..bdc33c6 100644
>>>> --- a/include/libvirt/libvirt.h.in
>>>> +++ b/include/libvirt/libvirt.h.in
>>>> @@ -1225,6 +1225,7 @@ typedef enum {
>>>> VIR_MIGRATE_ABORT_ON_ERROR = (1 << 12), /* abort migration on I/O errors happened during migration */
>>>> VIR_MIGRATE_AUTO_CONVERGE = (1 << 13), /* force convergence */
>>>> VIR_MIGRATE_RDMA_PIN_ALL = (1 << 14), /* RDMA memory pinning */
>>>> + VIR_MIGRATE_POSTCOPY = (1 << 15), /* enable (but don't start) post-copy */
>>>> } virDomainMigrateFlags;
>
> In my first review, I forgot to mention that I think another flag
> requesting post-copy to be started right away (instead of waiting for
> virDomainMigrateStartPostCopy to be called) could be useful too.
I'm a bit reluctant to include such a flag. Since qemu does not offer
such a mechanism, it would feel like we are implementing a policy in
libvirt.
> ...
>>>> @@ -3580,6 +3619,10 @@ qemuMigrationRun(virQEMUDriverPtr driver,
>>>> if (flags & VIR_MIGRATE_RDMA_PIN_ALL &&
>>>> qemuMigrationSetPinAll(driver, vm,
>>>> QEMU_ASYNC_JOB_MIGRATION_OUT) < 0)
>>>> +
>>>> + if (flags & VIR_MIGRATE_POSTCOPY &&
>>>> + qemuMigrationSetPostCopy(driver, vm,
>>>> + QEMU_ASYNC_JOB_MIGRATION_OUT) < 0)
>>>> goto cleanup;
>>>>
>>>> if (qemuDomainObjEnterMonitorAsync(driver, vm,
>>>
>>> I'd expect similar thing would need to be done in the Prepare phase on
>>> destination... However, if destination does not need to set the
>>> capability, we at least need to check if destination QEMU supports it
>>> and report failure from Prepare if it doesn't. And the
>>> QEMU_ASYNC_JOB_MIGRATION_IN branch in qemuMigrationSetPostCopy would be
>>> unreachable in that case.
>>
>> It's up to the source qemu (through the migration protocol) to activate
>> post-copy on the destination qemu. So there are no other steps to be
>> done on the source.
>>
>> I have mixed feelings about having libvirt check the necessary
>> capability on the destination. Personally, I would prefer qemu to return
>> an error like "post-copy unavailable" when the "migrate" command is
>> issued, as there might be more factors that influence the availability
>> of post-copy. For example, it's not sufficient for the destination qemu
>> to support post-copy, but the destination kernel also needs userfault
>> support.
>
> Yeah, it won't catch all cases, but will at least fail early when
> someone tries to enable post-copy migration while migrating to a host
> with older QEMU that does not support it.
>
> Moreover, if QEMU is smart enough to check if post-copy migration can
> actually be used when the migration capability is set, we could catch
> even cases when userfault is not supported on the destination.
Okey, I'll add code for that too.
--
Cristian Klein, PhD
Post-doc @ Umeå Universitet
http://www8.cs.umu.se/~cklein
More information about the libvir-list
mailing list