From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nz7tl-0006La-NQ for qemu-devel@nongnu.org; Tue, 06 Apr 2010 08:28:53 -0400 Received: from [140.186.70.92] (port=43455 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nz7tk-0006Kn-5r for qemu-devel@nongnu.org; Tue, 06 Apr 2010 08:28:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nz7ti-0006CO-F8 for qemu-devel@nongnu.org; Tue, 06 Apr 2010 08:28:52 -0400 Received: from cantor.suse.de ([195.135.220.2]:53265 helo=mx1.suse.de) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nz7ti-0006CF-75 for qemu-devel@nongnu.org; Tue, 06 Apr 2010 08:28:50 -0400 Message-ID: <4BBB2900.9010309@suse.de> Date: Tue, 06 Apr 2010 14:28:48 +0200 From: Alexander Graf MIME-Version: 1.0 References: <4BBA60CC.5050008@redhat.com> <2B33FC0A-344D-4A4D-8B2D-7E8FFBB038EF@suse.de> <4BBB2474.6010204@redhat.com> In-Reply-To: <4BBB2474.6010204@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: libvirt vs. in-qemu management List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , qemu-devel Developers 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