From: "Daniel P. Berrange" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Jeff Cody <jcody@redhat.com>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] RFC: making QMP query-block more useful
Date: Mon, 8 Oct 2012 12:02:12 +0100 [thread overview]
Message-ID: <20121008110212.GG20230@redhat.com> (raw)
In-Reply-To: <506F72C3.5080304@redhat.com>
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.
> Likewise, can 'qemu-img info' be enhanced to add a recursion flag?
Sounds like a good idea.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2012-10-08 11:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-05 23:52 [Qemu-devel] RFC: making QMP query-block more useful Eric Blake
2012-10-08 11:02 ` Daniel P. Berrange [this message]
2012-10-09 13:24 ` Luiz Capitulino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121008110212.GG20230@redhat.com \
--to=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=jcody@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).