To maintain the same
ID for local service profiles, while migrating to global ID pools, construct
the global ID pools so that they are supersets of the corresponding local ID
pools. This means that the global ID pool contains all identifier blocks that
are currently within the local ID pools.
The best practice is
to adopt an A/B naming orientation for MAC and WWPN pools for the fabric, such
as G-MAC-A or G-WWPN-B. Once you have created the global ID pools, you can
change the service profile, VNIC, VHBA, or template to reference the global ID
pools.
Cisco UCS Central automatically assigns the same identifier that was previously used
in the local ID pool, if not already assigned, thus eliminating the need for a
service interruption.
When the ID space is
already partitioned and not overlapping, adopt as follows:
-
Create a new
global ID pool in
Cisco UCS Central with a unique name. Use
Global- or
G- for the
pool-name prefix. For MAC and WWPN pools, add an
-A or
-B suffix
to the pool name, if desired.
![](/c/dam/en/us/td/i/templates/note.gif) Note |
For MAC pools,
the Network Administrator always sees A and B MACs intermeshed on the network
upstream. This is because
Cisco UCS Central clusters the upstream connectivity from the FIs to the aggregation
layer-2, TOR (top of rack), EOR (end of row) switch.
|
-
For each local
ID block in the local pool, recreate a corresponding ID block in the global
pool.
-
Change any
existing templates (service profiles, VNICs, and VHBAs) to refer to the
corresponding global ID pool name.
-
Change the Pool
reference from local to global. Perform a
Reset
MAC/WWxN/UUID Address on the specific instantiated managed object
to effect the global ownership change.
-
Verify that the
corresponding local ID block has no assignments.
-
Verify, through
ID usage, that the address now references a global pool.
-
Delete the
corresponding local ID block for each local ID block in the local pool.
For VNICs, or VHBAs,
created from initial templates, once the IDs reference the global ID pools,
then all subsequently created managed objects reference the new global ID
pools.
For VNICs, or VHBAs,
that are bound to updating templates, once the IDs reference the global ID
pools, then all existing managed objects bound to the template reference the
new global ID pools. If the existing managed object’s ID is present and
unassigned in the global pool, then this transition does not cause a
reconfiguration, reboot, or service impact.
For VNICs, or VHBAs,
that are not bound to a template, if the service profile pool name is modified
to point to a global pool, and the existing ID is already used in the global
pool, then the service profile receives a new ID, causing a reconfiguration,
reboot, and service impact. If the ID is not already used, then the ID is
retained and points to the global pool, without incurring a reconfiguration or
service impact.
You can also manage
IP addresses for ext-mgmt and iSCSI initiators through global pools.