+1 to Option #2. -- dims
On Sun, Jun 15, 2014 at 11:15 AM, Gary Kotton <gkot...@vmware.com> wrote: > Hi, > In the Icehouse cycle it was decided to deprecate the VMware ESX driver. The > motivation for the decision was: > > The driver is not validated by Minesweeper > It is not clear if there are actually any users of the driver > > Prior to jumping into the proposal we should take into account that the > current ESX driver does not work with the following branches: > > Master (Juno) > Icehouse > Havana > > The above are due to VC features that were added over the course of these > cycles. > > On the VC side the ESX can be added to a cluster and the running VM’s will > continue to run. The problem is how that are tracked and maintained in the > Nova DB. > > Option 1: Moving the ESX(s) into a nova managed cluster. This would require > the nova DB entry for the instance running on the ESX to be updated to be > running on the VC host. If the VC host restarts at point during the above > then all of the running instances may be deleted (this is due to the fact > that _destroy_evacuated_instances is invoked when a nova compute is started > https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L673). > This would be disastrous for a running deployment. > > If we do decide to go for the above option we can perform a cold migration > of the instances from the ESX hosts to the VC hosts. The fact that the same > instance will be running on the ESX would require us to have a ‘noop’ for > the migration. This can be done by configuration variables but that will be > messy. This option would require code changes. > > Option 2: Provide the administrator with tools that will enable a migration > of the running VM’s. > > A script that will import OpenStack VM’s into the database – the script will > detect VM’s running on a VC and import them to the database. > A scrip that will delete VM’s running on a specific host > > The admin will use these as follows: > > Invoke the deletion script for the ESX > Add the ESX to a VC > Invoke the script for importing the OpenStack VM’s into the database > Start the nova compute with the VC driver > Terminate all Nova computes with the ESX driver > > This option requires the addition of the scripts. The advantage is that it > does not touch any of the running code and is done out of band. A variant of > option 2 would be to have a script that updates the host for the ESX VM’s to > the VC host. > > Due to the fact that the code is not being run at the moment I am in favor > of the external scripts as it will be less disruptive and not be on a > critical path. Any thoughts or comments? > > Thanks > Gary > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: http://davanum.wordpress.com _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev