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

Matthias Bolte matthias.bolte at googlemail.com
Wed Jul 28 13:22:50 UTC 2010

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


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:



More information about the libvir-list mailing list