Features/Snapshots: Difference between revisions
No edit summary |
No edit summary |
||
Line 33: | Line 33: | ||
|- | |- | ||
| '''format''' || format of snapshot image, valid formats are QCOW2 & QED (when merged upstream If not specified, the image will default to QCOW2. | | '''format''' || format of snapshot image, valid formats are QCOW2 & QED (when merged upstream If not specified, the image will default to QCOW2. | ||
|} | |||
==QMP command== | |||
The QMP command matches the behaviour of the human monitor command, except it is named slightly differently to match the fact that the command is synchronous. | |||
'''blockdev-snapshot-sync device snapshot-file [format]''' | |||
{|border=1 | |||
| '''device''' || device name to snapshot (json-string) | |||
|- | |||
| '''snapshot-file''' || name of new image file (json-string) | |||
|- | |||
| '''format''' || format of new image (json-string, optional) | |||
|} | |} | ||
Revision as of 10:31, 12 July 2011
Live Snapshots
This document is describing the current design of live snapshots for QEMU. It is a work in progress and things may change as we progress.
Overall concept
The idea is to be able to issue a command to QEMU via the monitor or QMP, which causes QEMU to create a new snapshot image with the original image as the backing file, mounted read-only. This will allow the original image file to be backed up.
Roll-back to a previous version requires one to boot from the previous backing file, at which point the snapshot file becomes invalid. Unfortunately there is no way to detect that a backing file has been booted, making it important for administrators to take care to not rely on snapshot files being valid after a roll-back.
The snapshot image will have to be in a format which support backing files, ie QCOW2 (and QED when the code is integrated), however the original image can be of any supported format. Ie. it is possible to make a QCOW2 snapshot of a RAW image.
High level design
Snapshot procedure:
- Run the VM
- (Optional)Admin tool calls Agent in guest, requesting consistent state
- Issue snapshot command to QEMU: The command will specify which block device is to be snapshot, as well as the filename of the QCOW2 snapshot image (see below).
- QEMU creates new snapshot image
- VM is halted by QEMU
- Flush pending IOs
- Switch VM to open new snapshot image, using original image as read only backing file.new image.
- Restart VM
- (Optional)Admin tool calls Agent in guest, with run command
Monitor command
The monitor command is designed to be flexible enough to handle both internal and external snapshots, as well as snapshots to various different snapshot file formats.
snapshot_blkdev device [snapshot-file] [format]:
device | block device to snapshot |
snapshot-file | target snapshot file, if no specified, the snapshot is meant to be internal to the original image. Internal snapshots are not expected to be supported in the initial implementation. |
format | format of snapshot image, valid formats are QCOW2 & QED (when merged upstream If not specified, the image will default to QCOW2. |
QMP command
The QMP command matches the behaviour of the human monitor command, except it is named slightly differently to match the fact that the command is synchronous.
blockdev-snapshot-sync device snapshot-file [format]
device | device name to snapshot (json-string) |
snapshot-file | name of new image file (json-string) |
format | format of new image (json-string, optional) |
Future features
Internal snapshots to images which support internal snapshots (QCOW2 & QED) are not expected to be supported initially.