From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuIyT-0007lV-Ia for qemu-devel@nongnu.org; Wed, 24 Mar 2010 01:17:49 -0400 Received: from [140.186.70.92] (port=58018 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuIyR-0007jS-8R for qemu-devel@nongnu.org; Wed, 24 Mar 2010 01:17:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuIyP-0001yJ-Sw for qemu-devel@nongnu.org; Wed, 24 Mar 2010 01:17:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10899) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuIyP-0001y8-LR for qemu-devel@nongnu.org; Wed, 24 Mar 2010 01:17:45 -0400 Message-ID: <4BA9A066.3070904@redhat.com> Date: Wed, 24 Mar 2010 07:17:26 +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> In-Reply-To: <4BA901B5.3020704@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: Anthony Liguori Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org 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 qemu - with -qemud option, connects to qemud (or maybe automatically?) qemudc - command-line client, can access qemu human monitor -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.