[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)

Daniel P. Berrange berrange at redhat.com
Tue Apr 14 08:30:16 UTC 2009

On Sun, Apr 12, 2009 at 07:42:17PM +0100, Jamie Lokier wrote:
> 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.

Yes indeed its a little crazy :-)  As anthony mentioned if libvirt were 
able to be notified of changes a user makes in the monitor, there's no 
reason we could not allow end users to access the monitor of a VM 
libvirt is managing. We just need to make sure libvirt doesn't miss
changes like attaching or detaching block devices, etc, because that'll
cause crash/data loss later when libvirt migrates or does save/restore,
etc because it'll launch QEMU with wrong args

> 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?

I think it could probably be argued that sending fake keystrokes could
be within scope. Random ad-hoc debugging probably out of scope.

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

More information about the libvir-list mailing list