qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH V9 00/14] qmp/hmp interfaces for internal snapshot info
Date: Wed, 13 Mar 2013 13:40:48 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Mar 13, 2013 at 06:29:18AM -0600, Eric Blake wrote:
> 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.

The same applies for VMDK where one .vmdk can reference multiple extent
files.

This is why I asked about the array.  A dict of ImageInfos is needed,
they can refer to each other by key.

If we go with an array we're painting ourselves into a corner.

If we go with a dict it's more complicated and may not be used much.

I'd go for the dict but we need a policy for choosing keys (names) for
the ImageInfo elements.  Perhaps BlockDeviceInfo['file'] is the key for
the top-level image and then ImageInfo['backing-filename'] for the
backing chain.

Stefan



reply via email to

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