From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFkzT-0004OJ-Pi for qemu-devel@nongnu.org; Wed, 13 Mar 2013 08:41:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFkzN-0003Lw-8O for qemu-devel@nongnu.org; Wed, 13 Mar 2013 08:41:07 -0400 Received: from mail-qc0-x229.google.com ([2607:f8b0:400d:c01::229]:46717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFkzN-0003Lp-3c for qemu-devel@nongnu.org; Wed, 13 Mar 2013 08:41:01 -0400 Received: by mail-qc0-f169.google.com with SMTP id t2so429644qcq.14 for ; Wed, 13 Mar 2013 05:41:00 -0700 (PDT) Date: Wed, 13 Mar 2013 13:40:48 +0100 From: Stefan Hajnoczi Message-ID: <20130313124048.GA31109@stefanha-thinkpad.muc.redhat.com> References: <1363000996-13221-1-git-send-email-xiawenc@linux.vnet.ibm.com> <20130312100754.GC19624@stefanha-thinkpad.redhat.com> <513F54EE.1050205@redhat.com> <513FEA7A.7000102@linux.vnet.ibm.com> <20130313113408.GA30532@stefanha-thinkpad.muc.redhat.com> <5140711E.5090900@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5140711E.5090900@redhat.com> Subject: Re: [Qemu-devel] [PATCH V9 00/14] qmp/hmp interfaces for internal snapshot info List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, lcapitulino@redhat.com, pbonzini@redhat.com, Wenchao Xia 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