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

[Avi Kivity <avi@redhat.com>]

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.

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.

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

-- 
error compiling committee.c: too many arguments to function