From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1O6L3k-0001YN-Ax
	for qemu-devel@nongnu.org; Mon, 26 Apr 2010 05:57:00 -0400
Received: from [140.186.70.92] (port=47403 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1O6L3i-0001Xn-E2
	for qemu-devel@nongnu.org; Mon, 26 Apr 2010 05:56:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <matthias.bolte@googlemail.com>) id 1O6L3g-0006gs-Q7
	for qemu-devel@nongnu.org; Mon, 26 Apr 2010 05:56:58 -0400
Received: from mail-bw0-f209.google.com ([209.85.218.209]:33146)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <matthias.bolte@googlemail.com>) id 1O6L3g-0006gY-L6
	for qemu-devel@nongnu.org; Mon, 26 Apr 2010 05:56:56 -0400
Received: by bwz1 with SMTP id 1so15625655bwz.2
	for <qemu-devel@nongnu.org>; Mon, 26 Apr 2010 02:56:54 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <4BD52B13.2040200@redhat.com>
References: <4BBF2E93.3020508@redhat.com> <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>
Date: Mon, 26 Apr 2010 11:56:54 +0200
Message-ID: <z2g632d995a1004260256md9e7d926ja845256b4cf0dac3@mail.gmail.com>
Subject: Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
From: Matthias Bolte <matthias.bolte@googlemail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Avi Kivity <avi@redhat.com>
Cc: Libvirt <libvir-list@redhat.com>, Jiri Denemark <jdenemar@redhat.com>, qemu-devel@nongnu.org

2010/4/26 Avi Kivity <avi@redhat.com>:
>
[...]
>>
>>>> In theory, it does support this with the session urls but they are
>>>> currently second-class citizens in libvirt. =C2=A0The remote dispatch =
also adds a
>>>> fair bit of complexity and at least for the use-cases I'm interested i=
n,
>>>> it's not an important feature.
>>>
>>> If libvirt needs a local wrapper for interesting use cases, then it has
>>> failed. =C2=A0You can't have a local wrapper with the esx driver, for e=
xample.
>>>
>>> This is off-topic, but can you detail why you don't want remote dispatc=
h
>>> (I assume we're talking about a multiple node deployment).
>>
>> Because there are dozens of remote management APIs and then all have a
>> concept of agents that run on the end nodes. =C2=A0When fitting virtuali=
zation
>> management into an existing management infrastructure, you are going to
>> always use a local API.
>
> When you manage esx, do you deploy an agent? =C2=A0I thought it was all d=
one via
> their remote APIs.
>

No, you don't deploy any agents.

If you manage an ESX server using VMware tools only, then you use
VMware management tools on the client PC. This tools directly use the
SOAP based remote API provided by the ESX server.

The ESX driver in libvirt does the same and uses this remote API as
the VMware management tools. No libvirt specific agents are installed
on the ESX server and no VMware specific agents (except libvirt
itself) are installed on the client PC.

Matthias