[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH 13/14] qemu-nbd: Add --list option

From: Eric Blake
Subject: Re: [Qemu-block] [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

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 

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

reply via email to

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