UCCX 12.5 SU1

[m.liew]

Upgrading from UCCX 12.0 to 12.5SU1.  The switch version on the HA server is taking nearly 3 hours.  Did anyone experience it too?  UCCX Primary node switched version in 1 hour.

[m.liew · Accepted solution]

Update.. UCCX2 upgrade failed.  Lost UCCX2 server.  Rebuilding it now. 

[jim-j]

Any lessons learned from losing your subscriber server?  For example, anything that's important to do (or not to do) during the upgrade?

Hope your recovery goes well.

[TomMar1]

Perform a DRS backup prior to the upgrade.  I have found it a good practice to clone the VM as well. Especially with a Publisher node.

DO NOT TAKE A SNAPSHOT.

You will need to shut down the VM to clone it via CLI.

Navigate to directory where application is, create a Backup folder mkdir Backup

For example /vmfs/volumes/DataStore1/MRAexpressway-C

cp * /vmfs/volumes/DataStore1/Backup

A few days after the successful upgrade delete the clone

[Roger Kallberg]

You can also clone the VM from the vSphere UI. That's what we normally do for all the VMs in a cluster before we upgrade it.

[jim-j]

---

@TomMar1 wrote:

...DO NOT TAKE A SNAPSHOT....

I know that snapshots can cause performance issues (so you shouldn't leave them in place long term) and if you revert a snapshot of running servers you're asking for DB weirdness.  However, do you know if there's any reason snapshots wouldn't work for a short term rollback option if you did this:

1. Power down both servers
2. Take a snapshot of both servers
3. Perform upgrade of both servers
4. If upgrade goes well delete both snapshots, but if upgrade goes poorly revert both servers to their previous (powered off) pre-upgrade state.

[Roger Kallberg]

I never use Snapshots, we have even changed advanced settings on the VMs so that it’s not possible to do a snapshot. I don’t know if I see your value point in doing that outline? If you do a shutdown of the VM to create the snapshot what gain would that have compared to doing a clone? For both you would have the VM in shutdown state.

[jim-j]

---

@Roger Kallberg wrote:

I never use Snapshots, we have even changed advanced settings on the VMs so that it’s not possible to do a snapshot. I don’t know if I see your value point in doing that outline? If you do a shutdown of the VM to create the snapshot what gain would that have compared to doing a clone? For both you would have the VM in shutdown state.

---

I was primarily just thinking out loud.  The only minor benefits to snapshots would be the speed with which you can create them and revert to them.  I agree though, the downsides of snapshots (that @TomMar1 and you point out) far outweigh these minor benefits.

[TomMar1]

https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/116459-technote-product-00.html

"

VMware snapshots are not supported in UC applications. Snapshots cause all types of latency and voice-quality issues. They also cause disk-drive space issues, CPU spikes, and memory utilization issues in UC applications.

When you troubleshoot any voice-quality or CPU/memory issues on a UC application that is supported on a VMware platform, the first thing to check is the presence of snapshots on the system."