Modifying SP of one server causes another to reboot

[rsobey001]

Hi all,

We're running UCS Central 1.5(1c). It's been working very well for a long time, but in the last few days we've noticed that adding SAN connectivity to a profile is causing the immediate reboot of another profile.Screenshot attached.

So, to be more clear, we have a SAN Connectivity Policy for Windows and Linux systems. We have a need to add this policy to any existing Service Profile. When we do that and press Evaluate, not only is it causing the user-ack reboot of that Profile (to be expected), but it's causing the *immediate* reboot of another profile.

That other profile is the same each time.

Our maintenance policy is set to user-ack.

Obviously we do not want to reboot the other server so we have to back out of modifying the intended Profile. We therefore don't know if this will definitely reboot the other server, or if it's just cosmetic.

We can work around it by disassociating the Service Profile before adding the SAN Connectivity Policy and then associating it again.

I can't think of anything that's changed so recently that would be causing this. The other profile has existed for over a year easily.

So, anyone got any ideas on what's causing this and how to fix it? I've rebooted the UCSC appliance.

Cheers!

[Wes Austin]

There is likely some component that requires a reboot for an upgrade or change on server 4/3.

You can open a TAC case or tail the DME log while you make the change and see what is requiring a reboot.

UCS#connect local

UCS(local-mgmt)#tail svc_sam_dme

You will get a lot of output, so try to do this right before you make the change and then Ctrl + C right after.

Then search the outputs for "RebootRequired" and it should flag why it wants to reboot.

This could also be a software defect, so I would recommend opening a TAC case.

[rsobey001]

Thanks Wesley.

The best I can get for RebootRequired is the following line:

[KINFO][0x6ccffb90][Aug  3 15:51:41.442][ls:analyzeConfig]      bindingChange 0, hostEthIfChange 0,hostEthIfProfileChange 0, hostEthIfQosChange 0,hostEthIfQosHostControlChange 0, hostEthIfNwCtrlChange 0, hostEthIfProfileRedeployRequired 0,hostFcIfChange 1, hostFcIfProfileRedeployRequired 0,hostFcIfPersChange 0, hostFcIfProfileChange 0, hostFcIfQosChange 0, hostFcoeIfChange 0, hostIfPCIeChange 0, vifChange 1, vlanChange 1, vsanChange 0, ipChange 0,bootOrderChange 0, biosProfileChange 0, bladeIdentityChange 0,agentPolicyChange 0, biosFwChange 0,storageControllerFwChange 0, adaptorHostFwChange 0,adaptorNwFwChange 0, mgmtControllerFwChange 0,localDiskPolicyChange 0, pinChange 1, solChange 0,flexFlashConfigChange 1, cimcVmediaConfigChange 0,epAuthChange 1,bootVnicChange 0, bootPXEChange 0, boardCtrlFwChange 0, errInsufficientResources 1,localDiskFwChange 0,pnuosConfig 0, rebootRequired 1,ConfigRename 0,FcZoneChange 0,OobLocalStorageChange 0,snicConfigChange 0,failed 1, serverIssues 0x1, networkIssues 0x0, storageIssues 0x0, vnicIssues 0x1000000, iscsiIssues 0x0 FLAGS APPLIED: 0x0, willExecute 0

(I see lots of RebootRequired 0, too, but I assume that's not relevant).

[Wes Austin]

This is what is causing your reboot hostFcIfChange 1.

Is that SAN connectivity policy in use by both servers? If you let the server reboot, does it still prompt for reboots on subsequent changes to server 4/1?

[rsobey001]

(sorry, reported your post instead of pressing reply... hopefully it unreported!)

Yes, the SAN policy is in use on this server, and 8 others in this UCS domain. 

Edit: to clarify the SAN policy being used is a Global policy that's in use across two domains.

I need to get an outage for 4/3 *just in case* it does reboot, and especially if it doesn't reboot gracefully, so I can't answer the other question yet.