[libvirt] [PATCHv2 09/11] qemu_capabilities: Persist QEMU instance over multiple QMP Cmds

Jiri Denemark jdenemar at redhat.com
Fri Jul 13 15:14:22 UTC 2018


On Mon, Jul 09, 2018 at 22:56:53 -0500, Chris Venteicher wrote:
> Commit makes starting a single persistent QEMU instance possible for use
> over multiple independent QMP commands without starting and stopping
> QEMU for each QMP command or command type.
> 
> Commit allows functions outside qemu_capabilities
> (ex.  qemuConnectBaselineHypervisorCPU in qemu_driver)
> requiring multiple different QMP messages to be sent to QEMU to issue
> those requests over a single QMP Command Channel without starting and
> stopping QEMU for each independent QMP Command usage.
> 
> Commit moves following to global scope so parent function can
> maintain QEMU instance over multiple QMP commands / command types:
> virQEMUCapsInitQMPCommand
> virQEMUCapsInitQMPCommandFree
> 
> Commit Introduces virQEMUCapsNewQMPCommandConnection to Start and
> connect to QEMU so QMP commands can be performed.
> 
> The new reusable function isolates code for starting QEMU and
> establishing Monitor connections from code for obtaining capabilities so
> that arbitrary QMP commands can be exchanged with QEMU.
> ---
>  src/qemu/qemu_capabilities.c | 61 +++++++++++++++++++++++-------------
>  src/qemu/qemu_capabilities.h | 26 +++++++++++++++
>  2 files changed, 66 insertions(+), 21 deletions(-)

Just a high level review since this patch will require some significant
changes...

Your approach will not work because all callers would end up using the
same monitor socket for to the QEMU process. And there might be several
concurrent callers which would want to call some QMP command to do the
job, each of them spawning their own QEMU process. You'd need to give
each caller a unique monitor socket path.

I think this should be reworked into a general code (ideally placed in
qemu_process.c), which would then be called by the QEMU capabilities
code and from APIs which need to call QEMU.

Jirka




More information about the libvir-list mailing list