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

Anthony Liguori anthony at codemonkey.ws
Sat Apr 11 20:18:08 UTC 2009


Avi Kivity wrote:
> Anthony Liguori wrote:
>
>> IMHO, multiple monitors is a critical feature to support in the long 
>> term.
>
> Multiple monitors are nice to have (for developers), but I don't see 
> them as critical.

If you live in a world where there is a single management application 
that provides the only interface to interact with a QEMU instance, then 
yes, they aren't critical.

The problem with this is that most management applications are lossy by 
their nature.  They expose only a subset of functionality supported by QEMU.

Currently, the monitor is the "management interface" for QEMU.  If we 
only every support one instance of that management interface, then it 
means if multiple management applications are to interact with a given 
QEMU instance, they must all use a single API to do that then allows for 
multiplexing.  I see no reason that QEMU shouldn't do the multiplexing 
itself though.

To put it another way, a user that uses libvirt today cannot see QEMU 
instances that are run manually.  That is not true when a user uses 
libvirt with Xen today because Xend provides a management interface that 
is capable of supporting multiple clients.  I think it's important to 
get the same level of functionality for QEMU.

N.B. yes, Xend is a horrendous example especially when your argument has 
been simplicity vs. complexity.

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.

Regards,

Anthony Liguori




More information about the libvir-list mailing list