Features/SnapshottingImprovements

Snapshotting Improvements

id/tag confusion

• Starting a VM with no previous snapshot on the disks

(qemu) savevm 2
(qemu) savevm
(qemu) info snapshots 
Snapshot devices: ide0-hd0
Snapshot list (from ide0-hd0):
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         2                      1.5M 2010-07-21 16:55:48   00:00:15.581
2                                1.5M 2010-07-21 16:55:55   00:00:21.501
(qemu) loadvm 2 <loads the VM with the id 2>

It is not clear witch snapshot is going to be loaded.

Snapshot overwriting

• Is this the expected behavior?
• What other projects do?

By id

(qemu) savevm 
(qemu) savevm 
(qemu) info snapshots 
Snapshot devices: ide0-hd0
Snapshot list (from ide0-hd0):
ID        TAG                 VM SIZE                DATE       VM CLOCK
1                                3.9M 2010-07-21 17:08:31   00:00:03.696
2                                3.9M 2010-07-21 17:08:33   00:00:05.419 <-- 17:08:33
(qemu) savevm 2 <overwrittes the snapshot with id 2>
(qemu) info snapshots 
Snapshot devices: ide0-hd0
Snapshot list (from ide0-hd0):
ID        TAG                 VM SIZE                DATE       VM CLOCK
1                                3.9M 2010-07-21 17:08:31   00:00:03.696
2                                3.9M 2010-07-21 17:08:53   00:00:25.918 <-- 17:08:53

By tag

(qemu) savevm test1
(qemu) savevm test2
(qemu) info snapshots 
Snapshot devices: ide0-hd0
Snapshot list (from ide0-hd0):
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         test1                  3.9M 2010-07-21 17:12:11   00:00:08.126 <-- 17:12:11
2         test2                  3.9M 2010-07-21 17:12:19   00:00:16.053
(qemu) savevm test1
(qemu) info snapshots 
Snapshot devices: ide0-hd0
Snapshot list (from ide0-hd0):
ID        TAG                 VM SIZE                DATE       VM CLOCK
2         test2                  3.9M 2010-07-21 17:12:19   00:00:16.053
1         test1                  3.9M 2010-07-21 17:12:33   00:00:29.221 <-- 17:12:33

current/previous

• There is no way to know witch VM is loaded
• There is no history of loaded VMs

inheritance

The only way to know witch snapshot came before of after another is to look at the date, but it is not possible to fully deduct the relationship. e.g.:

(qemu) savevm a
(qemu) savevm b
(qemu) savevm c
(qemu) savevm d
(qemu) loadvm b
(qemu) savevm e
(qemu) info snapshots 
Snapshot devices: ide0-hd0
Snapshot list (from ide0-hd0):
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         a                      3.9M 2010-07-21 17:32:55   00:00:06.144
2         b                      3.9M 2010-07-21 17:33:00   00:00:11.103
3         c                      3.9M 2010-07-21 17:33:13   00:00:22.953
4         d                      3.9M 2010-07-21 17:33:16   00:00:26.289
5         e                      3.9M 2010-07-21 17:33:28   00:00:15.548

Snapshot e is newer than d, but it is an state saved right after b, and not d as implied by the ids and dates.

mixing disks could be dangerous

A VM is loaded with two devices, one device with three previous snapshots and the other device with two previous snapshots.

I take a new snapshot of the VM without a name: the first device will save the snapshot as id_str 4 and the second device with id_str 3.

I play around for a while and I want to restore the VM to my latest state. When 'info snapshots' is run, only the first device is show with the VM state, and the latest ID shown will be 4.

loading without checking all devices

So, I fire up loadvm 4. qemu will try to load by id or name anyway, will succeed loading the VM state from the first device, but will fail to load an non-existent snapshot id from the second device and will still be running with the second device out of sync with the VM state.

Patch that fixes this: http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg01065.html

equal IDs on the different devices with different states

Running again:

(qemu) savevm 4

The previously saved state identified by id_str 4 will be deleted and replaced by a new one, but only in the first device of my example above. The second device will get a new snapshot, since it does not have a id_str equal to 4.

If I run loadvm 4 again, the snapshot id 3 in the second device will be left there in an state diferent from the snapshot id 3 from the first device.