Open Stack

Hi Kevin,

Thanks for the contribution.

Shawn from VMware already filed a bp to export those resources
https://blueprints.launchpad.net/nova/+spec/vmware-auto-inventory , but
this bp might some redesign as we need to decide how we will handle
configuration and convention when it comes to vSphere inventory.

Yes, I think that we need support host-node mode for live migration.

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.



2014-04-09 14:07 GMT+08:00 Chen CH Ji <jichenjc at cn.ibm.com>:

> we used to have one compute service corresponding to multiple hypervisors
> (like host and nodes concept )
> 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
> hypervisor management API through REST API
> 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,
> but we have no choice since nova migration only can be migrated to another
> host instead of node ,so we implement according to it
> if we can support host + node, then it might be helpful for the
> hypervisors with different arch
>
> The point is whether we are able to expose the internal (say, not only the
> host concept but also the node concept ) to outside
> guess live-migration is admin only feature, can we expose those node
> concept to admin and let admin decide it?
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM at IBMCN   Internet: jichenjc at cn.ibm.com
> Phone: +86-10-82454158
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
> Beijing 100193, PRC
>
> [image: 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]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 -
>
> From: Jay Lau <jay.lau.513 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>,
> Date: 04/06/2014 07:02 PM
>
> Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live
> migration with one nova compute
> ------------------------------
>
>
>
> Hi Divakar,
>
> 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?
>
> Thanks!
>
>
> 2014-04-06 14:59 GMT+08:00 Nandavar, Divakar Padiyar <
> *divakar.padiyar-nandavar at hp.com* <divakar.padiyar-nandavar at hp.com>>:
>
>    >> 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.
>
>    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
>    "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?
>
>    Thanks,
>    Divakar
>
>
>    -----Original Message-----
>    From: Jay Pipes [mailto:*jaypipes at gmail.com* <jaypipes at gmail.com>]
>    Sent: Sunday, April 06, 2014 2:02 AM
>    To: *openstack-dev at lists.openstack.org*<openstack-dev at lists.openstack.org>
>    Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live
>    migration with one nova compute
>    Importance: High
>
>    On Fri, 2014-04-04 at 13:30 +0800, Jay Lau wrote:
>    >
>    >
>    >
>    > 2014-04-04 12:46 GMT+08:00 Jay Pipes <*jaypipes at gmail.com*<jaypipes at gmail.com>
>    >:
>    >         On Fri, 2014-04-04 at 11:08 +0800, Jay Lau wrote:
>    >         > Thanks Jay and Chris for the comments!
>    >         >
>    >         > @Jay Pipes, I think that we still need to enable "one nova
>    >         compute
>    >         > live migration" as one nova compute can manage multiple
>    >         clusters and
>    >         > VMs can be migrated between those clusters managed by one
>    >         nova
>    >         > compute.
>    >
>    >
>    >         Why, though? That is what I am asking... seems to me like
>    this
>    >         is an
>    >         anti-feature. What benefit does the user get from moving an
>    >         instance
>    >         from one VCenter cluster to another VCenter cluster if the
>    two
>    >         clusters
>    >         are on the same physical machine?
>    > @Jay Pipes, for VMWare, one physical machine (ESX server) can only
>    > belong to one VCenter cluster, so we may have following scenarios.
>    >
>    > DC
>    >  |
>    >
>    >  |---Cluster1
>    >  |      |
>    >
>    >  |      |---host1
>    >  |
>    >
>    >  |---Cluser2
>    >         |
>    >
>    >         |---host2
>    >
>    >
>    > Then when using VCDriver, I can use one nova compute manage both
>    > Cluster1 and Cluster2, this caused me cannot migrate VM from host2 to
>    > host1 ;-(
>    >
>    >
>    > The bp was introduced by
>    >
>    *https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-*<https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed->
>    > by-one-service
>
>    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.
>
>    -jay
>
>
>
>    _______________________________________________
>    OpenStack-dev mailing list
> *OpenStack-dev at lists.openstack.org* <OpenStack-dev at lists.openstack.org>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>    _______________________________________________
>    OpenStack-dev mailing list
> *OpenStack-dev at lists.openstack.org* <OpenStack-dev at lists.openstack.org>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> --
> Thanks,
>
> Jay_______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/61f740b1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/61f740b1/attachment.gif>