For more details, please see ourCookie Policy.

Fibre Channel (SAN)

Posts: 0

Renaming zones

Hi all,

I am new in this community. Have a question on a SAN switch(model 5300B--fabric os- 6.4.0b) in our env. Hope its relevant.

We had a server named A and zones and LUNs attached as A_alias, A_zone and A_LUN#. We have replaced this with server B few months back and LUNs are now named as B_alias, B_zone, and  B_LUN# etc...

We want to now rename server B as server A and corresponding LUNs and zones same way.

These are the steps that we thought of:

  1. Change the LUN Names
  2. Change the Zone Names in the FC Switch
  3. Deregister the current host B
  4. Register the host as A.

Please let me know if deregistering the host B is reqd or can we proceed directly with renaming without a downtime.


Posts: 0

Re: Renaming zones

How you rename your host and LUN's on the storage array has nothing to do with how and when you rename your zone on the switches.

Preferably they should be the same, but the order in which the renaming happens is of no importance.

To rename aliassen zones etc you can use zoneobjectrename {oldobjectname},{newobjectname} and enable the config.

The procedure to rename hosts and luns on the storage array is differs between vendor and models, most have an user guide or best practice which explains the steps you have to take.

Occasional Contributor
Posts: 8
Registered: ‎08-18-2011

Re: Renaming zones

On Brocade FOS-based SAN, zoning object names are just that - "names". They, by themselves, do not affect the operation of the Fabric itself in any way.*

You can safely change the name of any zoning object - be it alias or zone independently, at any time, and with no impact to production.

As long as your change sticks to (re)naming aliases and/or zones, you have nothing to worry about.

Correct procedure is:

1) make a cup of coffee

2) change object names (does nothing, just places the zoning transaction in a buffer)

3) save into current config (saves the transaction to a file)

4) enable current config (actually implements the transaction by enabling the new config version)

5) drink your coffee

Run 'nszonemember <WWPN>' to see why names really do not matter as far as switch is concerned...

If you do it via CLI, there is pretty much nothing to go wrong (it is imposible to mistype zoneobjectrename into something dangerous :D).

*(not true for LSAN routing, but that is not something you need to worry about)

Join the Broadcom Support Community

Get quick and easy access to valuable resources across the Broadcom Community Network.