How can I avoid all blades rebooting when upgrade FI.

[fly]

I upgrade ucs from 2.0.2x to 4.0.4

everything is fine , but After I click acknowledge reboot primary FI, all blades on 10 9 chassis rebooted at same time, and pass long time rediscover time, we lost all bussiness for 2 hour,  because we need time to start vm on vcenter

I met same thing before when I upgraded FI, especially reboot primary FI, all blade same lost control , so have to reboot, but I checked ha status , and pmon status(some retries), 

How can I avoid all blade rebooting ,because it is diffcult to transfer all vm to another ucs in sometime.

thank you

Tom

[Riaan van Niekerk]

Did you perform a direct upgrade between those versions?

According to UCSM-Upgrade-path-Overview you cannot upgrade directly from 2.2(1) (it does not list 2.0(x)) to 4.0(4). If you did, not sure if that has something to do with the upgrade being disruptive.

Other than that, I cannot think of anything obvious that would cause this issue.

[fly]

yes  I checked this url, i upgrade from 2.2(8m) to 4.0.(4o),It support direct upgrade,

 but  I got all blade rebooting when I ack primary FI reboot.

I use FI auto upgrade method, after upgrade ucs manager I can web login 4.0.4 web url, and finished secondary FI upgradre and reboot automatically,  but I forgot check clustert status before ack primary FI reboot request.

this is weird 

[fly]

yes i direct upgrade, it is successful,but when primary fi switch, all blade rebooting.

I check doucment support from 2.2.8 to 4.0.4 directly

[Riaan van Niekerk]

I would recommend logging a call with Cisco TAC. They should be able to analyse the logs to tell you what went wrong in your particular case. 

I don't think there is a standard or common answer to a question like "How can I avoid all blades rebooting when upgrade FI?"

It is not normal behaviour and should not happen under normal circumstances (I have done 100s of domain infra upgrades, none of them a big jump as 2.2(8) -> 4.0 and have never seen anyting similar). If it were a known issue, someone who ran into it or is aware of this issue, may respond to your query, but I would say the chances are slim. 

[fly]

yes it is big jump ，I think if jump to a intermediate version is better

[Riaan van Niekerk]

The fact that it is such a big jump, should not cause the downtime you saw. If Cisco release notes and upgrade documentation say the direct upgrade of 2.2(8) to 4.0 is supported, it should just be as non-disruptive than any other smaller jump upgrade.

Another thought: Did you check that all paths were up on the recently rebooted and upgrades secondary (the UCSM support bundle should show this, since these would be faults in UCSM). We have had it happen once or twice where the "Reboot primary FI" appears Pending Activities, which the admin acknowledged before confirming that all paths to the upgraded and rebooted secondary restored.