Help - Change Service Profile templates and policies without changing the existing MAC or WWN on vNICs and vHBAs

[dlitinfraserver]

Hi,

I would like to know if there is a way to preserve existing vNIC MACs and vHBA WWNs if I change a Service Profile's template?

To clarify, our Service Profiles have been created from an initial-template, and now we would like these Service Profiles to point to an updating-template - to simplify management.

The original inital-template included manually created vNICs and vHBAs and did not use LAN or SAN Connectivity Policies, but the new updating-template does.

The vNIC names and vHBA names, as well as the MAC and WWN pools used in the updating-template's Connectivity Policies are the same as the ones currently being used by the Service Profiles.

To rephrase the question:
Is there a way to change a Service Profile's initial-template to an updating-template that has mostly the same of everything, without changing the Service Profile's currently in-use MACs, WWNs, and maybe the UUID?
If the answer is that they don't stay the same when this happens, then does anyone know of any workarounds?

Thanks for your help!

RR

[Walter Dey]

Hi RR

I've done this; and it's not easy.

I hope your pools (UUID, mac, pwwn and nwwn) use sequential allocation.

Fact is: as long as a SP exists (idle, or assoicated), all pool values are reserved. You can even delete a pool and it will keep the reserved values.

Lets say you have SP1-IT (inital template), SP2-IT, SP3-IT, SP4-IT.

If this would be eg. a VMware cluster, do the following sequence

- Bring ESXi associated with SP1-IT to maintenance mode

- Turn ESXi SP1-IT off

- Disassociate SP1-IT, which will free up all the pool items

- Create the new SP1-UT (which will inherit the previous pool values)

- associate SP1-UT

- take this ESXi out of maintenance mode

.......

repeat this sequence one by one.

Walter.

[dlitinfraserver]

Thanks for the info Walter.

This is all done in UCS Central, so pool sequential allocation is not supported (yet?).

If I understand you correctly, you are saying that I can unbind the initial-template from the SP, the MACs and WWNs will be preserved. Next, if I then bind the SP to a new updating-template that has the same vnic/vhba names and mac/wwn pools as the previously used initial-template, then the preserved MAC/WWN values will be reused, so ultimately there is nothing to worry about?

To clarify, this is the situation:

Old Template (initial):
vNICs - vnic01(mac_poolA), vnic02(mac_poolB)
vHBAs - vhba01(wwpn_poolA), vhba02(wwpn_poolB)

New Template (updating):
vNICs - LAN Connectivity Policy
vHBAs - SAN Connectivity Policy

LAN Connectivity Policy - vnic01(mac_poolA), vnic02(mac_poolB)
SAN Connectivity Policy - vhba01(wwpn_poolA), vhba02(wwpn_poolB)

As we can see, the vnics and vhbas in the LAN Connectivity Policies used by the new updating-template are identical to the manually configured ones in the old initial-template.
In this case, would the MACs and WWNs still stay the same?
My main concern here is that the new template uses Connectivity Policies but the old one does not.

Thank you again.

RR

[Walter Dey · Accepted solution]

Hi RR

Regarding UCS Central and sequential allocation:

https://supportforums.cisco.com/discussion/12006286/ucs-central-sequential-pool-assignment

http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/RN-CiscoUCSCentral_1-1.html
New Software Features in Release 1.1(2a)
 
Sequential ID allocation for pools, such as MAC addresses, WWNs, Management IP, and UUIDs

The procedure I would use:

- Create updating template

- unbind 1. SP from inital template

- delete this 1. SP (this will release all pool values)

- create new SP from updating template (this will inherit above pool values)

- repeat this for all SP's

I have done this several times without problems (e.g. no need to change FC zoning). Of course it's disruptive, per blade and SP.

No sure if this unbind / bind procedure works without caveats.

Cheers

Walter.

[dlitinfraserver]

Hi Walter,

Thanks for your suggestions. We will give them a try.

RR

[dlitinfraserver]

We tested and observed the following:

1. Unassociate SP with the initial-template. SP still keeps all the vnics+MACs and vhbas+WWNs.
Note: SP's vnics and vhbas were all manually added, and not using Connectivity Policies.

2. Associate SP with a new updating-template.
Note: This update-template uses updating vnic and vhba Connectivity Policies. The vnic and vhba list, names, mac/wwn pools used in the Connectivity Policies match those of the SP's existing vnic and vhba lists exactly.

3. SP is now using the updating-template. vnics and vbhas are now based on Connectivity Policies. The list of vnics+MACs and vhbas+WWNs are all kept the same as before the unassociation of the initial-template. Goal achieved.

Thanks all,

RR

[Walter Dey]

Hi RR

Good to hear about the success.

Can you please clarify ! I think you mean

1) unbind (not unassociate) SP ....

2) bind (not associate) SP ...

Walter.

[dlitinfraserver]

Hi Walter,

Yes, you are correct on both accounts.

I wish they had put this method in the guides.

Regards,

RR