SAN VMFS resignature

SAN VMFS resignature

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)?

TIA.


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".


Hello,

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:

Thank you for your help !


This document was generated from the following thread: SAN VMFS resignature

Version history
Revision #:
1 of 1
Last update:
‎04-21-2008 01:05 AM
Updated by: