Avi Kivity wrote:
Anthony Liguori wrote:
>At the end of the day, I want to be able to run a QEMU instance from
>the command line, and have virt-manager be able to see it remotely and
>connect to it. That means multiple monitors and it means that all
>commands that change VM state must generate some sort of notification
>such that libvirt can keep track of the changing state of a VM.
I don't think most management application authors would expose the qemu
monitor to users. It sounds like a huge risk, and for what benefit? If
there's something interesting you can do with the monitor, add it to the
management interface so people can actually use it. They don't buy this
stuff so they can telnet into the monitor.
I want the same as Anthony. I want to do unusual things that libvirt
doesn't support and shouldn't have to support itself, such as sending
keystrokes to a running VM (from a script), attaching a debugger, and
hotplugging network devices that are configured differently to how
libvirt would like to do it. I also want these VMs to show in the
nice GUI along with other non-debugging VMs, show their resources,
start and stop them easily, catch them when they attempt to reboot,
and let me do these things remotely.
My solutionat the moment is to put a monitor multiplexer outside QEMU
(it's a small Perl script). It accepts multiple monitor connections
and forwards to QEMU's single monitor, parsing the "^\(qemu\) "
prompt. This is obviously silly but it's what we have to do to get
this functionality.
I don't see how adding those low-level monitory things to libvirt is
an improvement - debugging and scripted keystrokes are not the sort of
functionality libvirt is for - or is it?
The other alternative is not to use libvirt for these VMs, but that
means losing functionality that's useful to me (visibility in the
GUI), and more importantly it means I have to configure nearly
identical VMs in a completely different way (totally different
configuration syntax between libvirt and QEMU direct) depending on
what I'm going to do with them.
Hence multiplexing monitors, either outside or inside QEMU. Inside is
better because its behaviour is more well-defined.
-- Jamie