vDisk UIDs change with firmware updates?

[Jeremy C]

I know the partial answer already: sometimes!

I just upgraded an EVA 5k from VCS 3.028 to 4.110. I have sssu results of "ls vdisk" from before and after the upgrade. The UID of each vdisk changed. This caused problems for VMWare ESX but not physical servers.

On to my question:
Planning a controller upgrade from EVA 5000 to 8100 (XCS 6.220). Is this going to change the UID of vdisks again?

[Uwe Zessin · Accepted solution]

I don't know what you mean by "UID", but the 128-bin "LUN WWN" *should not* have changed.

What definitely has changed is the SCSI inquiry string - the system now claims to be a "HSV111" instead of "HSV110". This is a 'trick' to prevent the old Secure Path for active/passive software from trying to filter paths of the new VCS V4 active/active system. VMware ESX uses this characteristic for its VMFS-3 volume management, too.

If you upgrade from an EVA5000 to EVA8100 the inquiry will _very_ likey change again (to HSV210) which requires work on VMWare ESX (but know you have the experience ;-)

[Patrick Terlisten]

Hello,

the problem is not the LUN ID. It was more the inquiry sting which caused VMware to feel picky about the new firmware. VMware ESX stores the LUN number, the inquiry string and the world-wide LUN ID in the LVM header of a VMFS filesystem when it is created. The UUID (the LVM signature) of an VMFS contains some other data, like creation time, internal time stamp, random number and MAC of the service-console nic. This is the main cause why you should use EnableResignature only if a LUN number is changed. If the inquiry sting changed, you shoud use DisallowSnapshotLun to access the disk. Using EnableResignature will cause a namechange by the datastore. So if you write a new LVM signature to the VMFS, you have to rename the datastore and re-import all VMs. In this case you should fix the error (in most cases changed LUN numbers).

When you change the controllers, you will need to set DisallowSnapshotLun to access the VMFS again.

Best regards,
Patrick

[Uwe Zessin]

> If the inquiry sting changed, you shoud use DisallowSnapshotLun to access the disk

I disagree. DisallowSnapshotLun is a hack for incompetent arrays which have limited LUN mapping capabilies (which does not apply to the EVA) and can be used as a temporary workaround, e.g. in some replication failover scenarios when the inquiry string changes.

I would *NOT* use it as a permanent switch - otherwise you risk data corruption if you ever map a snapshot / cloned copy of a VMFS twice to a server.

[Patrick Terlisten]

> I would *NOT* use it as a permanent switch - otherwise you risk data corruption if you ever map a snapshot / cloned copy of a VMFS twice to a server.

ACK! Thanks for clarification, I agree that this should never be a permanent hack.

Best regards,
Patrick

[Jeremy C]

We ended up doing the Resignaturing thing, renamed datastores, and re-added VMs to inventory. That process took many hours with multiple people. I was hoping for a better way since this is going to happen again. Thanks for the clarification about the controller name changing.