Actually, this is vaguely related to a bug I'm working on right now... * https://bugs.launchpad.net/nova/+bug/1180044 ... the root cause has to do with hosts and inventory hierarchy. That's how these things are related.
The VC (VC short for vCenter) driver as written doesn't seem to respect the tree-like relationship between data-centers, clusters, hosts, and data-stores. The strategy employed by several critical bug fixes we've had over the last few weeks has been to expose less of the vCenter inventory to the OpenStack scheduler. This works for "putting out fires" in the short term as people get quickly working OpenStack + vSphere installs going using this hot-fix strategy... but long-term? We may need to consider a different strategy. This also points to a possible flaw in: https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service ... which currently treats all resources under vCenter as a single large compute node. That is, we expose a single cluster as a compute node per single nova-compute daemon or expose multiple clusters per nova-compute daemon... that in turn effectively "hides" the individual hosts. (See the relationship to bug 1180044 now? That bug deals with the fact that the hosts are all hidden from the scheduler so host_ref location is always "None" and the vCenter errors because there's no location specified when it has multiple locations to choose from!) My current patch attempts to "round-robin" the hosts in a vCenter, but this has caused unintended side-effects I'm attempting to trace. I've opened this bug: https://bugs.launchpad.net/nova/+bug/1192192 please take it over. This is effectively a regression created by our current efforts to answer other critical/high priority issues rapidly. We should be able to support migration targets some how... if our current set of changes are successful I don't see how we'll support this use case. Hopefully, I'm missing something. While I have a fair amount of experience with vSphere's APIs I am still learning OpenStack internals. I'd like to see how to alter the BP I've referenced so we can handle this use case. # Shawn Hartsock, vmware's nova-compute driver maintainer guy ----- Original Message ----- > From: "Roman Sokolkov" <rsokol...@gmail.com> > To: "openstack" <openstack@lists.launchpad.net> > Sent: Tuesday, June 18, 2013 7:05:25 AM > Subject: [Openstack] No idea how to use live-migration with "vmwareapi" > driver. > > Hi, all! > > We are using VMWareVCDriver for our grizzly deployment. Cluster within 4 > ESXi nodes is managed by OpenStack. > > I've found here > <https://wiki.openstack.org/wiki/HypervisorSupportMatrix>that ESX/VC > drivers supports live-migration, also i found related method in > code, it uses vmware API "MigrateVM_Task" function. > > But i couldn't understand how i should use live-migration: > > - standalone ESXi hosts not supports any migration. Therefore > VMWareESXDriver also not supports migration. Correct, if am wrong. > - In case vCenter (VMWareVCDriver) i could use vMotion to migrate VMs > between members of cluster. But nova sees cluster as a single "host" and > thru "nova live-migration VM" scheduler raise exception "NoValidHost: No > valid host was found." > > My question is: What is the use-case of > this<https://github.com/openstack/nova/blob/stable/grizzly/nova/virt/vmwareapi/vmops.py#L1018>function > ? > > -- > Regards, Roman Sokolkov > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
