Tonight I’ve been upgrading a CallManager 7.1.3 cluster to 7.1.5. This is a minor upgrade, but still follows upgrade procedures as usual.

I experienced two issues which I just need to note down.

Firstly, upon a switch version to the new partition CallManager takes A LONG TIME to start its services. The trap that I fell into was that I SSH’d to the box to check how the service start was going when I was greeted with this:

Requesting service status, please wait…
System SSH [STARTED]
Cluster Manager [STOPPED] Service Not Started
Service Manager [Not Running]
Warning: Service Manager need to be running for all Call Processing Applications

I started to freak out thinking that my new upgraded partition was fkd. I played with all sorts of starts and restarts shown below:

admin:utils service start Cluster Manager
Service Stopped
Cluster Manager [STOPPED]

admin:utils service start Service Manager
Starting servM
admin:

I rebooted the box hoping that something had got stuck and that it just needed a kick. When it came back up and SSH showed the same thing I tried to start services that I knew I hit the following:

admin:utils service start Cisco Database Layer Monitor
Service Manager [Not Running]
Warning: Service Manager need to be running for all Call Processing Applications
admin:utils service start Cisco Database Layer Monitor
Service Manager [Not Running]
Warning: Service Manager need to be running for all Call Processing Applications
admin:utils service start Cluster Manager
Service Stopped
Cluster Manager [STOPPED]

By this time I was freaking so I moved away for a few mins to work on something else. I came back and checked the service list again, and everything had started! So I guess the moral here is that 1. services don’t show as starting when they are starting for the first time. 2. an upgrade and switch partition takes a long time!

The second issue I had was a box not rebooting to its switched partition. I tried to force the switch but hit the following:

admin:utils system switch-version

Active Master Version: 7.1.3.32009-2
Inactive Master Version: 7.1.5.30000-1

If you are switching to an earlier release, you must run:
utils dbreplication reset all
from the publisher after all the nodes are switched over.
Do you really want to switch between versions ?

Enter (yes/no)? yes

Switching Version and Restarting the Appliance …

Switch version duration can vary depending on the database size
and platform configuration.  Please continue to monitor the
switchover process from here.

Waiting ………………………….

Operation failed

ERROR: Acquiring lock failed

I started to freak again. Then I found this page: http://iptbuzz.blogspot.com.au/2011/10/switch-version-doesnt-switch.html props to the guy who wrote that, because it worked perfectly! I manually rebooted the box and then forced a switch version and rebooted again and everything was gravy.

I’m yet to play with 8.x as we are waiting for 9 with proper VM support, but I hope that Cisco manage to fix their dodgey CCM scripting!