On Tue, Jul 27, 2010 at 08:39:50PM +0200, Matthias Bolte wrote: > 2010/7/26 Daniel P. Berrange <berrange@xxxxxxxxxx>: > > 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. I guess what I'm getting at this is that libvirt is really providing a per-host level view of virt. When using vCenter I was expecting that it was still scoped to the host. ie just using vCenter as a means to control an individual host, not using vCenter for controlling all hosts at once. If we go for the latter we're turning libvirt into something more like DeltaCloud which I'm not convinced we want todo Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list