From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuO2h-0007oo-A9 for qemu-devel@nongnu.org; Wed, 24 Mar 2010 06:42:31 -0400 Received: from [140.186.70.92] (port=60133 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuO2e-0007of-LW for qemu-devel@nongnu.org; Wed, 24 Mar 2010 06:42:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuO2c-0001e3-Iw for qemu-devel@nongnu.org; Wed, 24 Mar 2010 06:42:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1763) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuO2c-0001dv-AA for qemu-devel@nongnu.org; Wed, 24 Mar 2010 06:42:26 -0400 Message-ID: <4BA9EC88.6000906@redhat.com> Date: Wed, 24 Mar 2010 12:42:16 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt References: <4BA7C40C.2040505@codemonkey.ws> <20100323145105.GV16253@redhat.com> <4BA8D8A9.7090308@codemonkey.ws> <201003231557.19474.paul@codesourcery.com> <4BA8E6FC.9080207@codemonkey.ws> <4BA901B5.3020704@redhat.com> <4BA9A066.3070904@redhat.com> <20100324103643.GB624@redhat.com> In-Reply-To: <20100324103643.GB624@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org On 03/24/2010 12:36 PM, Daniel P. Berrange wrote: > On Wed, Mar 24, 2010 at 07:17:26AM +0200, Avi Kivity wrote: > >> On 03/23/2010 08:00 PM, Avi Kivity wrote: >> >>> On 03/23/2010 06:06 PM, Anthony Liguori wrote: >>> >>>>> I thought the monitor protocol *was* our API. If not, why not? >>>>> >>>> It is. But our API is missing key components like guest >>>> enumeration. So the fundamental topic here is, do we introduce these >>>> missing components to allow people to build directly to our interface >>>> or do we make use of the functionality that libvirt already provides >>>> if they can plumb our API directly to users. >>>> >>>> >>> Guest enumeration is another API. >>> >>> Over the kvm call I suggested a qemu concentrator that would keep >>> track of all running qemus, and would hand out monitor connections to >>> users. It can do the enumeration (likely using qmp). Libvirt could >>> talk to that, like it does with other hypervisors. >>> >>> >> To elaborate >> >> qemud >> - daemonaizes itself >> - listens on /var/lib/qemud/guests for incoming guest connections >> - listens on /var/lib/qemud/clients for incoming client connections >> - filters access according to uid (SCM_CREDENTIALS) >> - can pass a new monitor to client (SCM_RIGHTS) >> - supports 'list' command to query running guests >> - async messages on guest startup/exit >> > My concern is that once you provide this, then next someone wants it to > list inactive guests too. That's impossible, since qemud doesn't manage config files or disk images. It can't even launch guests! > Once you list inactive guests, then you'll > want this to start a guest. Once you start guests then you want cgroups > integration, selinux labelling& so on, until it ends up replicating all > of libvirt's QEMU functionality. > > To be able to use the list functionality from libvirt, we need this daemon > to also guarentee id, name& uuid uniqueness for all VMs, both running and > inactive, with separate namespaces for the system vs per-user lists. Or > we have to ignore any instances listed by qemud that were not started by > libvirt, which rather defeats the purpose. > qemud won't guarantee name uniqueness or provide uuids. > The filtering access part of this daemon is also not mapping well onto > libvirt's access model, because we don't soley filter based on UID in > libvirtd. We have it configurable based on UID, policykit, SASL, TLS/x509 > already, and intend adding role based access control to further filter > things, integrating with the existing apparmour/selinux security models. > A qemud that filters based on UID only, gives users a side-channel to get > around libvirt's access control. > That's true. Any time you write a multiplexer these issues crop up. Much better to stay in single process land where everything is already taken care of. So, at best qemud is a toy for people who are annoyed by libvirt. -- error compiling committee.c: too many arguments to function