From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Nu8PH-0001fE-8W
	for qemu-devel@nongnu.org; Tue, 23 Mar 2010 14:00:47 -0400
Received: from [140.186.70.92] (port=60239 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Nu8PE-0001dr-EL
	for qemu-devel@nongnu.org; Tue, 23 Mar 2010 14:00:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1Nu8PC-0002xq-Rq
	for qemu-devel@nongnu.org; Tue, 23 Mar 2010 14:00:44 -0400
Received: from mx1.redhat.com ([209.132.183.28]:37097)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1Nu8PC-0002xe-JY
	for qemu-devel@nongnu.org; Tue, 23 Mar 2010 14:00:42 -0400
Message-ID: <4BA901B5.3020704@redhat.com>
Date: Tue, 23 Mar 2010 20:00:21 +0200
From: Avi Kivity <avi@redhat.com>
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>
In-Reply-To: <4BA8E6FC.9080207@codemonkey.ws>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "libvir-list@redhat.com" <libvir-list@redhat.com>, Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

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.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.