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@xxxxxxxxx>
---
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list