Re: [Qemu-devel] [PATCH V9 00/14] qmp/hmp interfaces for internal snapshot info

[Eric Blake]

On 03/13/2013 05:34 AM, Stefan Hajnoczi wrote:
>>
>> { 'type': 'BlockDeviceInfo',
>>   'data': { 'file': 'str', 'ro': 'bool', 'drv': 'str',
>>             '*backing_file': 'str', 'backing_file_depth': 'int',
>>             'encrypted': 'bool', 'encryption_key_missing': 'bool',
>>             'bps': 'int', 'bps_rd': 'int', 'bps_wr': 'int',
>>             'iops': 'int', 'iops_rd': 'int', 'iops_wr': 'int',
>>             'images': ['ImageInfo']} }}
>>
>>   In this way, new define of structure is not needed, and no break
>> of API I guess, but disadvantage is there will be some duplicated info
>> in ImageInfo and other structure in BlockInfo, such as "file,
>> encrypted".
> 
> I'm happy with adding a ImageInfo field into BlockDeviceInfo.
> 
> Why did you make it an array and what is the array's layout?

I think the point of an array of ImageInfo is to let us return data on
an entire backing chain.  That is, if I have:

image.raw <- middle.qcow2 (with internal snapshot "a") <- top.qcow2
(with internal snapshots "b", "c")

then I want to see data on image.raw, as well as on snapshots a, b, and
c, all in one command.  For my example, 'images' would be a
three-element array, with element 0 describing top.qcow2 and its two
internal snapshots, element 1 describing middle.qcow2 and its snapshot,
and element 2 describing image.raw.

However, it's also worth remembering that there has been a proposal for
having quorums, where a single block device can have multiple images
associated with the top level, and where we would then want a recursive
structure rather than an array for representing backing chain
information of a given information within the array of multiple images
associated with a single quorum device.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature