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

2010/7/26 Daniel P. Berrange <berrange(a)redhat.com&gt;: > 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