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. 1. 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. 2. A scrip that will delete VM's running on a specific host The admin will use these as follows: 1. Invoke the deletion script for the ESX 2. Add the ESX to a VC 3. Invoke the script for importing the OpenStack VM's into the database 4. Start the nova compute with the VC driver 5. 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
