2010/4/26 Avi Kivity <avi(a)redhat.com>:
[...]
>
>>>> In theory, it does support this with the
session urls but they are
>>>> currently second-class citizens in libvirt. The remote dispatch also
adds a
>>>> fair bit of complexity and at least for the use-cases I'm interested
in,
>>>> it's not an important feature.
>>
>>> If libvirt needs a
local wrapper for interesting use cases, then it has
>>> failed. You can't have a local wrapper with the esx driver, for
example.
>>
>>> This is off-topic, but
can you detail why you don't want remote dispatch
>>> (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. When fitting virtualization
>> management into an existing management infrastructure, you are going to
>> always use a local API.
> When you manage esx, do you deploy an agent? I thought it
was all done 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