phigmov at gmail
Oct 28, 2009, 11:01 PM
Post #3 of 4
(2150 views)
Permalink
|
|
Re: Controller upgrade - ESX LUN re-signaturing
[In reply to]
|
|
Cheers Peter - this looks spot on.
I'll make sure this makes its way into the implementation plan.
Raj.
On 10/29/09, Learmonth, Peter <Peter.Learmonth [at] netapp> wrote:
> 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 [at] gmail]
> Sent: Wednesday, October 28, 2009 8:59 PM
> To: toasters [at] mathworks
> 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.
>
|
