2010/7/28 Daniel P. Berrange <berrange@xxxxxxxxxx>: > 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 > I think you're right, a vpx:// connection that covers a whole vCenter is probably out of libvirt's scope and gives much trouble with stuff like name uniqueness etc. I'm going to restrict a vpx:// connection to a single host for now: vpx://example-vcenter.com/datacenter1/cluster1/hostsystem1 This solves all name uniqueness issues and it allows to resolve remaining no-host-for-vpx-connection-todos in the driver. This way we don't have a feature in 0.8.3 that might need to be restricted in later version. Once we have a single-host-vpx-connection I'd like to investigate if it's feasible to relax the restrictions on a vpx:// in a way that allows to manage a single cluster too. Internally the driver would always manage (Cluster-)ComputeResources then. The URI for such a connection would omit the host part: vpx://example-vcenter.com/datacenter1/cluster1 Matthias -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list