Re: [libvirt] [PATCH 09/20] snapshot: qemu: Add support for external checkpoints

On 10/23/2012 09:12 AM, Peter Krempa wrote: Outdated comment, but looks like you've touched that up on your git tree. The guest will pause either because _LIVE was not present (we paused up front), or because qemu will pause the domain when live migration converges. Then, while the guest is paused, we take the disk snapshot, then resume the guest, and voila! external snapshot! Hmm, wonder if we should document somewhere that: virDomainSave(dom, "/path/to/file") is now shorthand for: virDomainSnapshotCreate(dom, " <domainsnapshot> <memory file='/path/to/file'/> <disks> <disk name='vda' snapshot='no'/> <!-- etc. for each disk --> </disks> </domainsnapshot> ", VIR_DOMAIN_SNAPSHOT_CREATE_NO_METADATA) It also makes me wonder if virDomainSaveFlags should learn a _LIVE flag. Consider what happens when you save domain memory but not disks, and then let the domain continue running - since you didn't snapshot disks, then any modification made to the disks will invalidate the saved memory. That said, it is possible to create a domain that only uses read-only disks and stores everything in tmpfs. In fact, one of my favorite test cases while working on block-commit was a domain based on a live iso image - precisely because I can then attach any number (including 0) of other disks which won't be touched by the live OS, at which point you really can make a case for a live ram-only snapshot. Hmm, here we are starting an async job that can be canceled any time we drop locks. But the biggest part of this job is waiting for the migration to file to complete; once that part is done, we will drop locks several more times while issuing a 'transaction' or a series of disk snapshot monitor commands, and I don't think the cancellation code is prepared to handle that case. I wonder if we need to separate this into two jobs - one async to do the migration to file, and one sync to do the disk snapshots, so that we only allow cancellation during the first half (the second half is fast enough that we aren't starving access to the domain in the process). I haven't checked closely - does this new async job allow the user to pause and continue the guest at will? I know with live migration we allow the client to pause the guest if they are tired of waiting on things to converge (in fact, virsh even has a migrate option that auto-pauses the guest if things take too long). Hmm, while I know we can pause a live migration, what I don't know is if we allow resuming a guest while migration is ongoing. I'm worried that we are missing the interaction that allows a user to pause a live snapshot if things aren't converging fast enough. I would be okay if our design is that, for the initial implementation, we reject pause and resume attempts during a migration, and add that ability later, but it is something we need to keep in mind. And it does make the question of whether to resume a bit trickier - it is no longer a matter of whether the guest was running before we started the snapshot, but also whether the guest has been paused later on during a live snapshot. Similar to live migration, I'm assuming that it is always safe to pause, but that once things are paused, we probably want to reject resuming until the snapshot operation completes. I looked in your tree to see how you changed things for the _LIVE flag: + if (!(flags & VIR_DOMAIN_SNAPSHOT_CREATE_LIVE) || + (!memory && atomic && !transaction)) { That's not quite the right logic. You want to pause if there is a memory snapshot but no _LIVE flag, or if there are multiple disks but no transaction support. Something like: if ((memory && !(flags & VIR_DOMAIN_SNAPSHOT_CREATE_LIVE)) || (atomic && !transaction)) Be aware that at this point, even if _LIVE was specified, the domain is now paused (qemu pauses the domain once things converge) - you may need to account for this later. Yep, should have read further - the comment looks right. s/PAUSE/LIVE/, obviously We should fail internal checkpoint if _LIVE is present, since qemu's 'savevm' does not support a live mode. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org