Replacing a SAN LUN Causes ESX Server to Behave Unexpectedly

Details

If your SAN administrator replaces a LUN your ESX Server has access to, the behavior of your ESX Server host depends on whether the replaced LUN is actively used or not.
If the replaced LUN is actively used by your ESX Server system, the ESX Server system and its virtual machines act in an unpredictable manner, and the ESX Server log file reports the following critical error:
Warning "The physical media represented by vmhba1:0:0 has changed."
"The device cannot be re-synchronized with the system."
"This is a critical error."
There is no solution in this case.
If the storage administrator removes a LUN that is not actively used by your ESX Server system and then later creates a new LUN with the same LUN #, you can use your ESX Server system to access the new LUN and format it with a VMFS datastore. After the server is rebooted, the system will treat the new LUN as a snapshot and will not be able to mount the VMFS datastore created on this LUN. To resolve this issue, you need to resignature the VMFS datastore.

Solution

For Resignaturing specific issues, see Resignaturing VMFS3 volumes that are not snapshots 9453805.

 

To enable volume resignaturing, follow this procedure:

1. In the VI Client, select the host in the inventory panel.
2. Click the Configuration tab and click Advanced Settings.
3. Select LVM in the left panel, and set the LVM.EnableResignature option to 1.
4. Rescan for any new LUNs or VMFS volumes. Volumes that are detected to be snapshots or replicas are resignatured.
5. Set the LVM.EnableResignature option to 0 after resignaturing is complete.
6. Rename the VMFS datastore to its original name.

VMware recommends that you vacate the ESX Server system and reboot it before creating a VMFS datastore if you are aware in advance of the LUN changes of this type. This prevents unexpected behavior.