Hi Raj

I'd like to refer you to NOW KB33990 (which I wrote). It covers this scenario pretty thoroughly. https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb33990

You're mixing two things. LUN identity consists of LUN ID and LUN S/N. The IQN is part of the filer identity. In some versions of ONTAP, when you swap the NVRAM card (or the whole controller including NVRAM) the LUNs may get a new serial number. The IQN should stay the same, provided you use the same root volume. If you configure from scratch, using the root vol from the factory, for example, you will get a new IQN. However, the new IQN is not what triggers VMFS metadata mismatches and resignaturing.

The best way to prevent resignaturing is to make sure the LUNs have the same S/N before and after. Before you shut down the FAS270, get the output of lun show -v, especially the serial numbers. Once you swap controllers, before bringing up ESX, make sure the LUNs have the original S/N.

To maintain the configuration and identity of the FAS270 when you swap, before you boot for the first time remove the new disks (in the FAS2050 chassis) and boot off the old disks. (This assumes you're keeping the FAS270 enclosure as a shelf on the new system.) You'll have to go into maintenance mode to reassign the disks to the new controller(s). Once it boots normally off the old disks, you can reinsert the new disks, clobber the factory aggregates and create new ones, or just destroy the factory root vol. There are other ways to achieve this, but this is one of the most simple.

When using the resignature options in ESX, you only need to set it to 1 on the first ESX server. Once it resignatures the rest of them will see that the metadata matches and will mount just fine on rescan. Set it back to 0 when you're done. However, if you fix the LUN S/Ns from the filer side, you should not have to resignature. If you do resignature, you will have to reregister all of your VMs. There's another trick to fix inaccessible VMs listed at the end of the KB, but you shouldn't need it.

I hope this helps!

Peter Learmonth

-----Original Message----- From: Raj Patel [mailto:phigmov@gmail.com] Sent: Wednesday, October 28, 2009 8:59 PM To: toasters@mathworks.com Subject: Controller upgrade - ESX LUN re-signaturing

Hi all,

We're planning to upgrade our controller (a 270c to a 2050ha) - my understanding is the iSCSI LUN's will retain their identity (ie the existing IQN strings will remain the same) however we will probably run into the ESX re-signaturing issue.

Is there a way to avoid this as part of the controller upgrade or do I need to go into each connected ESX host and change the value of LVM.EnableResignature to 1 ?

Are there any other potential 'gotchas' about an in-place head replacement ? The process itself looks fairly straightforward if all the steps are followed through in sequence.

Thanks in advance, Raj.

I wrote a simple little perl script with automates the process of changing the serial numbers on the luns back to their pre-head upgrade serials, which you can find on the now site here: http://communities.netapp.com/docs/DOC-2369

There is also a vb script one here: http://communities.netapp.com/docs/DOC-1754

which I basically imitated when making my perl version.

Romeo

On Thu, Oct 29, 2009 at 12:58 PM, Raj Patel phigmov@gmail.com wrote:

Hi all,

We're planning to upgrade our controller (a 270c to a 2050ha) - my understanding is the iSCSI LUN's will retain their identity (ie the existing IQN strings will remain the same) however we will probably run into the ESX re-signaturing issue.

Is there a way to avoid this as part of the controller upgrade or do I need to go into each connected ESX host and change the value of LVM.EnableResignature to 1 ?

Are there any other potential 'gotchas' about an in-place head replacement ? The process itself looks fairly straightforward if all the steps are followed through in sequence.

Thanks in advance, Raj.