<div dir="ltr"><div><div><div>Hi Kevin,<br><br></div>Thanks for the contribution.<br><br></div>Shawn from VMware already filed a bp to export those resources <a href="https://blueprints.launchpad.net/nova/+spec/vmware-auto-inventory">https://blueprints.launchpad.net/nova/+spec/vmware-auto-inventory</a> , but this bp might some redesign as we need to decide how we will handle configuration and convention when it comes to vSphere inventory. <br>
<br></div>Yes, I think that we need support host-node mode for live migration.<br><br>Divakar give some idea of "Parent - Child compute" mode, I'm just wondering what is the difference of this mode with bare-metal "host-node" mode.<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-09 14:07 GMT+08:00 Chen CH Ji <span dir="ltr"><<a href="mailto:jichenjc@cn.ibm.com" target="_blank">jichenjc@cn.ibm.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p><font face="sans-serif">we used to have one compute service corresponding to multiple hypervisors (like host and nodes concept )</font><br>
<font face="sans-serif">our major issue on our platform is we can't run nova-compute service on the hypervisor and we need to find another place to run the nova-compute in order to talk to </font><br>
<font face="sans-serif">hypervisor management API through REST API </font><br>
<font face="sans-serif">which means we have to run multiple compute service out side of our hypervisors and it's hard for us to control the compute services at that time,</font><br>
<font face="sans-serif">but we have no choice since nova migration only can be migrated to another host instead of node ,so we implement according to it</font><br>
<font face="sans-serif">if we can support host + node, then it might be helpful for the hypervisors with different arch</font><br>
<br>
<font face="sans-serif">The point is whether we are able to expose the internal (say, not only the host concept but also the node concept ) to outside</font><br>
<font face="sans-serif">guess live-migration is admin only feature, can we expose those node concept to admin and let admin decide it?</font><br>
<br>
<font face="sans-serif">Best Regards! <br>
<br>
Kevin (Chen) Ji ¼Í ³¿<br>
<br>
Engineer, zVM Development, CSTL<br>
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: <a href="mailto:jichenjc@cn.ibm.com" target="_blank">jichenjc@cn.ibm.com</a><br>
Phone: +86-10-82454158<br>
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC </font><br>
<br>
<img src="cid:1__=C7BBF626DFB33F9E8f9e8a93df938@cn.ibm.com" alt="Inactive hide details for Jay Lau ---04/06/2014 07:02:15 PM---Hi Divakar, Can I say that the bare metal provisioning is now usi" border="0" height="16" width="16"><font color="#424282" face="sans-serif">Jay Lau ---04/06/2014 07:02:15 PM---Hi Divakar, Can I say that the bare metal provisioning is now using kind of "Parent -</font><br>

<br>
<font color="#5F5F5F" face="sans-serif" size="1">From:      </font><font face="sans-serif" size="1">Jay Lau <<a href="mailto:jay.lau.513@gmail.com" target="_blank">jay.lau.513@gmail.com</a>></font><br>
<font color="#5F5F5F" face="sans-serif" size="1">To:        </font><font face="sans-serif" size="1">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, </font><br>

<font color="#5F5F5F" face="sans-serif" size="1">Date:      </font><font face="sans-serif" size="1">04/06/2014 07:02 PM</font></p><div class=""><br>
<font color="#5F5F5F" face="sans-serif" size="1">Subject:   </font><font face="sans-serif" size="1">Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute</font><br>
</div><hr style="color:#8091a5" align="left" noshade size="2" width="100%"><div><div class="h5"><br>
<br>
<br>
<font face="serif" size="3">Hi Divakar,<br>
</font><br>
<font face="serif" size="3">Can I say that the bare metal provisioning is now using kind of "Parent - Child compute" mode? I was also thinking that we can use host:node to identify a kind of "Parent-Child" or "Hierarchy Compute". So can you please show some difference for your "Parent - Child Compute Node" and bare metal provisioning?<br>

</font><br>
<font face="serif" size="3">Thanks! </font><br>
<font face="serif" size="3"><br>
</font><br>
<font face="serif" size="3">2014-04-06 14:59 GMT+08:00 Nandavar, Divakar Padiyar <</font><a href="mailto:divakar.padiyar-nandavar@hp.com" target="_blank"><font color="#0000FF" face="serif" size="3"><u>divakar.padiyar-nandavar@hp.com</u></font></a><font face="serif" size="3">>:</font>
<ul style="padding-left:9pt"><font face="serif" size="3">>> Well, it seems to me that the problem is the above blueprint and the code it introduced. This is an anti-feature IMO, and probably the best solution would be to remove the above code and go back to having a single >> nova-compute managing a single vCenter cluster, not multiple ones.<br>

