qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] QEMU patch to allow VM introspection via libvmi


From: Valerio Aimale
Subject: Re: [Qemu-devel] QEMU patch to allow VM introspection via libvmi
Date: Fri, 23 Oct 2015 09:03:06 -0600
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0



On 10/23/15 8:56 AM, Eric Blake wrote:
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.

Eric, good points. Libvmi was written quite some time ago; that libvirt api might not even have been there. When we agree on an access method to the guest mem, I will rewrite those legacy parts. I'm not the author of libvmi. I'm just trying to make it better, when accessing QEMU/KVM VMs




reply via email to

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