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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
С уважением,
Роман Шишнёв,
CTO | ActiveCloud | http://www.active.by
Т +375 17 2 911 511 доб. 308 | rommer@xxxxxxxxx
Облачные решения | Серверы и инфраструктура | IaaS | SaaS | Хостинг
diff -Nru a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
--- a/src/qemu/qemu_process.c 2012-01-03 01:51:55.069333901 +0300
+++ b/src/qemu/qemu_process.c 2012-01-03 05:59:24.195251148 +0300
@@ -2822,10 +2822,26 @@
/* Run an early hook to set-up missing devices */
if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) {
char *xml = virDomainDefFormat(vm->def, 0);
+ char *opt = NULL;
int hookret;
+ if (migrateFrom) {
+ switch (vmop) {
+ case VIR_VM_OP_MIGRATE_IN_START:
+ if (STRPREFIX(migrateFrom, "tcp")) {
+ opt = "migration-target-direct";
+ } else {
+ opt = "migration-target-tunnel";
+ }
+ break;
+ case VIR_VM_OP_RESTORE:
+ opt = "restore";
+ break;
+ }
+ }
+
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, opt, xml);
VIR_FREE(xml);
/*
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list