On 10/23/2015 08:44 AM, Valerio Aimale wrote:
Libvmi dependence on virsh is so strict, that libvmi does not even know
if the QEMU VM has an open qmp unix socket or inet socket, to send
commands through. Thus, libvmi sends qmp commands (to query registers,
as an example) via
virsh qemu-monitor-command Windows10B '{"execute":
"human-monitor-command", "arguments": {"command-line": "info registers"}}'
This is an unsupported back door of libvirt; you should really also
consider enhancing libvirt to add a formal API to expose this
information so that you don't have to resort to the monitor back door.
But that's a topic for the libvirt list.
so that libvmi can find the rendezvous unix/inet address and sends
commands through that. As of now, each qmp commands requires a popen()
that forks virsh, which compounds to the slowness.
No, don't blame virsh for your slowness. Write your own C program that
links against libvirt.so, and which holds and reuses a persistent
connection, using the same libvirt APIs as would be used by virsh. All
the overhead of spawning a shell to spawn virsh to open a fresh
connection for each command will go away. Any solution that uses
popen() to virsh is _screaming_ to be rewritten to use libvirt.so natively.