On Sat, Jul 24, 2010 at 09:39:31PM +0200, Matthias Bolte wrote: > 2010/7/19 Daniel Veillard <veillard@xxxxxxxxxx>: > > 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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list