[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