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

[Avi Kivity]

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