On Sat, Jul 24, 2010 at 09:39:31PM +0200, Matthias Bolte wrote:
2010/7/19 Daniel Veillard <veillard@redhat.com>:
On Mon, Jul 19, 2010 at 01:26:10AM +0200, Matthias Bolte wrote:
@@ -49,9 +51,9 @@ esx://example.com/?no_verify=1 (ESX over HTTPS, but doesn't verify the serve type://[username@]hostname[:port]/[?extraparameters]
May I suggest a small extra sentence here, explaining how to compose extraparameters ? User may find from lookuing above that they need to use:
arg=value
but there is no indication on how to separate multiple parameter.
That's true. I'll add a sentence or two about that.
Cool, thanks !
I feel ignorant here. I would assume that a vpx:// connection being to a vCenter vould allow to migrate, care to explain :-) ?
It will, but migration is tricky. Some more details first:
An ESX server has one Datacenter, this Datacenter contains one ComputeResource and this ComputeResource has a single HostSystem attached. Migration is performed between HostSystems in general. Given two ESX connections the driver can easily determine the two involved HostSystems.
A vCenter server can have multiple Datacenters, each Datacenter can contain multiple ComputeResources. There also might by a special type of ComputeResources, the ClusterComputeResource. A ClusterComputeResource may have multiple HostSystems attached. To make it more complex there is DRS. If DRS is enabled for a ClusterComputeResource then the vCenter server will automatically control the VirtualMachine to HostSystem mapping. In that case you can migrate between ClusterComputeResources and the vCenter will select the destination HostSystem for you.
But with the current vpx:// URI you specify the vCenter only, you don't specify the Datacenter or the ComputeResource or the HostSystem yet. Therefore, migration using a vpx:// URI doesn't work yet and I simply short-circuited the VMotion check for a vpx:// connection for now, effectively disabling migration for vpx:// connections.
I plan to model the Datacenter/ComputeResource/HostSystem selection via the path part of the URI: vpx://example-vcenter.com/datacenter1/cluster1/hostsystem1
This allows to omit the HostSystem part in case cluster1 has DRS enabled.
Migration is a complex topic, I decided to solve it with a later patch and to do the simple things first :)
Okay, I didn't expect that level of complexity, but that's normal, we are reaching the limits of teh libvirt level, not talking just to an hypervisor but to a management system, with the DRS implementing user policies instead of the app managing the software. Maybe we could extend virDomainMigrateToURI() to allow a NULL URI in such case where migration target can be decided by the hypervisor. But that would have to be exported in the capabilities first.
[...]
@@ -2173,6 +2283,7 @@ esxDomainDumpXML(virDomainPtr domain, int flags) }
esxVI_String_Free(&propertyNameList); + esxVI_ObjectContent_Free(&datacenter); esxVI_ObjectContent_Free(&virtualMachine); VIR_FREE(datastoreName); VIR_FREE(directoryName);
I'm a bit suspicious, I see no virFree(datacenterName) here ... normal ?
Yes, it's obtained via esxVI_GetStringValue from the datacenter object. The datacenter object owns the string and the string will be freed when the datacenter object gets freed via esxVI_ObjectContent_Free(&datacenter).
okay
Okay, overall a very large part of the patch is the change from priv->host to priv->primary, and there is still some TODOs without an error, I assume they will get fixed soon,
The "TODOs without an error" are the places where I decided to solve the complexer parts in a separate patch later and to do the simple things first.
okay, understood, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/