From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHXMG-00047u-Pu for qemu-devel@nongnu.org; Mon, 18 Mar 2013 06:32:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHXM8-0005Nq-Iw for qemu-devel@nongnu.org; Mon, 18 Mar 2013 06:32:00 -0400 Received: from e28smtp05.in.ibm.com ([122.248.162.5]:40524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHXM7-0005MQ-Ue for qemu-devel@nongnu.org; Mon, 18 Mar 2013 06:31:52 -0400 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 18 Mar 2013 15:59:10 +0530 Received: from d28relay04.in.ibm.com (d28relay04.in.ibm.com [9.184.220.61]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id EF52E3940064 for ; Mon, 18 Mar 2013 16:01:45 +0530 (IST) Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2IAVgkm11076008 for ; Mon, 18 Mar 2013 16:01:42 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2IAVh0L006084 for ; Mon, 18 Mar 2013 10:31:43 GMT Message-ID: <5146ECAB.1030109@linux.vnet.ibm.com> Date: Mon, 18 Mar 2013 18:30:03 +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> <5142BA85.6090706@linux.vnet.ibm.com> <20130315080758.GB2418@dhcp-200-207.str.redhat.com> In-Reply-To: <20130315080758.GB2418@dhcp-200-207.str.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: Kevin Wolf Cc: Stefan Hajnoczi , pbonzini@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, lcapitulino@redhat.com 于 2013-3-15 16:07, Kevin Wolf 写道: > Am 15.03.2013 um 07:07 hat Wenchao Xia geschrieben: >> 于 2013-3-13 20:40, Stefan Hajnoczi 写道: >>> 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. > > I don't think this describes exactly what happens. Each qemu block > device refers to one BlockDriverState, let's say top.vmdk for the top > level image. This may refer to a backing file, backing.vmdk for example. > > Now top.vmdk nd back.vmdk could both be split images, and the former > refers to its extents top_0.vmdk and top_1.vmdk, which contain the > actual data of the image, and the latter may refer to backing_0.vmdk, > backing_1.vmdk and backing_2.vmdk. > > So this can happen in any position in the BlockDriverState graph. > Thank u for the detailed explaination. Currently BlockDriverState have only one file name, so if my understanding is correct, the multiple referred disk is actually an internal data struct in VMDK now. Qemu main block layer only saw "main" disk in each layer. an case: BlockDriverState: | top.vmdk<-----------------------------------ref_top.vmdk | | backing_top.vmdk<---ref_backing_top.vmdk backing_ref_top.vmdk This seems hard to be reflected in the structure I defined before, and hard to get in currently block.c's API. what I can think is improve ImageInfo: { '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', '*ref-images": '[ImageInfo]', '*snapshots': ['SnapshotInfo'] } } Backing-image reflect that one image can have one main backing file, and one image can have multiple referenced images. Do you think this structure is good enough? >> 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']} }} > > Yes, I think this is what Stefan meant (at least it looks like what I > was thinking of). > > Kevin > -- Best Regards Wenchao Xia