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

[Matthias Bolte]

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>

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