|
From: | Eric Blake |
Subject: | Re: [Qemu-devel] [PATCH 13/14] qemu-nbd: Add --list option |
Date: | Fri, 7 Dec 2018 10:59:38 -0600 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 |
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:allocationdon'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
[Prev in Thread] | Current Thread | [Next in Thread] |