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

[Valerio Aimale <valerio@aimale.com>]

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