[libvirt] [Qemu-devel] Re: Libvirt debug API
Anthony Liguori
anthony at codemonkey.ws
Mon Apr 26 13:46:46 UTC 2010
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
More information about the libvir-list
mailing list