Features/VMSnapshotEnchancement

VM Snapshot enhancement

This feature will enhance VM snapshot functionality, to make it possible lively taking internal/external snapshots, and make it works better with underlining components such as LVM. Qemu then will have a completed picture about snapshot methods:

--qemu manage snapshot:

|----internal case

|----external case

--qemu do not manage snapshot:

|----block drain case

• Name: Wenchao Xia
• Email: xiawenc@linux.vnet.ibm.com, xiaxia347os@163.com

General Summary

This feature would provide APIs that can do:

• 1 block device live snapshot as internal/external/blank delta data, export sync API for all type.
• 2 vmstate live save as internal/external data, export async API for external data, fix the size problem.
• 3 combination(internal block snapshot + internal vmstate save, internal block snapshot + external vmstate save, external block snapshot external vmstate save).
• 4 a way to screen dump in the time of snapshot complete.

Subtask Details

Now qemu support block device live external snapshot, live migration to file, static internal block snapshot + internal vmstate save, following are the blanks need to be filled:

• 1 expose block device live internal snapshot.
• 2 add and expose block device drain.
• 3 provide 1,2 together with block external snapshot in unified style.
• 4 make vmstate save lively.
• 5 add progress query.
• 6 fix the vmstate size issue.
• 7 add vmstate save to external file which have the format that qemu support.
• 8 provide vmstate save internal/external in unified style, user can specify whether cal GA FS freeze before complete, whether vm pause after complete.
• 9 add vm lively save interface in qemu(only for internal vmstate+ internal block snapshot, in which case the content is managed

by qemu).

• 10 related information retrieving enhancement as qmp/hmp interface.

General Goal

First consider what is needed to take snapshot for an common application, or qemu:

Pic 1, principle for snapshot data for an application

As the picture shows, generally the application need to ensure disk<->memory can be safely transformed in some format, that is data on disk saved can be used to restore to a runtime application state, usually by a flush and freeze at up level. Then let a lower level components write down the contents. Once above is satisfied, snapshot can be done. That means for qemu, it can choose whether write down vmstate, whether does the disk content save/restore itself.

Snapshot are intensive used in backup application, for qemu case, the backup application may have a goal as following:

Pic 2, general goal on backup server

The base or delta are data set which does not have to be file, and qemu may just provide those data in some form, in some case the delta data can be got by exporting internal snapshot from an image if there is a tool. So there will be some different cases to take snapshot, and now qemu 1.3 support external block file + external vmstate file, with a little disadvantage that vmstate file size is not predicable, and internal case are not lively.

Note that there is requirement at VM host server to have better performance while a short chain exist, supporting additional snapshot case may give a chance to improve the performance, and let external components take some load from qemu to themself.

User Cases

As show above, how deep it can recover to, resulting a choice of whether to save vmstate. Who take the action, resulting a choice of whether qemu write/read the snapshot itself. For question two, things is a bit complicated, who take the action, what type of qemu's action to be(internal/external), will resulting many cases. Following picture shows the general relationship of components, to complete a snapshot for VM:

pic3, co-operation relationship in the big picture

Typical cases:

take LVM2 as an example as third party tool, vmstate save are optional, following are the typical cases:

Common Disadvantages: vmstate size is not predictable in lively saving.

--Type one, qemu manage snapshot:

-- Common advantages: less dependence, qemu manages all, workable on most systems.

-- Common disadvantages: lower level component have no chance to take the job.

• Case 1: external image snapshot data + external vmstate data

This is what qemu 1.3 support. Step:

 1 lively save vmstate to external place.
 2 at 95%, freeze guest FS by GA.
 3 freeze qemu block I/O by pause VM or queue I/O.
 4 blkdev-snapshot-sync each block device, get readonly image.
 5 restore qemu block I/O by resume VM or flush queued I/O.
 6 restore guest FS by GA.
 7 Copy out readonly image.
 (8 merge the image files.)

Advantages:

 Directly we have readonly standalone base / delta image files, "backup application" can directly copy

out them to form a chain. Disadvantages:

 External chain are slower in deleting(merging), reading.

• Case 2: internal image snapshot data + internal vmstate data

This is what qemu support as static method. Step:

 1 save vmstate to internal place.
 2 internal snapshot each block device.
 (3) pause the vm.
 (4) LVM create snapshot.
 (5) resume.

Todo:

 Fix the vmstate size issue, change it to commit.

Advantage:

 less dependence, qemu can manage bitmap and backing chain, so it is consistent, and ref count is faster.

• Case 3: internal image blank data (drain) + external vmstate data

Step:

 1 save vmstate to external place.
 2 pause VM(may call GA before).
 3 drain each block device.
 4 LVM create snapshot.
 5 resume.

Todo:

 Fix the vmstate size issue, add block device drain support, provide a interface integrate the calls.

Advantage:

 Fast, backing chain and block bitmap management can be offloaded from qemu to lower component, this also gives a
 chance to let lower software/hardware accelerate it.

• Case 4: internal image snapshot data + external vmstate data(not draw in the picture)

Step:

 1 save vmstate to external place.
 2 pause VM(may call GA before).
 3 internal snapshot each block device.
 4 LVM create snapshot.
 5 resume.

Todo:

 Fix the vmstate size issue, add block internal snapshot support, provide an interface integrate the calls.

Advantage:

 Internal snapshot are a bit faster, qemu managed the block snapshot consistence.

Lack:

 There is function duplication in qemu and lvm, actually only one is needed.

As a summary: focus on case 1, 2 for desktop usage on windows/Linux, focus on case 1, 3 for server usage on Linux.

API design

TBD.

Progress

TBD.