11:44 a.m.
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 eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org