[Top][All Lists]

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

Re: [Qemu-block] [PATCH v2 3/6] qapi: add nbd-server-remove

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [PATCH v2 3/6] qapi: add nbd-server-remove
Date: Tue, 6 Feb 2018 18:29:39 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

26.01.2018 18:05, Dr. David Alan Gilbert wrote:
* Vladimir Sementsov-Ogievskiy (address@hidden) wrote:
17.01.2018 19:03, Eric Blake wrote:
On 01/17/2018 09:51 AM, Vladimir Sementsov-Ogievskiy wrote:

I have a script (for managing libvirt guest, but it can be adopted for
qemu or even used for qemu monitor), which allows
me run qmp commands on vms as easy as:

|qmp VMNAME query-block-jobs or qmp VMNAME nbd-server-remove name exp1
mode hard or even |

|qmp VMNAME blockdev-add id disk driver qcow2 cache {writeback true
direct true} aio native discard unmap file {driver file filename
/tmp/somedisk} |||
Yeah, there are various scripting solutions around QMP that can make it
easier; but HMP is often still an easy front-line interface for

isn't it because these solutions are not available directly in monitor,
when HMP is?
QMP can be directly accessed in a monitor; it just requires more typing.
   If you are developing QMP commands, it may be easier to use
./scripts/qmp/qmp-shell (couple it with a readline wrapper, and you can
even get tab-completion and history across sessions).  There's also
things like libvirt's 'virsh qmp-monitor-command' for shell-scripting
access to arbitrary QMP commands, provided your guest is run by libvirt.

may be, we need third type of monitor HQMP which is QMP with simplified
syntax? Or
allow qmp commands in simplified syntax directly in HMP?
No, I don't think we need either thing.  Wrappers around existing
monitors is better than bloating qemu proper with a third flavor of
monitor.  And HMP is for humans, with no restrictions on back-compat
changes, so if it doesn't do something you want for quick-and-dirty
testing, you can either add a new HMP command, or just use QMP (or one
of its wrappers, like qmp-shell) in the first place.  Ultimately, our
long-term concern is only about the QMP interface; HMP is supposed to be
convenient.  So if it starts costing too much time to port a QMP
interface to HMP, then don't worry about it.

most of commands, ported to hmp are done in same style: they just call
corresponding qmp command.
Isn't it better to provide common interface for calling qmp commands through
HMP monitor, to never
create hmp versions of new commands? they will be available automatically.
It would be nice to do that, but they're not that consistent in how they
convert parameters and options, but I occasionally wonder if we could
automate more of it.

What about allowing some new syntax in hmp, directly mapped to qmp?

something like

>>> blockdev-add id disk driver qcow2 cache {writeback true direct true} aio native discard unmap file {driver file filename /tmp/somedisk}


Or it may be realized as a separate hmp command "qmp" (looks more safe as a first step, however, I think previous variant (direct call) is better):

>>> qmp blockdev-add id disk driver qcow2 cache {writeback true direct true} aio native discard unmap file {driver file filename /tmp/somedisk}

what do think? This looks simple to implement and should be useful.


Best regards,

Dr. David Alan Gilbert / address@hidden / Manchester, UK

Best regards,

reply via email to

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