Virtualization Software Requirements

VMware vSphere ESXi is mandatory for all virtualized deployments of Cisco Collaboration applications, and is the only supported hypervisor.

VMware vCenter is

• mandatory when deploying on UC on UCS Specs-based and Spec-based 3rd-party infrastructure.
  • vCenter Statistics Level 4 logging is mandatory so that Cisco TAC is able to provide effective support.
  • Click here for how to configure VMware vCenter to capture these logs. If not configured by default, Cisco TAC may request enabling these settings in order to provide effective support.
  • Also note that enablement of specific VMware vSphere management features may require vCenter and/or a higher feature Edition of vSphere ESXi.
• mandatory when deploying on Tested Reference Configurations of Cisco HyperFlex (because HyperFlex management requires vCenter).
• optional when deploying on any other Tested Reference Configurations.
• Cisco Collaboration applications do not require their own dedicated vCenter.
• Note that when VMware vCenter is not required and is not used, then VMware vSphere ESXi's default management interface is its free/included VMware vSphere Client (formerly branded VI Client).

• Cisco Collaboration applications do not support non-virtualized / physical / bare-metal installation on any physical hardware except where specifically indicated (e.g. Cisco Expressway is supported bare-metal on CE1200 appliance; Cisco Meeting Server is supported bare-metal on CMS 2000 appliance).
• Cisco Collaboration applications do not support hypervisors that are not VMware vSphere ESXi (e.g. Microsoft Hyper-V, Citrix Xen, Red Hat Virtualization, etc. are not supported)
• Cisco Collaboration applications do not support any 3rd-party public cloud infrastructure as a service (IaaS) offer. Including but not limited to:
  • Any 3rd-party public cloud offers based on VMware Cloud Foundation (e.g. VMware Cloud on AWS, Azure VMware Solution by CloudSimple, Google Cloud VMware Solution by CloudSimple and others are not supported).
  • Any 3rd-party public cloud offers that don�t use VMware technology (e.g. Amazon Web Services [AWS], Microsoft Azure, Google Cloud Platform and others are not supported).
  • Any on-premises �hybrid� extensions of 3rd-party public cloud infrastructure (e.g. VMware Cloud on Dell EMC VxRail, Amazon AWS Outposts, Microsoft Azure Stack, GKE On-prem and others are not supported).
  • Any other type of public cloud offer (e.g. IBM Cloud and others are not supported).
• Cisco Collaboration applications do not support VMware vSphere �ESX�, only ESXi.
  • Recall ESX and ESXi are architecture options for VMware vSphere releases prior to 5.0 (click here for a comparison). VMware vSphere 5.0+ only offers the ESXi architecture option. Click here for VMware's direction to transition from ESX to ESXi. An ESX cluster can contain ESXi hosts running Cisco Collaboration.
  • Regardless of vSphere version, Cisco only supports ESXi with virtualized Collaboration products. Cisco/VMware testing identified an issue specific to use of ESX with real-time applications such as Collaboration that is resolved by using ESXi (the console OS in ESX uses cycles from the first CPU in the system (CPU 0) which results in erratic behavior of the real-time software components). ESXi contains several optimizations for real-time applications and is therefore what Cisco will support.

For details on "legacy" virtualization support (i.e. 7.x of UC apps with VMware vSphere on limited 3rd-party servers), see the following links:

• Cisco Unity Virtualization Design Guide
• Virtualization Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted 7.5(3)

The vmv represents the version of virtual hardware. New ESXi versions may increase the latest vmv version, but new ESXi versions support older vmv versions (see vmware.com for information on compability of old vmv versions with new ESXi versions, such as this vmware.com KB article for compatibility for ESXi version with vmv version).

Cisco Collaboration apps do not require or even use most of the new features in new vmv versions (e.g. larger VMs, more virtual HW options, etc.). Cisco Collaboration apps only require vmv4 functionality, so a newer vmv is usually transparent. To date, Cisco has not discovered any issues with Collaboration apps due to a newer vmv version.

