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