CPI does not pay attention to ESXI servers disconnected or in maintenance mode about bosh-vsphere-cpi-release HOT 4 CLOSED

@jriguera to confirm, cpi ends up selecting local datastore connected to a host that's in the maintenance mode, which leads vm scheduled on that host, and hence a failure? we can definitely look into possibility of filtering out such datastores.

from bosh-vsphere-cpi-release.

@cppforlife Yep, that is exactly the use case, we use a pattern to select the datastores where we want to have the vms running. I would love if the cpi has the functionality to skip a server if it is in maintenance mode, when a vm needs to be deployed. About the logic to implement when a vm is already deployed (in order to delete the ephemeral disks), I am not sure, but I think the proper way is just fail and tell the user that the vm is on a server which is in maintenance.

For now, the way to deal with hardware failures (we do not use DRS/vmotion because we use local SSDs) is taking out of the VCenter cluster the failed server, but people who manages the VMware platform do not like this solution.

I can provide more details if you wish.

Thanks!

from bosh-vsphere-cpi-release.

From my understanding, one possible implementation would be add a filter to this function https://github.com/cloudfoundry-incubator/bosh-vsphere-cpi-release/blob/7fb6677a6a8dd9d4221dd57c171c9b0932d152fb/src/vsphere_cpi/lib/cloud/vsphere/vm_creator.rb#L23 ; a filter like https://github.com/cloudfoundry-incubator/bosh-vsphere-cpi-release/blob/5ea37ac72ee6da4b2e260af8590cd78326e02374/src/vsphere_cpi/lib/cloud/vsphere/resources/cluster.rb#L123

But for each datastore, has to retrieve all server where such datastore is available and apply the filter. Other implementation would be check the server once the datastore is known.

from bosh-vsphere-cpi-release.

Fixed in version 46.

from bosh-vsphere-cpi-release.