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. Daniel -- |: 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
