Re: [Qemu-devel] Re: [libvirt] Libvirt debug API

[Anthony Liguori <anthony@codemonkey.ws>]

On 04/26/2010 08:41 AM, Avi Kivity wrote:
>> Today, you have to make changes to libvirt whereas in a direct launch 
>> model, you get all of the neat security features linux supports for 
>> free.
>
> But you lose tap networking, unless you have a privileged helper.  And 
> how is the privileged helper to authenticate the qemu calling it?

There are a variety of ways.  My original proposal used a policy file.

>>>> And I've said in the past that I don't like the idea of a qemud :-)
>>>
>>> I must have missed it.  Why not?  Every other hypervisor has a 
>>> central management entity.
>>
>> Because you end up launching all guests from a single security context.
>
> Run multiple qemuds?
>
> But what you say makes sense.  It's similar to the fork()  /* do 
> interesting stuff */ exec() model, compared to the spawn(..., 
> hardcoded list of interesting stuff).
>
>>>> Yeah, that's where I'm at.  I'd eventually like libvirt to use our 
>>>> provided API and I can see where it would add value to the stack 
>>>> (by doing things like storage and network management).
>>>
>>> We do provide an API, qmp, and libvirt uses it?
>>
>> Yeah, but we need to support more features (like guest enumeration).
>
>
> What are our options?
>
> 1) qemud launches, enumerates
> 2) user launches, qemu registers in qemud
> 3) user launches, qemu registers in filesystem
> 4) you launched it, you enumerate it

Both 2 and 3 are appealing to me.

>> (3) The system management application can certainly create whatever 
>> context it wants to launch a vm from.  It's comes down to who's 
>> responsible for creating the context the guest runs under.  I think 
>> doing that at the libvirt level takes away a ton of flexibility from 
>> the management application.
>
> If you want to push the flexibility slider all the way to the right 
> you get bare qemu.  It exposes 100% of qemu capabilities.  And it's 
> not so bad these days.  But it's not something that can be remoted.

As I mentioned earlier, remoting is not a very important use-case to me.

Does RHEV-M actually use the remote libvirt interface?  I assume it'll 
talk to vdsm via some protocol and vdsm will use the local libvirt API.  
I suspect most uses of libvirt are actually local uses.

Regards,

Anthony Liguori