[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
- From: Avi Kivity <avi redhat com>
- To: Anthony Liguori <anthony codemonkey ws>
- Cc: Libvirt <libvir-list redhat com>, Jiri Denemark <jdenemar redhat com>, qemu-devel nongnu org
- Subject: Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
- Date: Sun, 25 Apr 2010 14:51:55 +0300
On 04/25/2010 06:39 AM, Anthony Liguori wrote:
On 04/24/2010 04:46 AM, Avi Kivity wrote:
On 04/23/2010 09:29 PM, Anthony Liguori wrote:
Maybe. We'll still have issues. For example, sVirt: if a QMP
command names a labeled resource, the non-libvirt user will have no
way of knowing how to label it.
This is orthogonal to QMP and has to do strictly with how libvirt
prepares a resource for qemu.
It's not orthogonal. If you allow qmp access behind libvirt's back,
it's a problem that you will have.
My point was, if libvirt is just exposing raw qemu features, then it
should be possible for qemu to arbitrate concurrent access. If
libvirt implements features on top of qemu, then no other third party
will be able to co-exist with those features without interacting with
qemu. It's an impossible problem for qemu to solve (arbitrating
access to state stored in a third party management app).
If libvirt implement features (like sVirt or network configuration) then
it is indeed impossible for qemu to arbitrate. If we take all those
features into qemu[d], then it becomes possible to arbitrate so long as
the libvirt and the other management app don't step on each others
toes. But that's impossible to guarantee if you upgrade your libvirt
while keeping the other app unchanged.
1) Allow libvirt users to access features of qemu that are not
exposed through libvirt
That's an artificial problem. If libvirt exposes all features, you
don't need to solve it.
It won't. Otherwise, we wouldn't be having this discussion.
Then libvirt will fade into uselessness. A successful app using libvirt
will grow, and will have new requirements. As soon as libvirt doesn't
meet those new requirements, the app will need to talk to qemu[d]
directly. Once it does that, it may as well use qemu[d] for everything;
if you can talk QMP and generate qemu command lines, there's not much
that libvirt buys you. Even the cross-hypervisor support is not that
hard to implement, especially if you only need to satisfy your own
2) Provide a means for non-libvirt users to interact with qemu
We have qmp. It doesn't do multiple guest management. I think it's
reasonable to have a qemud which does (and also does sVirt and the
zillion other things libvirt does) provided we remove them from
libvirt (long term). The only problem is that it's a lot of effort.
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?
This is really the qemu model (as opposed to the xend model).
(and the qemud model).
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).
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
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)
For (1), we all agree that the best case scenario would be for
libvirt to support every qemu feature. I think we can also all
agree though that this is not really practical and certainly not
practical for developers since there is a development cost
associated with libvirt support (to model an API appropriately).
All except me, perhaps.
We already have two layers of feature modeling: first, we mostly
emulate real life, not invent new features. PCI hotplug existed long
before qemu had support for it. Second, we do give some thought into
how we expose it through QMP. libvirt doesn't have to invent it
again, it only has to expose it through its lovely xml and C APIs.
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.
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.
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.
For the most part, the pool management is not virtualization specific
and you could have libvirt provide that functionality without it
knowing a thing about qemu.
Beyond simple porting, there's a secondary question of having
non-libvirt apps co-exist with libvirt apps. I think it's a good
long term goal, but I don't think we should worry too much about it
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?
error compiling committee.c: too many arguments to function
[Date Prev][Date Next] [Thread Prev][Thread Next]