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

[Kevin Wolf <kwolf@redhat.com>]

Am 18.03.2013 um 11:30 hat Wenchao Xia geschrieben:
> 于 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?

Yes, I think this is fine.

We don't need to introduce ref-images now, it's just good to have the
option to do it as soon as we need it. This is why we preferred using a
recursive structure instead of an array.

Kevin