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

[Valerio Aimale]

On 10/23/15 12:35 AM, Markus Armbruster wrote:
> Eduardo Habkost <address@hidden> writes:
>
> > On Wed, Oct 21, 2015 at 12:54:23PM +0200, Markus Armbruster wrote:
> > > Valerio Aimale <address@hidden> writes:
> > [...]
> > > > There's also a similar patch, floating around the internet, the uses
> > > > shared memory, instead of sockets, as inter-process communication
> > > > between libvmi and QEMU. I've never used that.
> > > By the time you built a working IPC mechanism on top of shared memory,
> > > you're often no better off than with AF_LOCAL sockets.
> > >
> > > Crazy idea: can we allocate guest memory in a way that support sharing
> > > it with another process?  Eduardo, can -mem-path do such wild things?
> > It can't today, but just because it creates a temporary file inside
> > mem-path and unlinks it immediately after opening a file descriptor. We
> > could make memory-backend-file also accept a full filename as argument,
> > or add a mechanism to let QEMU send the open file descriptor to a QMP
> > client.
> Valerio, would an command line option to share guest memory suffice, or
> does it have to be a monitor command?  If the latter, why?
As Daniel points out, later in the thread, libvmi knows about QEMU VMs 
only via libvirt/virsh.

Thus, a command line option to share guest memory would work only if 
there was an info qmp command, info-guestmaps that would return 
something like

{
    'enabled' : 'true',
    'filename' : '/path/to/the/guest/memory/map'
}

so that libvmi can find the map.

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"}}'

It would be nice if there was a qmp command to query if there are 
qmp/hmp sockets open, info-sockets that would return something like

{
    'unix' : {
                    'enabled': 'true',
                    'address': '/path/to/socket/'
            },

   'inet'  : {
                    'enabled': 'true',
                    'address': '1.2.3.4:5678'
    }
}

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.