From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nz7az-0000k9-Im for qemu-devel@nongnu.org; Tue, 06 Apr 2010 08:09:29 -0400 Received: from [140.186.70.92] (port=35475 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nz7ay-0000io-8T for qemu-devel@nongnu.org; Tue, 06 Apr 2010 08:09:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nz7aw-0003HI-M0 for qemu-devel@nongnu.org; Tue, 06 Apr 2010 08:09:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46671) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nz7aw-0003HC-Cm for qemu-devel@nongnu.org; Tue, 06 Apr 2010 08:09:26 -0400 Message-ID: <4BBB2474.6010204@redhat.com> Date: Tue, 06 Apr 2010 15:09:24 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4BBA60CC.5050008@redhat.com> <2B33FC0A-344D-4A4D-8B2D-7E8FFBB038EF@suse.de> In-Reply-To: <2B33FC0A-344D-4A4D-8B2D-7E8FFBB038EF@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Alexander Graf Cc: Anthony Liguori , qemu-devel Developers 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