UCS Central Equipment Policy Change

[BARishel]

We currently have a domain running 4.1(3h) that has the default host firmware package changed to a version that is not supported by the M5 blade proc's.  This is causing us an issue where we cannot associate Global Service Profiles from a Global Template to a M5 blade because its attempting to auto sync the firmware to a revision the M5 proc is not compatible with. 

When we attempt to change the default host firmware package version to back to <not set>, we get an error stating that the setting cannot be changed due to the fw_autosync policy being configured by a remote setting.  We found that this is due to our domain's Equipment Policy settings in UCS Central being configured to Global.  Has anyone made a change to the equipment policy from Global to Local on a running domain, and if so what is the impact of making this change to any active systems?  

Bryan Rishel

[Tapper]

I have not changed a Global to a Local, but I may have another solution for you.

Why not clone your current Template and remove the host firmware policy from the clone?  Then unbind the Service Profile from the old template and bind to the new one.  You will have to have the blade powered down during the swap though.

Hope this helps,

Tom

[BARishel]

Changing the host firmware revision on the global UCS Central template will not work for us due to the order of operations in how the profile is applied.  The local domain default firmware bundle always takes precedence first.   We do however, use your process in order to get a blade associated and working.  The downside is that it after its rebound to the SP Template, the local domain then see's the default version is different and has a pending ack against the blade trying to force it back down.  This locks any changes out on the blade such as adding a vLan to a vNic Template from being added to the local Service Profile.  

Unfortunately were in a situation where the default host firmware bundle is being used to auto-sync firmware onto blades that are not assigned.   This is fine for our M3 and M4 blades, but our M5's are not compatible with the firmware version in the default.  This causes a problem where UCS Central attempts to associate a Service Profile to the blade, and does a firmware version check before association begins.  Because the local domain is set with a firmware version that is to low for the CPU and CIMC to support on the M5's, it results in  an error during association saying that there are no resources available and the M5 association errors out.  

The only fix we've found is to modify the default host firmware bundle, but we can't do this because our UCS Central Equipment Policy is set to Global.  This prevents the local domain UCS Manager from being able to modify the default host firmware bundle and presents an error saying "firmware autosync policy is being received from a remote server" (Meaning UCS Central pushing it).   This domain has 12 chassis and over 80 active blades and we need to modify the UCS Central domain specific "Equipment Policy" from Global to Local.  I've been pouring over all of the documentation, administrative, troubleshooting, configuration guides but cannot find ANYTHING relating to the scope of what the the UCS Central Domain Equipment Policy does or what the impact is if its changed.  

Because this doesnt have both DMZ and internal production ESXi hosts running in it, we are very tentative to change this on the fly, as we've been warned by Cisco engineers that the default firmware package can reboot hosts ignoring the maintenance policy and forced ACK policies.