2010/7/28 Daniel P. Berrange <berrange@redhat.com>:
On Tue, Jul 27, 2010 at 08:39:50PM +0200, Matthias Bolte wrote:
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>
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