From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6OeF-0008KO-Fh for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:46:55 -0400 Received: from [140.186.70.92] (port=38125 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6OeD-0008JZ-S1 for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:46:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6OeB-0002ZV-RZ for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:46:53 -0400 Received: from mail-pv0-f173.google.com ([74.125.83.173]:38012) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6OeB-0002ZH-6q for qemu-devel@nongnu.org; Mon, 26 Apr 2010 09:46:51 -0400 Received: by pvg4 with SMTP id 4so586641pvg.4 for ; Mon, 26 Apr 2010 06:46:50 -0700 (PDT) Message-ID: <4BD59946.8040705@codemonkey.ws> Date: Mon, 26 Apr 2010 08:46:46 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Libvirt debug API References: <4BBF2E93.3020508@redhat.com> <20100409142717.GA11875@redhat.com> <20100412122013.58894a64@redhat.com> <4BD09A3B.3090001@codemonkey.ws> <4BD1971B.7060907@redhat.com> <4BD1A543.1050004@codemonkey.ws> <4BD1ADA2.2050605@redhat.com> <4BD1E723.6070005@codemonkey.ws> <4BD2BDE0.7020907@redhat.com> <4BD3B965.3060205@codemonkey.ws> <4BD42CDB.2030901@redhat.com> <4BD4F20D.8030901@codemonkey.ws> <4BD52B13.2040200@redhat.com> <4BD591AC.7090208@codemonkey.ws> <4BD597F1.2010205@redhat.com> In-Reply-To: <4BD597F1.2010205@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Libvirt , Jiri Denemark , Chris Lalancette , qemu-devel@nongnu.org, Luiz Capitulino On 04/26/2010 08:41 AM, Avi Kivity wrote: >> Today, you have to make changes to libvirt whereas in a direct launch >> model, you get all of the neat security features linux supports for >> free. > > But you lose tap networking, unless you have a privileged helper. And > how is the privileged helper to authenticate the qemu calling it? There are a variety of ways. My original proposal used a policy file. >>>> And I've said in the past that I don't like the idea of a qemud :-) >>> >>> I must have missed it. Why not? Every other hypervisor has a >>> central management entity. >> >> Because you end up launching all guests from a single security context. > > Run multiple qemuds? > > But what you say makes sense. It's similar to the fork() /* do > interesting stuff */ exec() model, compared to the spawn(..., > hardcoded list of interesting stuff). > >>>> Yeah, that's where I'm at. I'd eventually like libvirt to use our >>>> provided API and I can see where it would add value to the stack >>>> (by doing things like storage and network management). >>> >>> We do provide an API, qmp, and libvirt uses it? >> >> Yeah, but we need to support more features (like guest enumeration). > > > What are our options? > > 1) qemud launches, enumerates > 2) user launches, qemu registers in qemud > 3) user launches, qemu registers in filesystem > 4) you launched it, you enumerate it Both 2 and 3 are appealing to me. >> (3) The system management application can certainly create whatever >> context it wants to launch a vm from. It's comes down to who's >> responsible for creating the context the guest runs under. I think >> doing that at the libvirt level takes away a ton of flexibility from >> the management application. > > If you want to push the flexibility slider all the way to the right > you get bare qemu. It exposes 100% of qemu capabilities. And it's > not so bad these days. But it's not something that can be remoted. As I mentioned earlier, remoting is not a very important use-case to me. Does RHEV-M actually use the remote libvirt interface? I assume it'll talk to vdsm via some protocol and vdsm will use the local libvirt API. I suspect most uses of libvirt are actually local uses. Regards, Anthony Liguori