</font><br>
<font face="serif" size="3">Problem is not introduced by managing multiple clusters from single nova-compute proxy node.  Internally this proxy driver is still presenting the "compute-node" for each of the cluster its managing.    What we need to think about is applicability of the live migration use case when a "cluster" is modelled as a compute.   Since the "cluster" is modelled as a compute, it is assumed that a typical use case of live-move is taken care by the underlying "cluster" itself.       With this there are other use cases which are no-op today like host maintenance mode, live move, setting instance affinity etc.,     In order to resolve this I was thinking of<br>

"A way to expose operations on individual ESX Hosts like Putting host in maintenance mode,  live move, instance affinity etc., by introducing Parent - Child compute node concept.   Scheduling can be restricted to Parent compute node and Child compute node can be used for providing more drill down on compute and also enable additional compute operations".    Any thoughts on this?<br>

<br>
Thanks,<br>
Divakar</font><br>
<font face="serif" size="3"><br>
<br>
-----Original Message-----<br>
From: Jay Pipes [mailto:</font><a href="mailto:jaypipes@gmail.com" target="_blank"><font color="#0000FF" face="serif" size="3"><u>jaypipes@gmail.com</u></font></a><font face="serif" size="3">]<br>
Sent: Sunday, April 06, 2014 2:02 AM<br>
To: </font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><font color="#0000FF" face="serif" size="3"><u>openstack-dev@lists.openstack.org</u></font></a><font face="serif" size="3"><br>
Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute<br>
Importance: High<br>
<br>
On Fri, 2014-04-04 at 13:30 +0800, Jay Lau wrote:<br>
><br>
><br>
><br>
> 2014-04-04 12:46 GMT+08:00 Jay Pipes <</font><a href="mailto:jaypipes@gmail.com" target="_blank"><font color="#0000FF" face="serif" size="3"><u>jaypipes@gmail.com</u></font></a><font face="serif" size="3">>:<br>

>         On Fri, 2014-04-04 at 11:08 +0800, Jay Lau wrote:<br>
>         > Thanks Jay and Chris for the comments!<br>
>         ><br>
>         > @Jay Pipes, I think that we still need to enable "one nova<br>
>         compute<br>
>         > live migration" as one nova compute can manage multiple<br>
>         clusters and<br>
>         > VMs can be migrated between those clusters managed by one<br>
>         nova<br>
>         > compute.<br>
><br>
><br>
>         Why, though? That is what I am asking... seems to me like this<br>
>         is an<br>
>         anti-feature. What benefit does the user get from moving an<br>
>         instance<br>
>         from one VCenter cluster to another VCenter cluster if the two<br>
>         clusters<br>
>         are on the same physical machine?<br>
> @Jay Pipes, for VMWare, one physical machine (ESX server) can only<br>
> belong to one VCenter cluster, so we may have following scenarios.<br>
><br>
> DC<br>
>  |<br>
><br>
>  |---Cluster1<br>
>  |      |<br>
><br>
>  |      |---host1<br>
>  |<br>
><br>
>  |---Cluser2<br>
>         |<br>
><br>
>         |---host2<br>
><br>
><br>
> Then when using VCDriver, I can use one nova compute manage both<br>
> Cluster1 and Cluster2, this caused me cannot migrate VM from host2 to<br>
> host1 ;-(<br>
><br>
><br>
> The bp was introduced by<br>
> </font><a href="https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-" target="_blank"><font color="#0000FF" face="serif" size="3"><u>https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-</u></font></a><font face="serif" size="3"><br>

> by-one-service<br>
<br>
Well, it seems to me that the problem is the above blueprint and the code it introduced. This is an anti-feature IMO, and probably the best solution would be to remove the above code and go back to having a single nova-compute managing a single vCenter cluster, not multiple ones.<br>

<br>
-jay<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list</font><font color="#0000FF" face="serif" size="3"><u><br>
</u></font><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank"><font color="#0000FF" face="serif" size="3"><u>OpenStack-dev@lists.openstack.org</u></font></a><font color="#0000FF" face="serif" size="3"><u><br>

</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font color="#0000FF" face="serif" size="3"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font face="serif" size="3"><br>

<br>
_______________________________________________<br>
OpenStack-dev mailing list</font><font color="#0000FF" face="serif" size="3"><u><br>
</u></font><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank"><font color="#0000FF" face="serif" size="3"><u>OpenStack-dev@lists.openstack.org</u></font></a><font color="#0000FF" face="serif" size="3"><u><br>

</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font color="#0000FF" face="serif" size="3"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a></ul>

<font face="serif" size="3"><br>
<br>
<br>
-- </font><br>
<font face="serif" size="3">Thanks,<br>
</font><br>
</div></div><font face="serif" size="3">Jay</font><tt><font>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
</font></tt><tt><font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font><br>
</font></tt><br>
<p></p></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Thanks,<br><br></div>Jay<br></div>
</div>