|
We tested our SAN Faileover (IBM FAST T DS4800 with remote mirror) .
After a rescan of a newly added LUN with an existing VMFS partition, it is usually not recognized without a reboot of the host.
Somtimes it is presented to the console and is also writable there. But to the rest of the Infrastructure, it doesn't exist or is readonly.
To resolve this issue you have to follow the following steps:
-Stop all VMs that are running on the test/mirror LUN -Stop all I/O to this LUN, including any management agents that may be running in the Service Console
-Remove the mapping of the LUN as before
-changed to role secondary role
-log into VI client -select Datastores view in inventory view
-select the datastore, right click, select remove to remove the old label as this is associated with the source volume
-added the LUN mapping (with the same LUN ID) to the mirrored (now primary) LUN
-changed lvm.disallowSnapshotvolumes to 0
-do a rescan esxcfg-rescan vmhba1
-do a rescan esxcfg-rescan vmhba2
-restart the mgmt-vmware service
-log into VI client
-select Hosts & Clusters view
-in the summary tab, you should see the LUN in the list of datastores
Conclusion:
It is in the current ESX 3.01 release not possible to do an automatic faileover. Even having all the faileover scripts the problem is on the ESX side which still tries to reach the original LUN which will be removed when it fails. also the datastore needs to be removed before adding the secondary LUN.
Special attention needs to by payed to the settings:
lvm.disallowSnapshotvolumes
Be aware if this is set to 0 all snaphot volumes are presented to the host. Even a secondary LUN will be recognized as snapshotvolume. somtimes you might even use such a snapshotvolule without knowing it. The best solution to make shure which volumes are recogniced as snaphots is to set the value to 1 and do a rescan.
Additional information:
VMFS Volume Can Be Erroneously Recognized as a Snapshot VMware KB article
I found this on the forum:
ESX3 ships with a Logical Volume Manager (LVM) that supports automatic volume resignaturing. If you snapshot or replicate a VMFS volume, the LVM can tell the difference between the primary and its copy, hence allowing you to access the snapshot/replica from the same physical host(s) that has access to the primary. We will change the identity of the copy, so that there are no namespace clashes. This is different from ESX2, where all you could do was mount the snapshot on a different ESX server. If you mounted it to the same server as the primary, ESX2 would get confused because there would be 2 volumes with the same identity.
We call this process automatic re-signaturing, because it doesn't require user intervention. Your diskarray should abide by a checklist though, and we will publish all this in detail later. For now, you can see your replica on the second ESX server.
See session material from VMworld: ESX Server 3.0 Tips and Tricks by Mostafa Khalil VMware Support Engineering.
|
