Libvirt manages all qemus, but this should be implemented independently
of libvirt.
In general qemu exposes communication channels (such as the monitor) as
tcp connections, unix-domain sockets, stdio, etc. It's very flexible.
Obviously you can't trust anything you get from a guest, no matter how
you get it.
How do you trust a userspace program's symbols? you don't. How do you
get them? they're on a well-known location.
That's exactly what happens. You invoke qemu with -monitor
unix:blah,server (or -qmp for a machine-readable format) and have your
management application connect to that. You can redirect guest serial
ports, console, parallel port, etc. to unix-domain or tcp sockets.
vmchannel is an extension of that mechanism.
Someone writing perf-gui outside the kernel would have the same
problems, no?
--
error compiling committee.c: too many arguments to function
--
