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
