We had the same issue, 2 of our 40 domains were registered to Central’s IP address with all SPs on these domains living in Central. If your SPs are local, or you don’t mind them being local after step 2, you only need to perform steps 2 & 3 only. There is no easy way to switch if your SP configs live in Central. These are the high-level steps we followed:
- Extract all resources from the domain that you may need for the Central SP recreate and edit (this step can happen any time, before step 5.)
- Remove domain from Central (NB: localize global resources, NOT deep remove).
- Re-add domain to Central using DNS entry (we kept all resources except for infra firmware management to global).
- Recreate all SPs in Central using the same SP template, to reduce the amount of modifying individual SPs post create.
- Customise Central SPs with policies that will not clash with locally assigned resources (e.g. boot policy, host firmware package, if those were not set correctly during the SP creation).
- In a rolling fashion (we had hosts in VMware clusters, so could take a couple down at a time)
- Put host in MM, shutdown, disassociate SP from blade,
- On Manager, rename $SP to $SP_local (to avoid clashes with the same SP name in Central when you associate Central $SP)..
- Change one character in $SP_local MAC & WWPN (e.g. B5 to B6) to avoid clashes during the next step (you can also remove the SP completely to avoid name / WWPN / MAC conflicts, but that complicates the roll-back to the old local SP). NB to change after disassociate, otherwise it will trigger a reconfigure and boot up when you shut the host down.
- In Central, assign the same MAC & WWPN to $SP to match the $SP_local (If you did not perform step iii, Central will complain about duplicate MACs.
- Associate Central $SP with the same blade. Because the Central $SP is referencing policies and templates that were localised when you removed the domain, you will get lots of error messages of resources conflicting. Central will tell you to delete the resource (e.g. a power policy, host firmware package, etc - there are probably 15-20 of these). Every time you delete the resource, reapply the $SP configuration from Central. Central will push the removed resource to the domain since it no longer clashes, pass that hurdle, but get stuck on the next resource with a conflicting name. Once you have resolved all conflicts, $SP will successfully associate. (NB: this policy / resource conflict typically only happens for the first SP. Subsequent SPs will not require this, if they are using the same resources as the first SP).
- Once you are happy that the server boots fine, remove $SP_local.
We tested the whole process extensively in the lab before taking on the first production domain. Removing these resources and policies (step v on the first SP) is not for the faint of heart. You may see an error/warning dialog before removing the resource, and after you OK, the fault count will go up, and go back to pre-remove levels, after the resource is pushed from Central to the domain.
Special consideration when you use VLAN groups: the port channel or uplink association to VLAN group in LAN uplinks manager will be lost if you remove the local VLAN group (when Central complains about local and Central VLAN group name conflict). You will have to manually re-add this association in LAN uplinks manager. Depending on your network configuration (e.g. if you are using disjoint layer 2 configuration), you may experience downtime during this period (before you re-establish the port channel to VLAN group association).
We were able to use the above procedure to localise 100+ SPs on 7 domains (see Background below). It was a truly crazy amount of work, but the alternative of keeping the SPs local, was not an option for us. We wrote commands and scripts to extract the resources that we need for the SP recreate (boot policy, sub-org, host firmware package, WWPN, MAC) and used those as inputs for when recreating and modifying new SPs, using various Central PowerTool and CLI commands.
I researched the “localise global policies and SPs” feature in Central extensively, but unfortunately it did not work for us, since all policies, templates, VLANs, VSANs and pools used the same name in locally than what was in Central, and they clash when you try to use the globalise workflow.
Background: We ran into an issue in 2021 with 7x FI-6454 based domains running UCS 4.1 infra firmware connected to Central, where 7 of the domains (more than half of the FI-6454 in our estate) went “missing” from Central. Central lost all record of these domains, as if they were removed and localised. No amount of TAC digging was able to find a cause. Not that it mattered, even if they found the cause, it would not help us in getting out of the hole that this bug created. In the end we developed the above procedure, which we reused this year when our Central IP had to change.
Edit: I stumbled on the post https://community.cisco.com/t5/unified-computing-system-discussions/migrating-local-service-profile-to-global-ucs-central/m-p/3495498 where someone posted a file Migrate-Local-Service-Profile.ps1.zip which may help with what youare trying to accomplish.
