Upgrading UCS1.4l to 2.1(1a) cannot transfer the primary role

[ryanquimby]

Upgrading to 2.1(1a), got everything upgraded to the point of the fabric interconnects.. Upgraded the subordinate, its online, ready, happy.. What I can’t seem to do is failover the primary ( version 1.43l) to the secondary so I can then upgrade the last part of our infrastructure…

From the subordinate (2.1) I get:

UCS01-B# sh clus state

Cluster Id: 0x3d4c7d28fb3411e0-0xad17000573e6c384

B: UP, SUBORDINATE

A: UP, PRIMARY

HA READY

UCS01-B(local-mgmt)# cluster force primary

Cluster Id: 0x3d4c7d28fb3411e0-0xad17000573e6c384

request failed: cannot accept  force command when election has successfully completed

From the primary (1.43l) I get:

UCS01-A# show cluster state

Cluster Id: 3d4c7d28-fb34-11e0-ad17-000573e6c384

Unable to communicate with UCSM controller

UCS01-A(local-mgmt)# cluster lead b

Cluster Id: 3d4c7d28-fb34-11e0-ad17-000573e6c384

Unable to communicate with UCSM controller

[Robert Burns]

Why are you trying to switch it over manually during the upgrade?

The system will do this for you once you activate Fabric-A with the 2.1(1a) image.  I don't believe you can even force it if the two are different versions like that.

Regards,

Robert

[ryanquimby]

The upgrade document i am following says to do this.

http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/upgrading/from2.0/to2.0MR/b_UpgradingCiscoUCSFrom1.4To2.0_chapter_0100.html

We are trying to avoid any downtime.

[Robert Burns · Accepted solution]

Since the cluster state is FULL HA, you can go ahead and activate the remaining primary.

By forcing a switchover or just activating the FI its going to kill the UCSM session regardless, but your data path will be unaffected with either method.

Try the "cluster lead b" instead of the force command from the Primary FI.   The "force" command is for when election fails or the subordinate is the only FI online and you need to "steal" the role.  The "lead" command is more graceful.

Robert

[ryanquimby]

Thanks, i guess it was my inexperience that didnt trust the failover. I did as you said and just went ahead with the upgrade on the existing primary, i did lose my admin connection, but was able to reconnect with the backup IP.

Thanks

[Robert Burns]

Better safe than sorry

Let us know if you have any questions on the new features.

Cheers,

Robert

[Mierdin21]

Really hate to hijack an old thread but this happened to me on my way from 2.1(3a) to 2.2(1b) today.

I'd like to know the reason for this error - all TAC was willing/able to tell me on the late shift was that the resolution was to reboot the switch. Not exactly ideal for situations where I have to answer to a large customer that needs root-cause analysis for anything that goes wrong.