* Paolo Bonzini (pbonzini@xxxxxxxxxx) wrote: > Il 03/03/2014 14:30, Kevin Wolf ha scritto: > >> > So why don't we simply reuse the existing migration code? > >> I think this is different in the same way that block-backup and > >> block-mirror are different. Huangpeng's proposal would let you make > >> a consistent snapshot of disks and RAM. > >Right. Though the point isn't about consistency (doing the disk snapshot > >when memory has converged would be consistent as well), but about > >having the snapshot semantically right at the time when the monitor > >command is issued instead of only starting it then and being consistent > >at the point of completion. > > Right---though it's not entirely true that migration only affects > the point in time where you have consistency. For example, with > migration you cannot use the guest agent for freeze/thaw and, even > if we changed the code to allow that, the pause would be much longer > than for live snapshots or block-backup. > > >This is indeed like pre/post-copy live migration, and probably both > >options have their uses. I would suggest starting with the easy one, and > >adding the post-copy feature on top. > > The feature matrix for migration and snapshot > > disk RAM internal snapshot > non-live yes (0) yes (0) yes > live, disk only yes (1) N/A yes (2) > live, pre-copy yes (3) yes no > live, post-copy yes (4) no no > live, point-in-time yes (5) no no > > (0) just stop VM while doing normal pre-copy migration > (1) blockdev-snapshot-sync > (2) blockdev-snapshot-internal-sync > (3) block-stream > (4) drive-mirror > (5) drive-backup > > By "the easy one" you mean live savevm with snapshot at the end of > RAM migration, I guess. But the functionality is already available > using migration, while point-in-time snapshots actually add new > functionality. I'm not sure what's the status of the kernel > infrastructure for post-copy. Andrea? Accumulating the running set of changes that migration is spitting out gets you some of the way - but to do it you have to have points in the migration stream which represent a consistent view of device state, RAM and disk and I think the tricky point is getting those consistent points; while the CPU is running the set of pages that migration spits out are certainly newer than old versions of the pages but I don't think you can just put a marker in and say that the point represents a single consistent view of RAM. In many ways this is the opposite of Michael Hines's microcheckpointing approach; which stops everything and takes the snapshot regularly; I did suggest a modification to that would be to COW those checkpoints. Dave -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
