DataStore conflicts with an existing DataStore in the DataCenter – Manually disabling Storage I/O Control
I ran into this issue yesterday while reconnecting hosts in our vCenter Server following a complete reinstall - the reasons for which are a long story, but suffice to say that there were new certificates and the host passwords were encrypted with the old ones.
The LUNs had been unpresented at the hardware level by the storage team, but had not been unmounted or removed from vCenter. This is *not* the way to remove storage - let me re-iterate: remove storage properly. Unfortunately in this case the storage was removed badly - doing this can lead to a condition called "All Paths Down" or APD which is best explained by Cormac Hogan (@vmwarestorage) in the article Handling the All Paths Down (APD) condition.
Simply because of the size and age of the environment, some of our production clusters have now reached the limit (including local paths) - you see this message in the logs
[2012-08-20 01:48:52.256 77C3DB90 info 'ha-eventmgr'] Event 2003 : The maximum number of supported paths of 1024 has been reached. Path vmhba3:C0:T4:L0 could not be added.
Recently I installed and configured a client’s new ESXi host, they’re a small company and only require a single host. The host in question was an IBM x3650 M3, an excellent workhorse for virtualisation and one of 5 or 6 of the same model that I’ve installed in the last year. In addition to the onboard Broadcom Dual Gigabit NIC, we always install at least a second Intel PCIx Dual Gigabit card for resilience/redundancy/performance.
Recently I had cause to configure iSCSI multipathing on a test ESXi server. The production environment servers use iSCSI HBAs to connect to the back end storage, so multipathing them is a straight-forward setup.