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