From Fedora Project Wiki
(Add 'how to test' section, brief release notes, and mark it 'ready')
(Testing Live Blockcommit)
 
(7 intermediate revisions by 4 users not shown)
Line 17: Line 17:
 
* Targeted release: [[Releases/18 | Fedora 18]]
 
* Targeted release: [[Releases/18 | Fedora 18]]
 
* Last updated: June 6 2012
 
* Last updated: June 6 2012
* Percentage of completion: 90%
+
* Percentage of completion: 100%
  
 
== Detailed Description ==
 
== Detailed Description ==
 
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
 
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
XXX: Point out that while qemu has had 'snapshot' capabilities for a long time, it was not 'live' and required pausing guest operation for the duration of the snapshot process. This is more a true snapshot.
+
 
 +
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 ==
 
== Benefit to Fedora ==
 
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
 
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
 +
* Snapshots can be performed on guests using any storage configuration (utilizing external qcow2 snapshots)
 +
* No downtime during the snapshotting process.
  
 
== Scope ==
 
== Scope ==
 
* Live snapshot support in qemu (DONE, 1.1 is in rawhide/f18)
 
* Live snapshot support in qemu (DONE, 1.1 is in rawhide/f18)
 
* Live snapshot support in qemu-ga (DONE)
 
* Live snapshot support in qemu-ga (DONE)
* Live snapshot support in libvirt (DONE)
+
* Live snapshot support in libvirt (DONE, but checkpointing usecase is still lacking)
 
* Apps (all optional but would be nice if they are done)
 
* Apps (all optional but would be nice if they are done)
** Snapshot support in ovirt? (unknown)
+
** Snapshot support in ovirt? (available, used for live backup)
** Snapshot support in virt-manager? (not done)
+
** Snapshot support in virt-manager? (not done, not a requirement)
** Snapshot support in boxes? (probably out of scope)
+
** Snapshot support in boxes? (out of scope)
  
 
== How To Test ==
 
== How To Test ==
Line 49: Line 52:
 
3. What are the expected results of those actions?
 
3. What are the expected results of those actions?
 
-->
 
-->
 +
 +
=== Live backup ===
 +
 +
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 <code>vda</code>) or path to the current disk image, just created by the snapshot command (in this example, <code>/var/lib/libvirt/images/myvm.snapshot1</code>).
 +
 +
  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.
 +
 +
=== VM checkpointing ===
 +
 +
The below commands are not fully implemented in libvirt yet.
 +
 
Any guest KVM guest can be snapshotted using external snapshot files. Simplest way:
 
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 snapshot1 "snapshot1 description" --disk-only --atomic
 
   virsh snapshot-create-as myvm snapshot2 "snapshot2 description" --disk-only --atomic
 
   virsh snapshot-create-as myvm snapshot2 "snapshot2 description" --disk-only --atomic
 
(however --atomic claims to only work for a guest with 1 disk. isn't that what jtc's patches were meant to fix? maybe just a libvirt validation issue)
 
  
 
You make some changes and want to switch back to an older snapshot state, you do:
 
You make some changes and want to switch back to an older snapshot state, you do:
Line 60: Line 82:
 
   virsh snapshot-revert myvm snapshot1
 
   virsh snapshot-revert myvm snapshot1
  
(however this doesn't work right now?: revert to external disk snapshot not supported yet)
+
XXX: however this doesn't work right now: 'revert to external disk snapshot not supported yet'
  
 
If you want to delete a snapshot, use:
 
If you want to delete a snapshot, use:
Line 66: Line 88:
 
   virsh snapshot-delete myvm snapshot2
 
   virsh snapshot-delete myvm snapshot2
  
(that also doesn't work: deletion of 1 external disk snapshots not supported yet)?
+
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.
 
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.
Line 72: Line 94:
 
--atomic should ensure all disks are snapshotted atomically
 
--atomic should ensure all disks are snapshotted atomically
  
 +
=== Testing Live Blockcommit ===
 +
http://kashyapc.fedorapeople.org/virt/blockcommit/recursive-blockcommit-base-raw.txt
 +
 +
(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)
  
 
== User Experience ==
 
== User Experience ==
Line 97: Line 123:
  
  
[[Category:FeatureReadyForWrangler]]
+
[[Category:FeatureAcceptedF18]]
 
<!-- When your feature page is completed and ready for review -->
 
<!-- When your feature page is completed and ready for review -->
 
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
 
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
 
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
 
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
 
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
 
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Latest revision as of 18:33, 23 October 2012


Virt Live Snapshots

Summary

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.

Owner

  • Name: Cole Robinson
  • Email: crobinso@redhat.com
  • Name: Jeff Cody
  • Email: jtc@redhat.com

Current status

  • Targeted release: Fedora 18
  • Last updated: June 6 2012
  • Percentage of completion: 100%

Detailed Description

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.

Scope

  • 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

Live backup

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, /var/lib/libvirt/images/myvm.snapshot1).

 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.

VM checkpointing

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

http://kashyapc.fedorapeople.org/virt/blockcommit/recursive-blockcommit-base-raw.txt

(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)

User Experience

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.

Dependencies

None

Contingency Plan

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.

Documentation

Release Notes

  • KVM and libvirt now support storage snapshotting of live guests with no downtime.

Comments and Discussion