On Fri, 26 Aug 2011 09:46:13 -0600 Eric Blake <eblake@xxxxxxxxxx> 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@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). > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list