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: Wenchao Xia
Subject: Re: [Qemu-devel] [PATCH V9 00/14] qmp/hmp interfaces for internal snapshot info
Date: Wed, 13 Mar 2013 10:54:50 +0800
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

于 2013-3-13 0:16, Eric Blake 写道:
On 03/12/2013 04:07 AM, Stefan Hajnoczi wrote:
On Mon, Mar 11, 2013 at 07:23:02PM +0800, Wenchao Xia wrote:
   In the use of snapshot a way to retrieve related info at runtime is needed,
so this serial of patches will merge some code for qemu and qemu-img, and add
following interfaces for qemu:


Is there a reason you added the new query-images command instead of
extending BlockDeviceInfo with an ImageInfo field?  Then query-block,
which is already used today, just provides ImageInfo as well.

I suggest this because it makes life easier for clients - they can issue
a single command to extract all image information.  If we have two
commands they may have to invoke both and then match the results
together.

Indeed, from the libvirt perspective, I would much prefer that a single
command gives me everything, instead of having to call two commands to
build up the complete picture.


  I have no special reason for new interface query-images, it just
show up during the work, and I am pretty OK to merge the information
into query-block especially when the user of it, Eric hope so. Then
the qmp interface need to designed carefully, my idea is adding an item
in  BlockDeviceInfo:

{ '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".

--
Best Regards

Wenchao Xia




reply via email to

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