Features/SnapshottingImprovements: Difference between revisions

From QEMU
No edit summary
No edit summary
Line 1: Line 1:
= Snapshotting Improvements =
= Snapshotting Improvements =


== id/tag confusion ==
== ID and TAG confusion ==


* Starting a VM with no previous snapshot on the disks
Starting a VM with no previous snapshot on the disks.
  (qemu) savevm 2
  (qemu) savevm 2
  (qemu) savevm
  (qemu) savevm
Line 15: Line 15:


It is not clear witch snapshot is going to be loaded.
It is not clear witch snapshot is going to be loaded.
Ideas for improvements:
* ''savevm'' tests the argument to check if it is an ID or a TAG. Make it accept only a TAG and do not allow the user to specify and ID.
* ''loadvm'' does the same thing. The user must specify if a ID or TAG is wanted. Suggestions:
(qemu) loadvm id=3
(qemu) loadvm tag=xxx
(qemu) loadvm xxx <error>
(qemu) loadvm 3 <error>
In case ''loadvm'' cannot be changed due to retro-compatibility, introduce a new command. Suggestions:
(qemu) load_vm id=3
(qemu) load_vm tag=xxx
(qemu) loadvm_byid 3
(qemu) loadvm_bytag xxx


== Snapshot overwriting ==
== Snapshot overwriting ==


* Is this the expected behavior?
* Is this the expected behavior?
** Don't think so.
* What other projects do?
* What other projects do?
** VirtualBox does not allow specifying an ID, just a name and description of an snapshot. http://www.virtualbox.org/manual/ch01.html#snapshots
** VMware does not allow specifying and ID, just a name and description. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180
** XenServer does not allow specifying an ID, just a name. http://support.citrix.com/servlet/KbServlet/download/23735-102-646135/Administrators_Guide.pdf - page 127


=== By id ===
=== By id ===
Line 37: Line 55:
  1                                3.9M 2010-07-21 17:08:31  00:00:03.696
  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
  2                                3.9M 2010-07-21 17:08:53  00:00:25.918 <-- 17:08:53
Ideas for improvements:
* Do not allow the user to specify an ID when saving a VM, just a TAG.


=== By tag ===
=== By tag ===
  (qemu) savevm test1
  (qemu) savevm test1
  (qemu) savevm test2
  (qemu) savevm test2
(qemu) info snapshots  
  (qemu) info snapshots  
  Snapshot devices: ide0-hd0
  Snapshot devices: ide0-hd0
  Snapshot list (from ide0-hd0):
  Snapshot list (from ide0-hd0):
Line 54: Line 75:
  2        test2                  3.9M 2010-07-21 17:12:19  00:00:16.053
  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
  1        test1                  3.9M 2010-07-21 17:12:33  00:00:29.221 <-- 17:12:33
Ideas for improvements:
* Do not allow the user o overwrite an snapshot, even if saving it the same name (will have different IDs anyway)


== current/previous ==
== current/previous ==
* There is no way to know witch VM is loaded
* There is no way to know witch VM snapshot is currently loaded.
* There is no history of loaded VMs
* There is no history of loaded VMs.


== inheritance ==
== inheritance ==
Line 78: Line 102:


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.
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.
Ideas for improvements:
* Store the previous snapshot taken as parent_id of a new snapshot.


== mixing disks could be dangerous ==
== mixing disks could be dangerous ==
Line 90: Line 117:
state. When 'info snapshots' is run, only the first device is show
state. When 'info snapshots' is run, only the first device is show
with the VM state, and the latest ID shown will be 4.
with the VM state, and the latest ID shown will be 4.
Ideas for improvements:
* Use an stronger ID model, not sequential and large enough to be virtually unique.


=== loading without checking all devices ===
=== loading without checking all devices ===
Line 99: Line 129:
Patch that fixes this: http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg01065.html
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 ===
=== equal IDs on different devices with different states ===


Running again:
Running again:
  (qemu) savevm 4
  (qemu) savevm 4


Continuing on the same case.
The previously saved state identified by id_str 4 will be deleted and
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
replaced by a new one, but only in the first device of my example
Line 111: Line 142:
If I run loadvm 4 again, the snapshot id 3 in the second device will be left
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.
there in an state diferent from the snapshot id 3 from the first device.
Ideas for improvements:
* Use an stronger ID model, not sequential and large enough to be virtually unique.


== Monitor does not show all devices ==
== Monitor does not show all devices ==
Line 117: Line 151:


