
2010/7/27 Matthias Bolte <matthias.bolte@googlemail.com>:
2010/7/26 Daniel P. Berrange <berrange@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