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