qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 00/11] convert savevm to use qapi and introdu


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v4 00/11] convert savevm to use qapi and introduce qmp command
Date: Thu, 11 Apr 2013 11:20:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

[Cc: Wenchao Xia because of overlap with his work]

Eric Blake <address@hidden> writes:

> On 04/10/2013 08:05 AM, Pavel Hrdina wrote:
>> Here is another proposal how to handle vm snapshots:
>> 
>> QMP vm-snapshot-save:
>>     - { 'command': 'vm-snapshot-save',
>>         'data': { 'name': 'str' },
>>         'returns': 'SnapshotInfo' }
>>     - vm-snapshot-save returns an error if there is an existing
>>       snapshot with the same name
>>     - you cannot provide an id for a new snapshot
>>     - on success all information about created snapshot will be returned
>> 
>> QMP vm-snapshot-load
>>     - { 'command': 'vm-snapshot-load',
>>         'data': { '*name': 'str', '*id': 'int' },
>>         'returns': 'SnapshotInfo' }
>>     - one of the name or id must be provided
>>     - if both are provided they will match only the snapshot with the
>>       same name and id
>>     - returns SnapshotInfo only if the snapshot exists.
>> 
>> QMP vm-snapshot-delete:
>>     - { 'command': 'vm-snapshot-delete',
>>         'data': { '*name': 'str', '*id': 'int' },
>>         'returns': 'SnapshotInfo' }
>>     - same rules as vm-snapshot-load
>
> Missing some form of query-snapshots to list all consistent snapshots
> that can be loaded or deleted (or is that another series?)
>
> Also, while load can only take a consistent snapshot, it might make
> sense to expose two levels of delete - one that deletes consistent
> snapshots, and one that deletes a snapshot for a given block device
> regardless of whether it is consistent across all devices in use by the VM.

I agree distinguishing between two levels (vm and device) make sense.

On the vm level, we consider only "consistent" snapshots, i.e. ones that
cover all devices and the VM state.  Semantics of save, load, delete and
query should all be obvious.

On the device level, query and delete make obvious sense.  Save and load
still have perfectly well-defined semantics (they apply just to the
device, and never include VM state), but may not be terribly useful in
practice.  Include them or not?  Not sure.

Wenchao Xia's work (pointed to by Pavel) deals with query on both
levels.

>> HMP savevm:
>>     - args_type = "force:-f,name:s?",
>>     - if the name is not provided the HMP command will generates new
>>       one for QMP command
>>     - if there is already a snapshot with provided or generated name
>>       it will fails
>>     - there will be an optional -f parameter to force saving requested
>>       snapshot and it will internally use vm-snapshot-delete and then
>>       vm-snapshot-save
>>     - all information about created snapshot will be printed
>> 
>> HMP loadvm:
>>     - args_type = "name:s?,id:i?",
>>     - follow the same behavior as the QMP command
>
> Except that with HMP, arguments are positional.  You can't provide 'id'
> in isolation; by listing id:i? second, the parser requires that the
> first argument encountered is a name.
>
> I think a better interface might be:
>
> HMP loadvm:
>     - args_type = "id:-i,name:s?'
>
> If just name is given, first do a tag lookup; if that fails do an id
> lookup.  If the -i flag is given, skip the tag lookup just do an id lookup.
>
>> 
>> HMP delvm:
>>     - args_type = "name:s?,id:i?"
>>     - same rules as loadvm
>
> Same comment as for loadvm.

Pavel's proposal together with Eric's corrections looks sane to me.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]