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

[KAMEZAWA Hiroyuki]

On Fri, 26 Aug 2011 09:46:13 -0600
Eric Blake <eblake at 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 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).
> 

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