[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [Qemu-devel] Re: Libvirt debug API



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.  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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]