Open Stack

Shawn,

Thanks for the unfurled answer and the
bug<https://bugs.launchpad.net/nova/+bug/1192192>.
We follow vmware driver development and ll try to help.

2013/6/18 Shawn Hartsock <hartsocks at vmware.com>

> 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" <rsokolkov at gmail.com>
> > To: "openstack" <openstack at 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 at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
>



-- 
Regards, Roman Sokolkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130619/64ffef42/attachment.html>