[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]