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

Avi Kivity avi at redhat.com
Sun Apr 25 11:51:55 UTC 2010

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 
>> 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)

>>> 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 
>>> now.
>> 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

More information about the libvir-list mailing list