8:53 p.m.
On 04/25/2010 06:51 AM, Avi Kivity wrote:
> It depends on what things you think are important. A lot of
> libvirt's complexity is based on the fact that it uses a daemon and
> needs to deal with the security implications of that. You don't need
> explicit labelling if you don't use a daemon.
I don't follow. If you have multiple guests that you want off each
other's turf you have to label their resources, either statically or
dynamically. How is it related to a daemon being present?
Because libvirt has to perform this labelling because it loses the
original user's security context.
If you invoke qemu with the original user's credentials that launched
the guest, then you don't need to do anything special with respect to
security.
IOW, libvirt does not run guests as separate users which is why it needs
to deal with security in the first place.
> This is really the qemu model (as opposed to the xend model).
(and the qemud model).
And I've said in the past that I don't like the idea of a qemud :-)
> In theory, it does support this with the session urls but they
are
> currently second-class citizens in libvirt. The remote dispatch also
> adds a fair bit of complexity and at least for the use-cases I'm
> interested in, it's not an important feature.
If libvirt needs a local wrapper for interesting use cases, then it
has failed. You can't have a local wrapper with the esx driver, for
example.
This is off-topic, but can you detail why you don't want remote
dispatch (I assume we're talking about a multiple node deployment).
Because there are dozens of remote management APIs and then all have a
concept of agents that run on the end nodes. When fitting
virtualization management into an existing management infrastructure,
you are going to always use a local API.
If you use a remote management API, you then have to worry about
security, authorization, and authentication. Just supporting SASL
really isn't enough because there are a lot fewer actual deployments of
kerberos out there (most of them are actually Active Directory and SASL
alone is not enough to interoperate with AD).
>>>
>>> 3) Provide a unified and interoperable view of the world for
>>> non-libvirt and libvirt users
>>
>> This problem can be solved by the non-libvirt users adopting
>> libvirt, or the libvirt users dropping libvirt. I don't understand
>> why we need to add interoperability between users who choose an
>> interoperability library and users who don't choose an
>> interoperability library.
>
> What I'd like to avoid is user confusion. Should a user use libvirt
> or libqemu? If they make a decision to use libqemu and then down the
> road want to use libvirt, how hard is it to switch? Fragmentation
> hurts the ecosystem and discourages good applications from existing.
> I think it's our responsibility to ensure there's a good management
> API that exists for qemu that we can actively recommend to our
> users. libvirt is very good at typical virtualization uses of qemu
> but qemu is much more than just that and has lots of advanced features.
Every typical virtualization use will eventually grow some non-typical
requirements. If libvirt explicitly refuses to support qemu features,
I don't see how we can recommend it - even if it satisfies a user's
requirements today, what about tomorrow? what about future qemu
feature, will they be exposed or not?
If that is the case then we should develop qemud (which libvirt and
other apps can use).
(even if it isn't the case I think qemud is a good idea)
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).
> That's not what the libvirt community wants to do. We're
very bias.
> We've made decisions about how features should be exposed and what
> features should be included. We want all of those features exposed
> exactly how we've implemented them because we think it's the right way.
>
> I'm not sure there's an obvious way forward unless we decide that
> there is going to be two ways to interact with qemu. One way is
> through the libvirt world-view and the other is through a more qemu
> centric view. The problem then becomes allowing those two models to
> co-exist happily together.
I don't think there's a point in managing qemu through libvirt and
directly in parallel. It means a user has to learn both APIs, and for
every operation they need to check both to see what's the best way of
exploiting the feature. There will invariably be some friction.
Layers need to stack on top of each other, not live side by side or
bypass each other.
I agree with you theoretically but practically, I think it's immensely
useful as a stop-gap.
>
> The alternative is to get libvirt to just act as a thin layer to
> expose qemu features directly. But honestly, what's the point of
> libvirt if they did that?
For most hypervisors, that's exactly what libvirt does. For Xen, it
also bypasses Xend and the hypervisor's API, but it shouldn't really.
Historically, xend was so incredibly slow (especially for frequent
statistics collection) that it was a necessity.
Qemu is special due to the nonexistence of qemud.
Why is sVirt implemented in libvirt? it's not the logical place for
it; rather the logical place doesn't exist.
sVirt is not just implemented in libvirt. libvirt implements a
mechanism to set the context of a given domain and dynamically label
it's resources to isolate it.
The reason it has to assign a context to a given domain is that all
domains are launched from the same security context (the libvirtd
context) as the original user's context (the consumer of the libvirt
API) has been lost via the domain socket interface.
If you used the /session URL, then the domain would have the security
context of whomever created the guest which means that dynamic labelling
of the resources wouldn't be necessary (you would just do static labelling).
This is certainly a more secure model and it's a feature of qemu that I
really wish didn't get lost in libvirt. Again, /session can do this too
but right now, /session really isn't usable in libvirt for qemu.
>> libvirt needs to either support all but the most esoteric use cases,
>> or to get out of the way completely.
>
> That's not where it is today or the path I think they're taking. I'm
> also not the person you have to convince of this.
>
It's fun trying all the same. But you are the person to convince that
side-by-side management is doomed to fail, yes?
The world is full of large collections of code that are all doomed to
fail :-)
Regards,
Anthony Liguori