On 07/15/2012 02:03 PM, Cole Robinson wrote: > Forgive my ignorance, but I'm trying to fill in some details for a Fedora > feature page: > > https://fedoraproject.org/w/index.php?title=Features/Virt_Live_Snapshots > > Yet things aren't working quite as expected in my tests. I'm trying to think > of this from an end user use case perspective. For example
Join the club. Yes, snapshot support is still a work in progress, and you've unfortunately hit on some of the sore points of things that are still on my plate to be implemented. Whether I can make them in time for the F18 feature freeze deadline is now looking iffy (although we may still end up getting them into F18 if we happen to rebase for other reasons before the F18 beta is in full swing). > > - I want to test some changes to my vm, and either throw them away, or commit > them to my base disk image. Yes, valid use case (and I want it too!). Back in libvirt 0.9.5,I even added the <transient/> marker under <disk> XML to support this notion, but haven't yet implemented it for qemu. The other restriction here is that discarding is easy, committing is harder (qemu 1.1 doesn't support online disk commits; qemu 1.2 will be improving the situation though). Offline commits via 'qemu-img' may be supportable, though, so I'm hoping to wire that in eventually. > - I want to have a base disk image, but have multiple snapshots with various > mutually exclusive VM changes in each, like one snapshot with libvirt 0.7.0 > installed, another with 0.8.0 installed. I want to switch between them > > (maybe those assumptions are off base to begin with) No, that's precisely why snapshots were created - it should indeed be easy to fork and create two snapshots of stages of VM usage, then revert to a snapshot to toggle between those two snapshots. > > So for a running guest, I do: > > virsh snapshot-create-as myvm snapshot1 "snapshot1 description" --disk-only > virsh snapshot-create-as myvm snapshot2 "snapshot2 description" --disk-only Remember that --disk-only of a running guest means that reverting to the snapshot will see the disks in a potentially inconsistent state (as if you had pulled the power cord), unless you also have the guest-agent installed and used the --quiesce flag. For that matter, even with a quiesced disk image, reverting to that state will still require the time to boot the guest; it almost sounds like you want the convenience of a system checkpoint (the ability to revert to a guest with its RAM state unchanged, which is much faster than booting from just disk state). > > I make some changes that I want to discard, so I try and switch back to the > older vm and want to switch back to an older snapshot state, odo: > > virsh snapshot-revert myvm snapshot1 > > But I get: 'revert to external disk snapshot not supported yet'. Yeah, that's still a glaring hole on my TODO plate. In particular, reverting to an internal system checkpoint snapshot is easy (no files to manage), but reverting to a disk snapshot means rebooting the guest, and also means deciding what to do with the fact that there are now two files (base and snapshot) - do the two files remain or get merged, and if they get merged, do we commit to base or pull into the snapshot? I think the fact that we have a flags argument in the API will allow the resolution to these questions, but it still means code has to be written to honor new flags. > Hmm, that > kind of invalidates all my use cases then. Additionally I don't see any API > option for merging snapshots, to fold my changes in snapshot2 into parent > snapshot1 or similar. I tried using snapshot-delete, but that also fails with > external disk snapshots: 'deletion of 1 external disk snapshots not supported > yet' > > Additionally, there's the --atomic option to snapshot-create-as, but it fails > for guests with more than 1 snapshotable disks: 'atomic live snapshot of > multiple disks is unsupported'. That's a factor of what qemu version you used. Qemu 1.1 provides the 'transaction' command, which is all the more this should be relying on. What were you testing with? > But isn't that what some of the recent qemu > additions explicitly supposed to support (that's the impression I got from > jtc)? > > So am I missing anything? If not, are things just not fully wired up or are > there missing chunks of functionality? Unfortunately yes. > And what's the use case for the current > impl of disk snapshoting (while I've read around and found lot's of info about > the implementation side of things, not too much about intended uses)? Right now, about the only decent use case for disk-only snapshots is for VDSM to take a snapshot with minimal guest time, in order to create a backing file that can then be backed up while the guest continues to run, and where VDSM will externally (using qemu-img or other tools outside of libvirt) revert to the disk snapshot by itself. I _do_ plan to make them more useful with just libvirt API (no external commands needed), but it will take me time to get those patches written. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
