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
experiments.
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.