Cisco-provided/required OVA files will be for the specific vmv version used when testing the ESXi major/minor version (e.g. OVAs for ESXi 5.x include vmv7 and vmv8).

For customers using vSphere Client instead of vCenter, it is NOT recommended to upgrade to a newer vmv. E.g. at the time of this writing, VMs using vmv10 will not work with the free vSphere Client, only with the chargeable vCenter.

Otherwise, unless indicated NOT to by a Cisco Collaboration app, customers are free to manually upgrade the vmv to a newer vmv supported by the ESXi version. Cisco does not produce OVA files for newer vmv versions, or test newer vmv versions since VMware indicates these are backwards compatible.

If ESXi 6.5, all applications support VMFS5 but only some support VMFS6 (check each application's virtualization page for details). Note: ESXi 6.0 only supports VMFS5. For older ESXi releases, the VMFS is transparent to Cisco Collaboration apps, but recommend using the latest version offered for the major/minor version of VMware vSphere ESXi you are deploying on.

VMware Tools are specialized drivers for virtual hardware that is installed in the UC applications when they are running virtualized. It is very important that the VMware tools version running in the UC application be in sync with the version of ESXi being used.

If VMware tools status does not show "OK" from the viClient, the VMware Tools must be upgraded.

It is important to understand that the UC application is not tied to the version of ESXi it is running on. For example, initial deployment of the OVA and UC application may have been done on ESXi 4.0 update 1. Then at a later time, you may upgrade the ESXi software to version 4.1 or migrate the vm to a host running ESXi 4.1 - once running on the different ESXi version, you will need to upgrade the VMware Tools running in your UC application to match the host it is running on. Software upgrades of the UC application will preserve the version of VMware Tools currently running.

• Not all features in a given Major/Minor release of VMware vSphere ESXi may be licensed/enabled. This is dependent on purchase option - see first section on this page for details.
• A Collaboration application may not support every feature in a given Major/Minor version of VMware vSphere ESXi. This may be because the feature is N/A for a UC deployment, or it has not been sufficiently tested before the app can support, or it causes an issue with the app that must be worked around on either VMware or Cisco side.

Note: Feature support for Cisco Unified Contact Center Enterprise varies by component (e.g. Peripheral Gateway) and deployment model (e.g. "Rogger"). This section will give a summary support position, but for individual components see Support for Virtualization on the ESXi/UCS Platform.

Legend for Feature Support Tables

• Y = Supported
• Y(C) = Supported with Caveats - see Best Practices for details
• Y(P) = Partial (limited) support only - see Best Practices for details
• No = the feature is not supported at this time - see Best Practices for alternatives, if any.
• Unlisted = Not Supported

NOTE: support varies by app and version. Before reading the best practices below, verify support at Supported Editions and Features of VMware vSphere ESXi, VMware vCenter and VMware vSphere Client.

See www.dmtf.org for details on the Open Virtualization Format, which describes an OVF Package (a directory of files describing a virtual machine's configuration) and an OVA Package (single tar file containing an OVF Package).

"Template" in this context refers to an OVA file that defines the virtual server (but not the "workload", i.e. the UC OS and application). Each virtualized UC product provides a set of predefined virtual machine templates (as OVA files) for supported Virtual Machine (VM) configurations. Customers must download and use these OVA template files for initial install, as they cover items such as supported capacity levels and any required OS/VM/SAN "alignment". OVAs configured differently than the predefined templates are not supported unless specifically allowed on the app's page on www.cisco.com/go/virtualized-collaboration. To download the OVA files, refer to the Collaboration Virtualization Sizing guidelines.

NOTE: support varies by app and version. Before reading the best practices below, verify support at Supported Editions and Features of VMware vSphere ESXi, VMware vCenter and VMware vSphere Client.

Copying a Virtual Machine (VM) copies both the virtual server configuration and the workload (UC OS and application) running on that virtual server to a file on networked shared storage. This allows VMs to be copied, then subsequently modified or shut down. This feature effectively provides a method to do full system backup/restore, take system images or revert changes to software versions, user data and configuration changes.

• Prior to copying, the VM must first be shutdown (which will shut down the virtual server, the UC OS and the UC application).
• If uploading a VM copy as a "whole system restore", clustered UC applications such as CUCM will probably require their replication to be manually "fixed" via a CLI command.

NOTE: support varies by app and version. Before reading the best practices below, verify support at Supported Editions and Features of VMware vSphere ESXi, VMware vCenter and VMware vSphere Client.

VMware vSphere ESXi 4.1 introduced a new setting called "Large Receive Offload (LRO)". When enabled on VMs running ESXi 4.1 or later, you may experience slow TCP performance on certain operating systems (depending on which Collaboration application and version). This setting usually needs to be disabled on an ESXi host running Collaboration app VMs (either new install of ESXi 4.1+, or upgrade from ESXi 4.0 to 4.1+ followed by upgrading VMwareTools in app VMs to 4.1+).

To disable LRO, follow this procedure:

1. Log into the ESXi host or its vCenter with vSphere Client.
2. Select the host > Configuration > Advanced Settings.
3. Select Net and scroll down slightly more than half way.
4. Set the following parameters from 1 to 0:
   • Net.VmxnetSwLROSL
   • Net.Vmxnet3SwLRO
   • Net.Vmxnet3HwLRO
   • Net.Vmxnet2SwLRO
   • Net.Vmxnet2HwLRO
5. Reboot the ESXi host to activate these changes.

Your guest VMs should now have TCP networking performance.

NOTE: support varies by app and version. Before reading the best practices below, verify support at Supported Editions and Features of VMware vSphere ESXi, VMware vCenter and VMware vSphere Client.

A Virtual Machine (VM) file on network/shared storage can be booted on any physical server hosting ESXi that has access to that network shared storage. With multiple physical ESXi hosts connected to the same network shared storage, this can be used to perform:

• Fast manual server moves, e.g. moving VM from ESXi host A to ESXi host B in another chassis, closet, building, etc.
• Fast manual server recovery, e.g. moving VM from ESXi host A that has just had a server hardware or VMware failure to ESXi host B that is healthy. See also VMware High Availability and Site Recovery Manager.
• Setting up software at a staging location to be later moved or deployed elsewhere. For multi-site scenarios, this may instead require "exporting" the VM.

NOTE: support varies by app and version. Before reading the best practices below, verify support at Supported Editions and Features of VMware vSphere ESXi, VMware vCenter and VMware vSphere Client.

Similar to adding/removing physical hardware to/from a physical server, you can add/remove virtual hardware (vCPU, vRAM, vDisk, vNIC, etc.) to/from a Virtual Machine (VM) via a software change in VMware's configuration interfaces. Where supported, this provides the VM equivalent of migration to a more powerful or less powerful server.

• Any changes to a VM must align with the best practices in Virtual Machine Templates (OVA files). VM changes that result in an unsupported OVA configuration are not allowed. Even if you align with supported OVA configurations, desired VM changes may be prevented by one of the other caveats below.
• Support for adding virtual hardware resources (similar to moving from a less powerful server to a more powerful server, such as MCS 7825 -> MCS 7845) depends on which resource, and which UC product:
  • Adding vCPU is supported for all apps except Unity Connection, but requires VM to be shutdown first.
  • Adding vRAM is supported but requires VM to be shutdown first.
  • Adding vDisk is not supported as it would require re-partitioning by the application.
  • Adding vNIC is not supported unless the UC app supports multiple network connections with different IP addresses. See best practices for Multiple Physical NICs and vNICs.
• For all other changes, it is recommended to backup the application, reinstall application on a new OVA file, and restore the application.
• Removing virtual hardware resources (vCPU, vRAM, vDisk, etc.) is not supported (similar to moving from a more powerful server to a less powerful server, such as MCS 7845 ? MCS 7825). These migrations require backing up the application, reinstalling on a new OVA file, and and restoring the application.
• Live runtime resizing via the VMware Hot Add feature is not supported.