[libvirt] [BUGFIX][PATCH] remove saved garbages after persistent migration

[Eric Blake]

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 at 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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org