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

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&lt;kamezawa.hiroyu(a)jp.fujitsu.com&gt; >> 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).