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@xxxxxxxxxxxxxx>
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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list