From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGNoo-0001qD-0l for qemu-devel@nongnu.org; Fri, 15 Mar 2013 02:08:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGNom-0003tz-C6 for qemu-devel@nongnu.org; Fri, 15 Mar 2013 02:08:41 -0400 Received: from e28smtp06.in.ibm.com ([122.248.162.6]:54108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGNol-0003tJ-QA for qemu-devel@nongnu.org; Fri, 15 Mar 2013 02:08:40 -0400 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 15 Mar 2013 11:34:47 +0530 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 851D3394004F for ; Fri, 15 Mar 2013 11:38:32 +0530 (IST) Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2F68PNF67043568 for ; Fri, 15 Mar 2013 11:38:25 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2F68TWd022516 for ; Fri, 15 Mar 2013 17:08:29 +1100 Message-ID: <5142BA85.6090706@linux.vnet.ibm.com> Date: Fri, 15 Mar 2013 14:07:01 +0800 From: Wenchao Xia MIME-Version: 1.0 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> <20130313124048.GA31109@stefanha-thinkpad.muc.redhat.com> In-Reply-To: <20130313124048.GA31109@stefanha-thinkpad.muc.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Stefan Hajnoczi Cc: kwolf@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, pbonzini@redhat.com 于 2013-3-13 20:40, Stefan Hajnoczi 写道: > 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. > I'd like to confirm: This means a block device can have multiple images at top level, but one image can still have only one backing image at most? If my understanding is correct,following should be the case: 1 device hda have two active images: a.qcow2 and b.qcow2(maybe vmdk format now, just an example) 2 a.qcow2 file's backing file will be a_base0.qcow2, never a_base0.qcow2 and a_base1.qcow2. > 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 > Since ImageInfo already have key 'backing-filename', which stands for the information got in this image, not from the backing image, add a new key 'bakcing-image' for recursive linking: { 'type': 'ImageInfo', 'data': {'filename': 'str', 'format': 'str', '*dirty-flag': 'bool', '*actual-size': 'int', 'virtual-size': 'int', '*cluster-size': 'int', '*encrypted': 'bool', '*backing-filename': 'str', '*full-backing-filename': 'str', '*backing-filename-format': 'str', '*backing-image": 'ImageInfo', '*snapshots': ['SnapshotInfo'] } } Then insert ImageInfo into BlockDeviceInfo, with key 'images', since 'file' is already used which may break compatibility if we change it. 'images' uses an array for the case when multiple images exist in top level, not for backing chain. { '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']} }} -- Best Regards Wenchao Xia