[libvirt] [BUGFIX][PATCH] remove saved garbages after persistent migration
From e1e8d5ceb4a9f7c59e20dfb8c168b781435c1613 Mon Sep 17 00:00:00 2001 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Date: Fri, 26 Aug 2011 12:08:11 +0900 Subject: [PATCH] Fix persistent migration config save
When a user migrates a domain by command as libvirt saves vm's domain XML config in destination host after migration. But it saves vm->def. Then, the saved XML contains some garbages. <domain type='kvm' id='50'> ^^^^^^^^ ... <console type='pty' tty='/dev/pts/5'> ^^^^^^^^^^^^^^^^^ Avoid saving unnecessary things by saving persistent vm definition. --- src/qemu/qemu_migration.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index a38c0d9..524b8bf 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2484,11 +2484,12 @@ qemuMigrationFinish(struct qemud_driver *driver, qemuMigrationVPAssociatePortProfiles(vm->def); if (flags & VIR_MIGRATE_PERSIST_DEST) { + virDomainDefPtr vmdef; if (vm->persistent) newVM = 0; vm->persistent = 1; - - if (virDomainSaveConfig(driver->configDir, vm->def) < 0) { + vmdef = virDomainObjGetPersistentDef(driver->caps, vm); + if (virDomainSaveConfig(driver->configDir, vmdef) < 0) { /* Hmpf. Migration was successful, but making it persistent * was not. If we report successful, then when this domain * shuts down, management tools are in for a surprise. On the -- 1.7.4.1
On Fri, Aug 26, 2011 at 12:15:37PM +0900, KAMEZAWA Hiroyuki wrote:
From e1e8d5ceb4a9f7c59e20dfb8c168b781435c1613 Mon Sep 17 00:00:00 2001 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Date: Fri, 26 Aug 2011 12:08:11 +0900 Subject: [PATCH] Fix persistent migration config save
When a user migrates a domain by command as
libvirt saves vm's domain XML config in destination host after migration. But it saves vm->def. Then, the saved XML contains some garbages.
<domain type='kvm' id='50'> ^^^^^^^^ ... <console type='pty' tty='/dev/pts/5'> ^^^^^^^^^^^^^^^^^
Avoid saving unnecessary things by saving persistent vm definition. --- src/qemu/qemu_migration.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index a38c0d9..524b8bf 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2484,11 +2484,12 @@ qemuMigrationFinish(struct qemud_driver *driver, qemuMigrationVPAssociatePortProfiles(vm->def);
if (flags & VIR_MIGRATE_PERSIST_DEST) { + virDomainDefPtr vmdef; if (vm->persistent) newVM = 0; vm->persistent = 1; - - if (virDomainSaveConfig(driver->configDir, vm->def) < 0) { + vmdef = virDomainObjGetPersistentDef(driver->caps, vm); + if (virDomainSaveConfig(driver->configDir, vmdef) < 0) { /* Hmpf. Migration was successful, but making it persistent * was not. If we report successful, then when this domain * shuts down, management tools are in for a surprise. On the
ACK, the existing bug was harmless, since those attributes won't be parsed later, but it is good to fix none-the-less. 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 08/26/2011 08:25 AM, Daniel P. Berrange wrote:
On Fri, Aug 26, 2011 at 12:15:37PM +0900, KAMEZAWA Hiroyuki wrote:
From e1e8d5ceb4a9f7c59e20dfb8c168b781435c1613 Mon Sep 17 00:00:00 2001 From: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com> Date: Fri, 26 Aug 2011 12:08:11 +0900 Subject: [PATCH] Fix persistent migration config save
When a user migrates a domain by command as
libvirt saves vm's domain XML config in destination host after migration. But it saves vm->def. Then, the saved XML contains some garbages.
<domain type='kvm' id='50'> ^^^^^^^^ ... <console type='pty' tty='/dev/pts/5'> ^^^^^^^^^^^^^^^^^
Avoid saving unnecessary things by saving persistent vm definition.
This brings up a related point. Suppose I have a persistent guest on the source, and make a transient hot-plug operation prior to migration, then a config-only change to affect next boot, such as an increase in maxmem. That is, the dumpxml --inactive is different from the dumpxml (only the latter has the hotplug, while only the latter has the change to affect next boot). Then I migrate. Right now, this means that the destination machine will get a persistent def that locks in the running state (that is, my hotplug becomes permanent and my maxmem increase is lost). I think that on persistent migrations, we need to migrate both the running xml _and_ the config (this patch merely recreates the config on the destination based on the running state). But since config domain xml is rather large, I don't know if we can fit it into the cookie of v3 migration. So right now, the burden is on the caller to do the migration, then to manually redefine the config on the destination to match the desired config for what was on the source. :( It goes back to my analysis for migration of snapshot data - we might need a migration v4 that can transfer as many additional handshakes as needed to cover multiple metadata motions (right now, I can think of at least the metadata for config, and the metadata for each snapshot, all in addition to the xml for the running domain actually being transferred). And someday, I'd _love_ to have libvirt allow offline migration - that is, migrate a persistent domain from one host to another even while the guest is in the inactive state, but picking up all metadata associated with that inactive guest (that would include any managed save file, and all snapshot metadata). At any rate, that's food for thought for the future, and shouldn't hold up this patch, even if this patch still isn't ideal. So given Dan's ACK, I've pushed it.
ACK, the existing bug was harmless, since those attributes won't be parsed later, but it is good to fix none-the-less.
-- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, 26 Aug 2011 09:46:13 -0600 Eric Blake <eblake@redhat.com> wrote:
On 08/26/2011 08:25 AM, Daniel P. Berrange wrote:
On Fri, Aug 26, 2011 at 12:15:37PM +0900, KAMEZAWA Hiroyuki wrote:
From e1e8d5ceb4a9f7c59e20dfb8c168b781435c1613 Mon Sep 17 00:00:00 2001 From: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com> Date: Fri, 26 Aug 2011 12:08:11 +0900 Subject: [PATCH] Fix persistent migration config save
When a user migrates a domain by command as
libvirt saves vm's domain XML config in destination host after migration. But it saves vm->def. Then, the saved XML contains some garbages.
<domain type='kvm' id='50'> ^^^^^^^^ ... <console type='pty' tty='/dev/pts/5'> ^^^^^^^^^^^^^^^^^
Avoid saving unnecessary things by saving persistent vm definition.
This brings up a related point.
Suppose I have a persistent guest on the source, and make a transient hot-plug operation prior to migration, then a config-only change to affect next boot, such as an increase in maxmem. That is, the dumpxml --inactive is different from the dumpxml (only the latter has the hotplug, while only the latter has the change to affect next boot). Then I migrate.
Right now, this means that the destination machine will get a persistent def that locks in the running state (that is, my hotplug becomes permanent and my maxmem increase is lost).
Hmm...that't problem. Maybe I need to recommend users not to use --undefinesource/--persistent...
I think that on persistent migrations, we need to migrate both the running xml _and_ the config (this patch merely recreates the config on the destination based on the running state). But since config domain xml is rather large, I don't know if we can fit it into the cookie of v3 migration. So right now, the burden is on the caller to do the migration, then to manually redefine the config on the destination to match the desired config for what was on the source. :(
It goes back to my analysis for migration of snapshot data - we might need a migration v4 that can transfer as many additional handshakes as needed to cover multiple metadata motions (right now, I can think of at least the metadata for config, and the metadata for each snapshot, all in addition to the xml for the running domain actually being transferred).
And someday, I'd _love_ to have libvirt allow offline migration - that is, migrate a persistent domain from one host to another even while the guest is in the inactive state, but picking up all metadata associated with that inactive guest (that would include any managed save file, and all snapshot metadata).
Ah, yes. I'd like to implement offline migration, too. Now, it need to be # virsh dumpxml dom >memo.xml # virsh -c dest define memo.xml 2 users have already complained about it. I wonder...I'd like to have # virsh dom-copy dom desturi I can add a new function virDomainCopy(dom, dconn, flags) (This just defines dom in dconn.) And replace --undefinesource/--persistent hooks in Migration drivers. Then, offline migration can be implemented easily... Thanks, -Kame
participants (3)
-
Daniel P. Berrange -
Eric Blake -
KAMEZAWA Hiroyuki