On 12/7/18 10:49 AM, Vladimir Sementsov-Ogievskiy wrote:
$ qemu-nbd -L
exports available: 1
export: ''
size: 65536
flags: 0x4ed ( flush fua trim zeroes df cache )
min block: 512
opt block: 4096
max block: 33554432
available meta contexts: 1
base:allocation
don't you plan to bind this all to QAPI and expose in json?
No. As explained above, QAPI is very much centered on per-BDS actions, while
this action is a per-server action (where many servers have only one export,
but it is also possible to have a server with 0 exports or a plurality of
exports). I _can't_ fit this into query-block's ImageInfo details about a
block device, because we don't have a way of stating 'connect to this arbitrary
server, create an unspecified number of block devices, tell me about each of
them, and then throw them all away because we only wanted the info about what
the server made available'. The same is true for gluster or other remote access
block devices - the QMP commands pre-suppose you already know WHICH specific
resource you are accessing, rather than providing a way for you to query the
remote server about ALL resources available but without actually selecting
those resources.
I'm open to ideas about a new QMP command to do such a query, but who would be
the client? A management app that wants to hotplug a new NBD device to a
running guest can run 'qemu-nbd --list' just as easily as they could run a new
QMP command to learn what the server is offering. Without a strong reason of a
client that would need this in QMP, I don't see the point in adding it to the
qemu binary.
I didn't mean QMP. For example, QAPI struct ImageCheck is used only in
qemu-img, to format output.
Anyway, creating a struct in QAPI for something we want to export is a good
thing, I think.
Oh, I see where you're going with this. Just as 'qemu-img info' has
routines to pretty-print a QAPI structure (and thus adding ImageInfo to
the .json files automatically gets output in HMP without any additional
work), you're suggesting that NBDExportInfo be converted into a QAPI
struct, even if it won't be tied to QMP, in order to make the output
more programmatic instead of manual effort. I'll have to play with
that, although it might be a separate series on top of this.
Also, if, as you said, some management app wants to query this information,
again strictly
defined data + json output should be a good option. And, if there would be such
users, we'll
need to track compatibility of exported structure between qemu versions and
this is easier
with QAPI defined structure.
And then, defined structure may be then (at least partly) shared with
ImageInfoSpecificNBD.
And if we will need at some point a qmp command like query-nbd-server, to get
same information through
current qmp-connection, not running additional nbd-client, it would be a simple
thing to do.
If we ever need future extensions, we'll want to have QAPI structs in
place. But whether we implement the QAPI structs now, or at the time of
the future extension, is an engineering tradeoff (how much technical
debt are we incurring by not doing it now; and how likely are we to ever
want the future extension).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
