10:49 a.m.
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(a)ucsd.edu 858-822-0711 University of California, San Diego
2:59 p.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
5:32 p.m.
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 :|
5:48 p.m.
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
3:25 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
С уважением,
Роман Шишнёв,
CTO | ActiveCloud | http://www.active.by
Т +375 17 2 911 511 доб. 308 | rommer(a)active.by
Облачные решения | Серверы и инфраструктура | IaaS | SaaS | Хостинг
4741
days inactive
4760
days old
4 comments
4 participants
participants (4)
-
Adam Tilghman -
Daniel P. Berrange -
Eric Blake -
Rommer