[libvirt] libvirt + kvm external snapshots: use case?

[Cole Robinson]

Thanks for all the info!

On 07/18/2012 12:44 PM, Eric Blake wrote:
> 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).
> 

Right, system checkpoint is basically the use case I was going for. The nice
thing about the disk only snapshots though is that they can work with existing
guests that don't use qcow2, which is pretty compelling (especially because
that's all virt-manager has ever really created).

>>
>> 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.
> 

I think an initial patch that avoided merging or file removal, and required
the VM to be turned off would be cover most end user use cases. I'll try and
look into that this weekend.

>> 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?
> 

I was using qemu 1.0, but then I examined the upstream libvirt code and
misread a chunk of code. My bad!

>> 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.
> 

Ah the clouds have lifted :) . I couldn't really think of a use case for the
existing libvirt disk only support, so figured I was missing something. Live
backup explains things.

Thanks,
Cole