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.

On 07/16/2012 01:33 AM, 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 > > - I want to test some changes to my vm, and either throw them away, or commit > them to my base disk image. > - 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) > > 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 Another possible way is to specify the device name explicitly using --diskspec ===================================================================== root@~$ virsh domblklist f17test --details Type Device Target Source ------------------------------------------------ file disk vda /var/lib/libvirt/images/f17test.qcow2 ===================================================================== root@~$ virsh snapshot-create-as f17test cleanf17 "cleanf17-box" --diskspec vda,file=/var/lib/libvirt/images/snap-f17test.qcow2 --disk-only Domain snapshot cleanf17 created root@~$ ===================================================================== > > 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'. 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'. 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? 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)? >From a previous discussion with Eric, with external snapshots the ‘original qcow2 file’ will be in a ‘read-only’ saved state, and the new qcow2 file(which will be generated once snapshot is created) will be the *delta* for the changes. So, all the changes will now be written to this delta file. External Snapshots appear to be useful for performing backups(though I'm yet to try those). Also, external snapshot creates a qcow2 file with the original file as its backing image, and the backing file can be /read/ in parallel with the running qemu. (side note: though, if we're not using --disk-only, then offline snapshots appear to be faster.) I'm also currently trying out different possibilities of external snapshots and trying to explore and understand proper use-cases. I'd be curious to hear more on this.

I'll will post my notes and participate in the above test day. Here's a slightly old blog post I made w/ snapshots - kashyapc.wordpress.com/2011/10/04/snapshotting-with-libvirt-for-qcow2-ima... > > Thanks, > Cole > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list >