Re: libvirt + kvm external snapshots: use case?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]