Hide Forgot
Description of problem: Section 2.4.3. Virt-manager snapshots of the Fedora 20 Release Notes states that the features listed in http://fedoraproject.org/wiki/Features/Virt_Live_Snapshots#VM_checkpointing of the fedora wiki should be working. However upon running a simple test it would seem that these features do not work as prescribed. Version-Release number of selected component (if applicable): - Fedora 20 How reproducible: Steps to Reproduce: 1. virsh snapshot-create-as myvm snapshot1 "snapshot1 description" --disk-only --atomic 2. ssh user@myvm touch test 3. virsh snapshot-revert myvm snapshot1 Actual results: error: unsupported configuration: revert to external disk snapshot not supported yet Expected results: A revert of the VM to the snapshot. Additional info: # virsh snapshot-list Faux Name Creation Time State ------------------------------------------------------------ snapshot1 2013-12-18 14:58:12 -0500 disk-snapshot # qemu-img snapshot -l /var/lib/libvirt/images/myvm.img [no data displayed] # virsh dumpxml myvm ... <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/myvm.snapshot1'/> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </disk> ... # ls -la /var/lib/libvirt/images/ total ######## drwxr-xr-x. 2 root root 4096 Dec 18 14:58 . drwxr-xr-x. 12 root root 4096 Dec 17 12:08 .. -rw-------. 1 qemu qemu 8591507456 Dec 18 14:57 myvm.img -rw-------. 1 qemu qemu 5963776 Dec 18 15:01 myvm.snapshot1 It looks as though the VM checkpoint commands to not create a qemu snapshot (checkpoint) but instead create an external snapshot. I do not feel that this should be the expected behavior or the default behavior. http://libvirt.org/formatsnapshot.html http://libvirt.org/formatdomain.html#elementsDisks
It also looks like a new disk is created and my VM simply uses the new disk, so If i delete my VM my other disk remains, this does not seem like it should be the default behavior.
Look at that wiki page again, you'll notice that there's XXX comments saying that the listed steps do not actually work, and that hasn't been fixed yet. There are plans to implement it in the future but it's a lot of work and not a huge priority. What you want does exist however, just drop the --disk-only flag. virt-manager provides UI for this in F20 now
Sure but this takes a live snapshot (VM Memory and all), doesn't it? I also do not think that this is a HUGE amount of work as I have bash script that I currently use to complete this (https://gist.github.com/sferich888/4978868).
*** Bug 1091328 has been marked as a duplicate of this bug. ***
Any plans to get this going? It's been a couple years since it was first requested. https://www.redhat.com/archives/libvirt-users/2012-May/msg00117.html
There's been bits and pieces floating around but nothing complete has landed yet AFAIK. This isn't really a priority for libvirt developers since the live snapshot feature is really about facilitating enterprisey use cases like live backup where the consumers don't really care about 'revert'. For end user type operations I'd recommend just using qcow2 internal snapshots, they are much more straight forward and support all the desired operations. That's what virt-manager exposes nowadays.
Hey Cole, thanks for your answer. The thing is you can't make an internal snapshot when the domain is running. To sum up: - external snapshot: can do live, can't revert - internal snapshot: can't do live, can revert So either way has its drawbacks. Implementing the external snapshot revert would at least make external snapshots feature-complete.
Internal snapshots definitely do work for a running VM. They aren't 'live' in that that VM is paused while the snapshot is being performed so you might have some downtime, but they do work on running VMs
Sorry for not being clear, I meant one-disk snapshots. libvirt: QEMU Driver error : unsupported configuration: active qemu domains require external disk snapshots; disk vdb requested internal Flags: VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY | VIR_DOMAIN_SNAPSHOT_CREATE_ATOMIC <disks> <disk snapshot="no" name="vda"/> <disk snapshot="internal" name="vdb"/> </disks> The same works ok with snapshot="external". That said, if there was a revert for external snapshots, they would be at least be feature-complete.
Indeed you can't do that with internal snapshots, they are fairly inflexible. External snapshots aren't feature complete even if revert support is added, deletion is still missing as well. Unfortunately it's all a lot of work, handling all the external files and making sure users don't shoot themselves in the foot with this stuff, and handling the failure scenarios is all quite a mess.
Just in case anyone's wondering that's supported at the moment. | live snapshot | live single | revert from | delete | all disks | single disk | snapshot | snapshot ---------+---------------+-------------+-------------+---------- external | yes | yes | no | no internal | yes | no | yes | yes
For reverting, as Cole says there are a few niggling scenarios that needs to be still tackled. A bit of notes from my experience of testing snapshots/disk image. Instead of reverting the external disk images (by manually editing domain's guest XML), I try to merge the disk image chain. You could merge the chain in few ways using: - 'blockcommit'- which merges 'top' images into 'base' images - 'blockpull' - that merges 'base' images into 'top' images e.g. with a chain like this for a libvirt guest 'vm1': [orig] <- [snap1] <- [snap2] <- [current] (live QEMU) You can merge back (by using 'blockcommit') the entire chain into [orig] - which will be the current active disk. Perform the live blockcommit: $ virsh blockcommit vm1 vda --wait --verbose --pivot --active Result: [orig] (live QEMU) The above disk image should contain all the contents from snap1, snap2, and curret).
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.