[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC: making QMP query-block more useful
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] RFC: making QMP query-block more useful |
Date: |
Tue, 9 Oct 2012 10:24:39 -0300 |
On Mon, 8 Oct 2012 12:02:12 +0100
"Daniel P. Berrange" <address@hidden> wrote:
> On Fri, Oct 05, 2012 at 05:52:35PM -0600, Eric Blake wrote:
> > Right now, 'query-block' has no way to filter to a single device, but
> > conversely, for each device, it shows only the first backing file,
> > rather than the entire backing chain. Jeff and I were lamenting this
> > fact on IRC while debugging his block-commit stuff.
> >
> > Would it be worth enhancing the QMP to be:
> >
> > ##
> > # @query-block:
> > #
> > # Get a list of BlockInfo for various virtual block devices.
> > #
> > # @devices: #optional If provided, limit the output to the given
> > # device names (since 1.3)
> > #
> > # @recurse: #optional Provide recursive information on any backing
> > # chains (since 1.3, default false)
> > #
> > # Returns: a list of @BlockInfo describing each virtual block device
> > #
> > # Since: 0.14.0
> > ##
> > { 'command': 'query-block',
> > 'arguments': { '*names': ['str'], 'recurse': 'bool' },
> > 'returns': ['BlockInfo'] }
> >
> > as well as enhancing BlockDeviceInfo to be self-recursive, by adding
> > backing_chain as in:
> >
> > # @backing_chain: #optional, only present if @backing_file is present
> > and 'query-block' requested recursion (since 1.3)
> >
> > { 'type': 'BlockDeviceInfo',
> > 'data': { 'file': 'str', 'ro': 'bool', 'drv': 'str',
> > '*backing_file': 'str', 'backing_file_depth': 'int',
> > '*backing_chain' : 'BlockDeviceInfo',
> > 'encrypted': 'bool', 'encryption_key_missing': 'bool',
> > 'bps': 'int', 'bps_rd': 'int', 'bps_wr': 'int',
> > 'iops': 'int', 'iops_rd': 'int', 'iops_wr': 'int'} }
> >
> > Or would such modifications require the creation of a new QMP command,
> > instead of altering 'query-block'?
>
> I think I'd probably go for creating a new command myself. I agree that
> both the changes you describe would be useful for libvirt needs.
I vote for a new command too.