We have 4 VI3 Servers, an IBM DS4000 Storage system. The DS4000 presents two VM LUN's (VMs, and VMs2) with the same LUN ID to all 4 VI3 Servers. All 4 VI3 Servers can see the VMs LUN, but only 2 can se the VMs2 LUN. This has not always been the case, only since our last power outage.
My query relates to what a resignature will actually do. If I resignature on one of the VI3 Servers that connot see the VMs2 LUN, I believe it will get renamed from VMs2 to something like SNAP-x-VMs2. Here come the questions...
1. Is it a simple matter of renaming the SNAP-x-VMs2 directory back to VMs2? (to save amending all the .vmx files to point to the SNAP-x-VMs2 directory)
2. If I resignature the 2 failing VI3 Servers, this should have no undesirable effect on the 2 working VI3 Servers, and their VM's?
3. Do I have to resignature both the failing VI3 Servers or will the effects of performing the resignature on one, update the other (I assume through either VC or a rescan on the other VI3 Server)?
iseau wrote: If I resignature the 2 failing VI3 Servers, this should have no undesirable effect on the 2 working VI3 Servers, and their VM's?
Do I have to resignature both the failing VI3 Servers or will the effects of performing the resignature on one, update the other (I assume through either VC or a rescan on the other VI3 Server)? The mechanism VMFS uses to share disc safely between ESX hosts relies on a set of information (the signature) written on the volumes LVM header which is essentially the SCSI Disk ID data from the LUN/storage array. The ‘signature' is created when VMFS partition is created and the storage is added to the first ESX server. If the LUN is ‘shared' to a second ESX using the same LUN, a rescan of the HBA will force the second ESX to read the ‘signature'.If the signature matches the SCSI Disk ID information returned from the storage array it is assumed that this is a shared ESX volume, the volume is presented to the ESX and normal operation resumes. The interesting stuff happens when the signature doesn't match.
There are number of reasons why this might be.
First the device might be shared with a different SCSI ID. This might be due to a simple mistake in the array config. You thought the LUN is the same but it isn't. In this case the second ESX will protect the volume by refusing to present it. However you will see errors appearing in the /var/log/vmkernel file to the effect that vmhbax:x:x:x may be snapshot: disabling access
Now you can see what might happen if you make a mistake on the LUN assignment and then attempt to resign the drive to make it visible on the new host. The effect will be to invalidate the volume on all other ESX hosts as the signature and the LUN assigned don't match. If the DisallowSnapshotLUN =1 they will not present themselves to the ESX.
I guess the best bet is always try and troubleshoot the problem to try and find out why the signature doesn't match the SCSI Disk ID before messing with the switches to get a workaround.
I agree - troubleshoot first. The resignature bit isn't as simple as many sources make it out to be.
Any virtual machines that are registered on that volume will become "unknown" to ESX. To correct this, you can amend /etc/vmware/hostd/vmInventory.xml on each host by replacing the 32-character GUID of the old volume with that of the new volume.
Additionally, you will need to amend the VMX file for each VM that has a disk that is NOT on the same volume as the VMX (such as a secondary data disk.) The primary data disk is usually on the same volume as the VMX and will not be affected.
Finally, each snapshot refers to its parent disk by the same 32-digit GUID if the delta files and parent files are not on the same volume. This starts treading into dangerous territory, but if you have snapshots like that, you can amend the VMDK for the snapshot to point to the correct volume. I've done this before, but wouldn't count on support from anyone if the process went wrong.
The important part (should you decide to resignature) is to ensure you have a dump of the GUIDs before and after the resignature. Place this into a table so that you have an accurate record to refer to when you do the actual changes (using sed, vi, whatever.)
A simple way of getting a mapping of GUIDs to datastore names is to "ls -l /vmfs/volumes".
I met the problem with a VMFS replica: vmware recomands to set the option enableresignature to 0 after we managed to mount our replica.
Please, could someone explain me why do we need to reset this option enableresignature to 0 ? What is the risk to let enable the resignature ?
Second, there is something I don't understand: normaly, our replica VMFS (we used mirroview) owns the same signature of my primary LUN so why do we have to enable the resignature to see the LUNS in the storage ?? :smileyconfused: