[Qemu-devel] Re: libvirt vs. in-qemu management

[Alexander Graf]

Avi Kivity wrote:
> On 04/06/2010 01:29 AM, Alexander Graf wrote:
>>
>>> Well, I did suggest (and then withdraw) qemud.  The problem is that
>>> to get something working we'd duplicate all the work that's gone
>>> into libvirt - storage pools, svirt, network setup, etc.
>>>      
>> That's infrastructure that should probably go along with qemu then.
>> Why should other UIs not benefit from secure VMs? Why should other
>> UIs not benefit from device passthrough cleverness? Why should other
>> UIs not benefit from easier network setup?
>>    
>
> You're right.  So we should move all the setup code from libvirt to
> qemud, and have libvirt just do the hypervisor-agnostic ABI conversion.

I believe that's the right way to go, yes.

>
> Note things like network setup are a bottomless pit.  Pretty soon you
> need to setup vlans and bonding etc.  If a user needs one of these and
> qemud doesn't provide it, then qemud becomes useless to them.  But the
> same problem applies to libvirt.

If they are a bottomless pit then they are a bottomless pit. There's
nothing we can do about it. This pit needs to be dug either way, whether
it's in libvirt or in qemud.

>
>> Take a look at our competition (vmware / vbox). They do the full
>> stack. That's what users want. They want to do something easily. And
>> I do too :-).
>>    
>
> Well, let's resurrect qemud, populate it with code from libvirt
> (though I'm not sure C is the best language for it), and have libvirt
> talk to qemud.  That's what it does for esx anyway.


I'm unsure what the right language would be. C probably is not. But
having VM management be done by something qemu'ish sounds like a good idea.


Alex