From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuPZ7-0003xI-NM for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:20:05 -0400 Received: from [140.186.70.92] (port=34456 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuPZ6-0003x6-5y for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:20:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuPZ3-0003iO-Jm for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:20:03 -0400 Received: from mail-gx0-f209.google.com ([209.85.217.209]:50701) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuPZ3-0003hK-HR for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:20:01 -0400 Received: by gxk1 with SMTP id 1so3070721gxk.16 for ; Wed, 24 Mar 2010 05:20:00 -0700 (PDT) Message-ID: <4BAA036D.3010707@codemonkey.ws> Date: Wed, 24 Mar 2010 07:19:57 -0500 From: Anthony Liguori 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> In-Reply-To: <4BA9A066.3070904@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: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org On 03/24/2010 12:17 AM, 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 Then guests run with the wrong security context. Regards, Anthony Liguori > qemu > - with -qemud option, connects to qemud (or maybe automatically?) > > qemudc > - command-line client, can access qemu human monitor >