- 1 Virt Live Snapshots
- 1.1 Summary
- 1.2 Owner
- 1.3 Current status
- 1.4 Detailed Description
- 1.5 Benefit to Fedora
- 1.6 Scope
- 1.7 How To Test
- 1.8 Testing Live Blockcommit
- 1.9 User Experience
- 1.10 Dependencies
- 1.11 Contingency Plan
- 1.12 Documentation
- 1.13 Release Notes
- 1.14 Comments and Discussion
Virt Live Snapshots
Live snapshots allow a user to take a snapshot of a virtual machine while the guest is running, thus preserving the state and data of a VM at a specific point in time.
- Name: Cole Robinson
- Email: email@example.com
- Name: Jeff Cody
- Email: firstname.lastname@example.org
- Targeted release: Fedora 18
- Last updated: June 6 2012
- Percentage of completion: 100%
QEMU has had snapshotting capabilities for a long time, but they have always required the guest to be paused/stopped for a short period of time while the storage was snapshoted. Live snapshots allow for qemu and libvirt to snapshot a the guest's storage with no downtime. This even works on guests with 'raw' disk images: libvirt will snapshot using an external qcow2 file, and transparently switch the guest over to running off the new external image.
Benefit to Fedora
- Snapshots can be performed on guests using any storage configuration (utilizing external qcow2 snapshots)
- No downtime during the snapshotting process.
- Live snapshot support in qemu (DONE, 1.1 is in rawhide/f18)
- Live snapshot support in qemu-ga (DONE)
- Live snapshot support in libvirt (DONE, but checkpointing usecase is still lacking)
- Apps (all optional but would be nice if they are done)
- Snapshot support in ovirt? (available, used for live backup)
- Snapshot support in virt-manager? (not done, not a requirement)
- Snapshot support in boxes? (out of scope)
How To Test
You can backup the storage of a VM from the host machine with no VM downtime.
Snapshot the VM:
virsh snapshot-create-as myvm snapshot1 "snapshot1 description" --disk-only --atomic
Backup the original storage using your regular backup method.
Merge the disk changes that accumulated in the snapshot back with the original disk. --path is the disk device (such as
vda) or path to the current disk image, just created by the snapshot command (in this example,
virsh blockpull --domain myvm --path /var/lib/libvirt/images/myvm.snapshot1
'blockpull' needs to be done for every disk image that was snapshotted. You can optionally supply a --base argument to blockpull, if it is desired to keep a common backing file while still collapsing the rest of a longer backing chain.
The below commands are not fully implemented in libvirt yet.
Any guest KVM guest can be snapshotted using external snapshot files. Simplest way:
virsh snapshot-create-as myvm snapshot1 "snapshot1 description" --disk-only --atomic virsh snapshot-create-as myvm snapshot2 "snapshot2 description" --disk-only --atomic
You make some changes and want to switch back to an older snapshot state, you do:
virsh snapshot-revert myvm snapshot1
XXX: however this doesn't work right now: 'revert to external disk snapshot not supported yet'
If you want to delete a snapshot, use:
virsh snapshot-delete myvm snapshot2
XXX: also doesn't work: 'deletion of 1 external disk snapshots not supported yet'
If the guest has qemu-ga installed and configured, passing --quiesce to snapshot-create-as will make sure the guest's filesystems are frozen for extra safety.
--atomic should ensure all disks are snapshotted atomically
Testing Live Blockcommit
(Side note: The "./qemu-img info --backing-chain " is with a patch available only via upstream qemu. Which will be available in QEMU-1.3)
Virtualization users will have a more production ready mechanism for snapshotting than QEMU previously supported (no loss of uptime). Exposing snapshotting in tools like ovirt and/or virt-manager will essentially be a new and compelling feature for those users.
Since this is brand new functionality, if it doesn't make it in time for F18, nothing has changed. We just drop this feature page.
- KVM and libvirt now support storage snapshotting of live guests with no downtime.