[libvirt] [PATCH] esx: Add vpx:// scheme to allow direct connection to a vCenter

[Matthias Bolte]

2010/7/27 Matthias Bolte <matthias.bolte at googlemail.com>:
> 2010/7/26 Daniel P. Berrange <berrange at redhat.com>:
>> On Mon, Jul 19, 2010 at 01:26:10AM +0200, Matthias Bolte wrote:
>>> Add a pointer to the primary context of a connection and use it in all
>>> driver functions that don't dependent on the context type. This includes
>>> almost all functions that deal with a virDomianPtr. Therefore, using
>>> a vpx:// connection allows you to perform all the usual domain related
>>> actions like start, destroy, suspend, resume, dumpxml etc.
>>>
>>> Some functions that require an explicitly specified ESX server don't work
>>> yet. This includes the host UUID, the hostname, the general node info, the
>>> max vCPU count and the free memory. Also not working yet are migration and
>>> defining new domains.
>>
>>
>> If you're connecting to vpx://example-vcenter.com  how does the driver
>> know which host you're asking for data on ? IIUC a vcenter reports on all
>> hosts in a data center. Does new mode still guarentee that every domain
>> has a unique name & ID, as well as UUID ?
>>
>
> UUID is unique by definition.
>
> The driver parses the ID from the internal object name. As far as I
> understand the object model this ID is unique. But the ID might be
> different if you look at the same guest through a esx:// or vpx://
> connection, but it's unique per connection.
>
> The name is a bit more tricky. For a single ESX server it's unique. I
> thought for a vCenter it's unique per datacenter, because the vCenter
> won't let you define a second guest with an existing name. I just
> played a bit with it and it seems there are ways to define two domains
> with the same name in a single cluster. This is definitely a problem
> and I'm not sure how to fix that, other than using hacks like adding
> the ID to the name.
>
> In order to have a guaranteed unique domain name for a vpx://
> connection the final name will probably have to be build like this
>
>  <datacenter-name>/<cluster-name>/<domain-name>-<domain-id>

Actually adding the domain ID should be enough

  <domain-name>-<domain-id>

> Quite ugly and unstable, because it'll change across a migration :(
>
> The same name uniqueness problem exists for datastores, because their
> names are unique per datacenter only.
>
> Matthias
>