LUN signature after RAID controller replacement

[zairav2]

I have the following scenario:

I got a Cisco UCS server with a LSI controller. I needed to replace the controller for another one, same specs, different model.

I did the physical replacement, powered on the server. ESXi booted fine, but no datastore is showing up. The datastores are on the local hard disk. There is no remote storage.

When I try to re-add the datastore, I got 2 mainly options:

- Keep existing signature

- Assing a new signature.

I'm sure both will work, and I would go with the first one.

However, I would like to know the impact of selecting any of those options. Like, if I resignature, will that be the best since I'm using a new hardware for RAID controller?

Or would it not matter at all if I keep the same signature?

I've beenr reading about these 2 options, and for local storage they don't seem to do any difference, but would like to know somebody else thoughts.

I'm a little afraid of assigning a new signature.

Thanks.

[a_p_ · Accepted solution]

Due to the controller replacement, the ESXi host now recognizes the LUN as a snapshot LUN, because it contains a known signature, but is presented from another controller. Since you can ensure that the LUN is unique, I don't see a requirement for resignaturing it.

André

[zairav2]

Thank you

[jetkins]

Just wanted to add a rider to this answer.  I replaced a Dell PERC 5/i card with a PERC 6/i on my ESXi 5.5 (free) host.  The hardware replacement went flawlessly - the new card detected and accepted the RAID configuration from the drives - and ESXi detected the new controller since it uses the same drivers.  However, the LUN did not mount automatically, and all my guests came up as Unknown (inaccessible).

Like the OP, I was able to mount the LUN manually, and when I did so, I got the same option to retain the old signature or assign a new one.  I opted to retain the signature, and all the guests came back correctly.

Great.  But...

When I rebooted the host, the same thing happened again.  I repeated the process, rebooted, and it happened again.  It seems that ESXi still had it in its head to look for the LUN on the old adapter each time it was rebooted, even after I had manually pointed it to the new adapter.

Eventually, I bit the bullet and selected the option to give the LUN a new signature.  This of course made my existing guests permanently unavailable, and I had to go through and add each one back into the inventory from the datastore browser, and confirm that I had "moved" each of them the first time I fired them up.  Fortunately I only have a handful of guests.

But after importing the guests from the "new" datastore, they are now persistent across reboots, and everything is working as it was before I replaced the controller.  So I guess the moral of the story is that if your RAID controller is an exact like-for-like replacement, you may be able to get away with reusing the same signature, but if not, you may need to give it a new signature and rediscover everything if you want it to survive reboots without manual intervention.

[a_p_]

In order to mount the datastore to be persistent across reboots, you may need to do so from the command line (see http://kb.vmware.com/kb/1011387)

André

[BecauseImGOOD]

I know this is an old thread, but I thought it important to point out that jetkins answer above is really the best answer here.  After a RAID card upgrade, I ran into the exact same problem with having to manually mount the datastore after every reboot, and assigning a new signature fixed this problem.