[libvirt] PATCH: Inform QEMU "prepare" hook of migration in progress
From: Eric Blake <eblake redhat com> Subject: Re: [libvirt-users] Wanted: method for qemu hook script to know if called for migration Date: Mon, 25 Jul 2011 14:17:08 -0600
As a feature suggestion, it would be nice if that fourth input variable, currently "-", was something like "migrate" in this instance.
Yes, that is probably a bug worth fixing.
I would also find it useful for the QEMU "prepare" hook to be told whether it's being called in the context of a migration. (In our case, we use that hook to manage shared DRBD storage, and only permit Primary/Primary mode in the context of a migration.) The attached 1-line patch supplies the hook with an additional argument "migration-target" when appropriate. Submitted as https://bugzilla.redhat.com/show_bug.cgi?id=768054 --- src/qemu/qemu_process.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 9123f4c..ef9f7eb 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2936,7 +2936,7 @@ int qemuProcessStart(virConnectPtr conn, int hookret; hookret = virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, - VIR_HOOK_QEMU_OP_PREPARE, VIR_HOOK_SUBOP_BEGIN, NULL, xml); + VIR_HOOK_QEMU_OP_PREPARE, VIR_HOOK_SUBOP_BEGIN, migrateFrom ? "migration-target" : NULL, xml); VIR_FREE(xml); /* -- 1.7.1 -- Adam Tilghman Systems Support / Academic Computing & Media Services agt@ucsd.edu 858-822-0711 University of California, San Diego
On 12/15/2011 09:49 AM, Adam Tilghman wrote:
From: Eric Blake <eblake redhat com> Subject: Re: [libvirt-users] Wanted: method for qemu hook script to know if called for migration Date: Mon, 25 Jul 2011 14:17:08 -0600
As a feature suggestion, it would be nice if that fourth input variable, currently "-", was something like "migrate" in this instance.
Yes, that is probably a bug worth fixing.
I would also find it useful for the QEMU "prepare" hook to be told whether it's being called in the context of a migration.
(In our case, we use that hook to manage shared DRBD storage, and only permit Primary/Primary mode in the context of a migration.)
The attached 1-line patch supplies the hook with an additional argument "migration-target" when appropriate.
Submitted as https://bugzilla.redhat.com/show_bug.cgi?id=768054
hookret = virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, - VIR_HOOK_QEMU_OP_PREPARE, VIR_HOOK_SUBOP_BEGIN, NULL, xml); + VIR_HOOK_QEMU_OP_PREPARE, VIR_HOOK_SUBOP_BEGIN, migrateFrom ? "migration-target" : NULL, xml);
The idea is nice, but I don't think it's quite the right implementation. migrateFrom is non-NULL not only for migration, but also for operations like 'virsh restore file' when restoring from a file-based migration stream even though we aren't changing hosts. Rather, we need to thread something through the call chain so that we can tell whether this code was reached from qemu_migrate.c during an actual migration case. In fact, it might be nice to know when 'virsh restore' was in use, separately from migration, separately from a fresh boot, so that we provide more than just '-' or 'migration-target' as the fourth hook argument. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Thu, Dec 15, 2011 at 01:59:06PM -0700, Eric Blake wrote:
On 12/15/2011 09:49 AM, Adam Tilghman wrote:
From: Eric Blake <eblake redhat com> Subject: Re: [libvirt-users] Wanted: method for qemu hook script to know if called for migration Date: Mon, 25 Jul 2011 14:17:08 -0600
As a feature suggestion, it would be nice if that fourth input variable, currently "-", was something like "migrate" in this instance.
Yes, that is probably a bug worth fixing.
I would also find it useful for the QEMU "prepare" hook to be told whether it's being called in the context of a migration.
(In our case, we use that hook to manage shared DRBD storage, and only permit Primary/Primary mode in the context of a migration.)
The attached 1-line patch supplies the hook with an additional argument "migration-target" when appropriate.
Submitted as https://bugzilla.redhat.com/show_bug.cgi?id=768054
hookret = virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, - VIR_HOOK_QEMU_OP_PREPARE, VIR_HOOK_SUBOP_BEGIN, NULL, xml); + VIR_HOOK_QEMU_OP_PREPARE, VIR_HOOK_SUBOP_BEGIN, migrateFrom ? "migration-target" : NULL, xml);
The idea is nice, but I don't think it's quite the right implementation. migrateFrom is non-NULL not only for migration, but also for operations like 'virsh restore file' when restoring from a file-based migration stream even though we aren't changing hosts. Rather, we need to thread something through the call chain so that we can tell whether this code was reached from qemu_migrate.c during an actual migration case. In fact, it might be nice to know when 'virsh restore' was in use, separately from migration, separately from a fresh boot, so that we provide more than just '-' or 'migration-target' as the fourth hook argument.
That information is in fact already passed into qemuProcessStart() via the virDomainRunningReason parameter, one of whose possible values is VIR_DOMAIN_RUNNING_MIGRATED Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Dec 15, 2011 at 11:32:23PM +0000, Daniel P. Berrange wrote:
Rather, we need to thread something through the call chain so that we can tell whether this code was reached from qemu_migrate.c during an actual migration case.
That information is in fact already passed into qemuProcessStart() via the virDomainRunningReason parameter, one of whose possible values is VIR_DOMAIN_RUNNING_MIGRATED
I'll take a stab at a more general solution and get back to the list. -- Adam
Hello, I need this feature too, so I made myself the more general solution. Attached patch sets the fourth argument of the hook to 3 differnent values: "migration-target-direct", "migration-target-tunnel" and "restore". On 12/16/2011 02:48 AM, Adam Tilghman wrote:
On Thu, Dec 15, 2011 at 11:32:23PM +0000, Daniel P. Berrange wrote:
Rather, we need to thread something through the call chain so that we can tell whether this code was reached from qemu_migrate.c during an actual migration case.
That information is in fact already passed into qemuProcessStart() via the virDomainRunningReason parameter, one of whose possible values is VIR_DOMAIN_RUNNING_MIGRATED
I'll take a stab at a more general solution and get back to the list.
-- Adam
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- С уважением, Роман Шишнёв, CTO | ActiveCloud | http://www.active.by Т +375 17 2 911 511 доб. 308 | rommer@active.by Облачные решения | Серверы и инфраструктура | IaaS | SaaS | Хостинг
participants (4)
-
Adam Tilghman -
Daniel P. Berrange -
Eric Blake -
Rommer