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

[Avi Kivity <avi@redhat.com>]

Anthony Liguori wrote:
> 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.
>

I do (or at least I hope I do).  Exposing the monitor to users is a 
layering violation.

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

What if they don't expose a feature because they don't want to make the 
feature available to the user?

What happens when the user changes something that the management 
application thinks it controls?  Do we add notifiers on everything?

The qemu monitor is a different privilege level from being a virtual 
machine owner.  Sure, we could theoritically plug all the holes with, 
for example the user filling up the disk with screendumps.  But do we 
want to reduce security this way?

You're taking away control from the management application, due to what 
are the management application's misfeatures.  You should instead tell 
the vendor of your management application to add the missing feature.

Oh, and don't expect users of a management application to connect to the 
qemu monitor to administer their virtual machines.  They expect the 
management application to do that for them.  The qemu monitor is an 
excellent way to control a single VM, but not for controlling many.

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

Again, I don't oppose multiplexing (though I do oppose the wait command 
which requires it, and I oppose this "management apps suck, let's telnet 
to qemu directly" use you propose.

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

I'm sure libvirt really enjoys it when users use xm commands to change 
the VM state.  What happens when you migrate it, for example?  Or add a 
few dozen vcpus?

>
> 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 have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.