Features/VMSnapshotEnchancement: Difference between revisions
No edit summary |
|||
Line 28: | Line 28: | ||
General goal from backup application persperctive: | General goal from backup application persperctive: | ||
[[File:Vmbackup_Common_goal.jpg]] | [[File:Vmbackup_Common_goal.jpg]] | ||
take LVM2 as an example as third party tool: | |||
* Case 1: external image snapshot data + external vmstate data | * Case 1: external image snapshot data + external vmstate data | ||
This is what qemu 1.3 support. | This is what qemu 1.3 support. | ||
Step: | Step: | ||
1 save vmstate to external place. | |||
2 blkdev-snapshot-sync each block device. | |||
3 Copy out data. | |||
4 Resume. | |||
Todo: | Todo: | ||
Fix the vmstate size issue(may introduce a new API), provide a interface integrate the calls. | |||
Advantage: | Advantage: | ||
less dependence, chain and block bitmap are managed by qemu. | |||
* Case 2: internal image snapshot data + external vmstate data | * Case 2: internal image snapshot data + external vmstate data | ||
Step: | |||
1 save vmstate to external place. | |||
2 pause VM(may call GA before). | |||
Advantage: faster. | 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: | |||
live commit internal snapshots now, so fit more for desktop usage now. | |||
* Case 3: internal image blank data (drain) + external vmstate data | * Case 3: internal image blank data (drain) + external vmstate data | ||
Step: | |||
1 save vmstate to external place. | |||
Advantage: | 2 pause VM(may call GA before). | ||
3 drain each block device. | |||
accelerate it. | 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 lower software/hardware to accelerate it. | |||
* Case 4: internal image snapshot data + internal vmstate data | * Case 4: internal image snapshot data + internal vmstate data | ||
This is what qemu support as static method. | |||
Advantage: | 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: | |||
qemu can manage bitmap and backing chain, so it is consistent. | |||
Lack: | |||
Can't delete internal snapshit lively, so fit better for desktop usage. |
Revision as of 09:52, 18 January 2013
VM Back up enhancement
This feature will enhance VM backup functionality, to make it possible taking internal/external snapshots lively, and make it works better with underlining components such as LVM.
- 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).
Component 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 block device live internal snapshot, block device data drain, provide the interfaces in unified style.
- 2 change vmstate save from static to live, fix the problem that size is not predictable, add support to save vmstate to external file format that qemu support(raw, qcow2...).
- 3 an API allow management stack configure the combination.
- 4 qmp/hmp for related information retrieving.
User Cases
General goal from backup application persperctive:
take LVM2 as an example as third party tool:
- Case 1: external image snapshot data + external vmstate data
This is what qemu 1.3 support. Step:
1 save vmstate to external place. 2 blkdev-snapshot-sync each block device. 3 Copy out data. 4 Resume.
Todo:
Fix the vmstate size issue(may introduce a new API), provide a interface integrate the calls.
Advantage:
less dependence, chain and block bitmap are managed by qemu.
- Case 2: internal image snapshot data + external vmstate data
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:
live commit internal snapshots now, so fit more for desktop usage now.
- 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 lower software/hardware to accelerate it.
- Case 4: 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:
qemu can manage bitmap and backing chain, so it is consistent.
Lack:
Can't delete internal snapshit lively, so fit better for desktop usage.