A first try to address this issue: http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02386.html
A first try to address this issue: http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02386.html
* Is it really necessary to show snapshot information and relating it block devices?
* Change 'info snapshots' to show information without exposing block devices?
= QMP =
Here is a list of suggested commands to manipulate snapshots information on a QEMU VM.
== query-snapshot-status ==
Returns '''true''' when the VM can be snapshotted, '''false''' otherwise.
-> {"execute": "query-snapshot-status"}
<- {"return": true }
* Not sure if QMP allow returning just a boolean.
== snapshot-create ==
Runs ''savevm''.
-> {"execute": "snapshot-create", "arguments": {"name": "vm_before_upgrade"} }
<- { "return": {} }
* "name" is mandatory and must be unique.
* Needs to return any errors.
== snapshot-delete ==
Runs delvm.
-> {"execute": "snapshot-delete", "arguments": {"name": "vm_before_upgrade"} }
<- { "return": {} }
* "name" is mandatory and must be unique.
* Needs to return any errors.
== snapshot-load ==
Runs loadvm.
-> {"execute": "snapshot-load", "arguments": {"name": "vm_before_upgrade"} }
<- { "return": {} }
* "name" is mandatory and must be unique.
* Needs to return any errors.
== query-snapshots ==
-> {"execute": "query-snapshots"}
<- {
"return": [
    {         
      "name": "vm_before_upgrade",
      "parent_name": "",
      "id": "3fab28c9-a6bd-4659-b9bc-683780d8a2d5",
      "parent_id": "00000000-0000-0000-0000-000000000000",
      "date": 20100415164856
    },
    {         
      "name": "vm_before_upgrade-2",
      "parent_name": "vm_before_upgrade",
      "id": "e693dce2-6e12-4474-9bbf-2b3f97323423",
      "parent_id": "00000000-0000-0000-0000-000000000000",
      "date": 20100415100000
    }
  ]       
}
* Do we really need to expose IDs or names should be enough?
* Does JSON has a date type of just using a integer like YYYYMMDDHHMMSS would be better?
Instead of a list, how about this:
-> {"execute": "query-snapshots"}
<- {
"return": [
    {         
      "vm_before_upgrade": {
      "id": "3fab28c9-a6bd-4659-b9bc-683780d8a2d5",
      "date": 20100415164856,
      "child": { "vm_before_upgrade-2":
  "id": "e693dce2-6e12-4474-9bbf-2b3f97323423",
          "date": 20100415100000
      }
                            }
        "random-backup": {
        "id": "abcdefcc-a6bd-4659-b9bc-683780d8a2d5",
        "date": 20111111111111
                          }
      }
  ]

Revision as of 21:43, 24 July 2010

Snapshotting Improvements

ID and 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.

Ideas for improvements:

  • savevm tests the argument to check if it is an ID or a TAG. Make it accept only a TAG and do not allow the user to specify and ID.
  • loadvm does the same thing. The user must specify if a ID or TAG is wanted. Suggestions:
(qemu) loadvm id=3
(qemu) loadvm tag=xxx
(qemu) loadvm xxx <error>
(qemu) loadvm 3 <error>

In case loadvm cannot be changed due to retro-compatibility, introduce a new command. Suggestions:

(qemu) load_vm id=3
(qemu) load_vm tag=xxx
(qemu) loadvm_byid 3
(qemu) loadvm_bytag xxx

Snapshot overwriting

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

Ideas for improvements:

  • Do not allow the user to specify an ID when saving a VM, just a TAG.

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

Ideas for improvements:

  • Do not allow the user o overwrite an snapshot, even if saving it the same name (will have different IDs anyway)

current/previous

  • There is no way to know witch VM snapshot is currently 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.

Ideas for improvements:

  • Store the previous snapshot taken as parent_id of a new snapshot.

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.

Ideas for improvements:

  • Use an stronger ID model, not sequential and large enough to be virtually unique.

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 different devices with different states

Running again:

(qemu) savevm 4

Continuing on the same case. 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.

Ideas for improvements:

  • Use an stronger ID model, not sequential and large enough to be virtually unique.

Monitor does not show all devices

When executing info snapshots only information about the device that saves the VM state is shown. If there are more devices, there is no way to verify if they are all consistent and have the same states.

A first try to address this issue: http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02386.html

  • Is it really necessary to show snapshot information and relating it block devices?
  • Change 'info snapshots' to show information without exposing block devices?

QMP

Here is a list of suggested commands to manipulate snapshots information on a QEMU VM.

query-snapshot-status

Returns true when the VM can be snapshotted, false otherwise.

-> {"execute": "query-snapshot-status"}
<- {"return": true }
  • Not sure if QMP allow returning just a boolean.

snapshot-create

Runs savevm.

-> {"execute": "snapshot-create", "arguments": {"name": "vm_before_upgrade"} }
<- { "return": {} }
  • "name" is mandatory and must be unique.
  • Needs to return any errors.

snapshot-delete

Runs delvm.

-> {"execute": "snapshot-delete", "arguments": {"name": "vm_before_upgrade"} }
<- { "return": {} }
  • "name" is mandatory and must be unique.
  • Needs to return any errors.

snapshot-load

Runs loadvm.

-> {"execute": "snapshot-load", "arguments": {"name": "vm_before_upgrade"} }
<- { "return": {} }
  • "name" is mandatory and must be unique.
  • Needs to return any errors.

query-snapshots

-> {"execute": "query-snapshots"}
<- {
"return": [
   {           
     "name": "vm_before_upgrade",
     "parent_name": "",
     "id": "3fab28c9-a6bd-4659-b9bc-683780d8a2d5",
     "parent_id": "00000000-0000-0000-0000-000000000000",
     "date": 20100415164856
   },
   {           
     "name": "vm_before_upgrade-2",
     "parent_name": "vm_before_upgrade",
     "id": "e693dce2-6e12-4474-9bbf-2b3f97323423",
     "parent_id": "00000000-0000-0000-0000-000000000000",
     "date": 20100415100000
   }
  ]        
}
  • Do we really need to expose IDs or names should be enough?
  • Does JSON has a date type of just using a integer like YYYYMMDDHHMMSS would be better?

Instead of a list, how about this:

-> {"execute": "query-snapshots"}
<- {
"return": [
   {           
      "vm_before_upgrade": { 
		      "id": "3fab28c9-a6bd-4659-b9bc-683780d8a2d5", 
		      "date": 20100415164856, 
		      "child": { "vm_before_upgrade-2": 
  					"id": "e693dce2-6e12-4474-9bbf-2b3f97323423",
 				        "date": 20100415100000 
			       }
                           }
        "random-backup": {
 		      "id": "abcdefcc-a6bd-4659-b9bc-683780d8a2d5",
 		      "date": 20111111111111
                         }
     }
  ]