This section only describes mandatory, optional, allowed or recommended virtualization software. For all other support policy elements (including supported hardware and supported application co-residency), see links on http://www.cisco.com/go/uc-virtualized.

Mandatory Virtualization Software

VMware vSphere ESXi is mandatory for all virtualized deployments of 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.

* Note these license options have limited capacity, feature and 3rd-party application support (see below) so may not be suitable for all deployments. If the capacity, features or 3rd-party support are mandatory, then:

BE 7000, Tested Reference Configuration or Specs-based deployments require substitution with a different virtualization license option

BE 6000 bundles require substitution with either a Tested Reference Configuration or Specs-based deployment with a different virtualization license option.

Logistics for Media access, License activation and technical support depend on purchase option.

Does not support VMware vCenter management or any other advanced features. Same feature enablement as the "free ESXi download" from vmware.com. (e.g. impacts ability to use Cisco Prime Collaboration Deployment for migrations as requried VMware APIs not in this license).

The only applications that may be hosted on this OEM are those that meet the requirements of the Cisco Business Edition 6000 Co-residency Policy Document available at: [1]. I.e. Cisco Collaboration apps and 3rd-party apps in Collaboration category of Solutions Plus or Cisco Developer Network, with a maximum count of 3rd-party VMs.

The Cisco UC Virtualization Foundation OEM option is only sold and supported as an add-on SKU for use with Business Edition 6000, Business Edition 7000 and UC on UCS.

It is not available or transferable for use with non-UCS hardware or non-UC software.

Supports connection to VMware vCenter management (vCenter software must be purchased separately). Does not enable any other advanced features (such as VMware High Availability, Data Recovery, vMotion, Distributed Switch, etc.). Does work with Cisco Prime Collaboration Deployment.

The only applications that may be hosted on this OEM are those that meet the requirements of the Cisco Business Edition 6000 Co-residency Policy Document available at: [2]. I.e. Cisco Collaboration apps and 3rd-party apps in Collaboration category of Solutions Plus or Cisco Developer Network, with a maximum count of 3rd-party VMs.

Cisco UCS 6x00 does not currently support Layer 3 to Layer 2 COS markings. Additionally, the UC applications and operating systems cannot set the Layer 2 COS markings. Use of Cisco Nexus® 1000V is therefore strongly recommended as this is currently the only way to deterministically manage traffic congestion through the UCS 6x00.

Supported Versions, Patches and Updates of VMware vSphere ESXi

Major/Minor Versions of ESXi

E.g. VMware vSphere ESXi 4.0, 4.1, 5.0, 5.1, 5.5.

Compatibility of ESXi Major/Minor versions with Cisco Collaboration app versions is stated either on this page or on the product details pages linked from www.cisco.com/go/uc-virtualized. Unlisted Major/Minor versions are not supported.

Interpret compatibility information as "if I am deploying version x of this application, here is the list of ESXi major/minor versions that are supported by application version x".

VMware vSphere ESXi versions prior to 4.0 are not supported due to technical reasons.

Patching and Updating VMware vSphere ESXi

In general, Cisco Collaboration app versions only mandate the Major/Minor versions of ESXi they require/support.

Guest OS support - Cisco Collaboration apps that require a minimum Maintenance release (e.g. "5.1 U1" as minimum instead of "5.1" as minimum) for the application to be supported will explicitly call this out on their product detail pages. When in doubt, consult Cisco Plan, Design, Implement (PDI) HelpDesk or Cisco TAC.

Hardware support - For a Major/Minor version of ESXi supported by Cisco Collaboration apps, recommendation is to use the latest Maintenance release that is also supported/recommended by the server vendor (and storage vendor if deploying on NAS/SAN). To help determine if a patch or Maintenance Release of ESXi "can" or "should" be deployed, follow the guidance from these sources:

Other "Versions"

Virtual Machine Version (vmv) - The vmv represents the version of virtual hardware. New ESXi versions may increase the latest vmv version, but ESXi versions always support older vmv versions (see vmware.com for information on compability of vmv versions with ESXi versions). The "bare minimum" for Cisco Collaboration apps is vmv4 so this is usually transparent. Cisco-provided/required OVA files will be for a particular vmv version (e.g. OVAs for ESXi 5.x include vmv7 and vmv8). 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 (click here for details ).

Virtual Machine File System (VMFS) version - This 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 vSphere ESXi Version Support for Call Processing and System Management Applications

* For applications that are allowed "on-box" with Cisco Business Edition 6000, this also includes version compatibility with Cisco UC Virtualization Hypervisor which is only supported for use with Cisco Business Edition 6000.

VMware vSphere ESXi Version Support for Messaging and Presence Applications

* For applications that are allowed "on-box" with Cisco Business Edition 6000, this also includes version compatibility with Cisco UC Virtualization Hypervisor which is only supported for use with Cisco Business Edition 6000.

VMware vSphere ESXi Version Support for Contact Center Applications

Note:

For Virtual Machines that need more than 4 vCPUs, the VMware vSphere ESXi 4.1 Enterprise Plus licensing is required (8 way virtual SMP capability and applicable to ESXi 4.x only). The VMware vSphere 4.1 Enterprise Plus license can be procured from the Cisco build-to-order or directly from the VMware (see VMware Purchasing section above.)

Notation Convention. The 8.0(1+) means 8.0(x) (x=1 and later 2,3,etc.) The 8.0(x) SU1+ means 8.0(x) and thereafter SU such as SU1, SU2, SU3, etc. in the 8.0(x). The 8.0(1)+ means 8.0(1) and thereafter releases like 8.0(1), 8.0(2) or 8.5(1), etc. The 8.x means any releases in that train: 8.0, 8.1, etc. The same is for other major releases (9, 10, etc.) using the + or x convention.

This section only clarifies technical support for VMware vSphere ESXi features.

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.

The table below lists VMware vSphere ESXi feature support by UC app/version. If the feature is supported, click on its name in the table to view UC caveats and best practices. This site will be updated as new support becomes available.

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.

Virtual Machine Templates (OVA files)

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 at this time. To download the OVA files, refer to the Unified Communications Virtualization sizing guidelines.

Copy Virtual Machine

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.

Restart Virtual Machine on Different ESXi Host

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 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.

Resize Virtual Machine

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 and 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.

Multiple Physical NICs and vNICs

Some virtualized UCS servers are configured with multiple physical NICs (see UCS page at http://www.cisco.com/go/swonly). Network traffic is switched from physical NICs to “vNIC’s” of the Virtual Machines (VM) via either VMware vSwitch or Cisco Nexus 1000V. Customers can use these multiple NICs for VM network traffic, VMware console access, or management “back-doors” for administrative access, backups, software updates or other traffic that is desired to be segregated from the VM network traffic. All these uses are supported for UC but note that UC apps like CUCM and UCCX only support a single vNIC with a single IP address.

VMware High Availability (HA)

This feature automatically restarts a Virtual Machine (VM) on the same physical server or a different physical server. It can be used to supplement software redundancy as a means of fast, automated Failed-server recovery when a VM (but not the application) is hung or if there is a fault with the physical host server or VMware software.

Failovers to other servers must not result in an unsupported deployment model (e.g. destination server must align with supported co-residency after failover occurs).

Does not protect vs. faults with the SAN or network hardware.

VMware Site Recovery Manager (SRM)

This feature provides an automated disaster recovery solution that works on a “site to site” basis, where a “site” comprises physical servers, VMware and SAN storage. Refer to the VMware documentation for requirements to use this feature. There are no special requirements to use this feature with UC apps that support it.

VMware Identity

The VMware identity feature allows you to copy an existing instance of a virtual Cisco Unified Presence, and change its identity. The identity of a system is made up of every setting that you usually configure during a fresh install (such as IP address, hostname, passwords).

You can then use this new identity for another instance of a Cisco Unified Presence on a virtual machine. This avoids you having to perform a complete installation each time you deploy a new Cisco Unified Presence.

VMware vMotion

This feature migrates a live, running Virtual Machine (VM) from one physical server to another.

The following applies to any use of vMotion with UC apps:

VM must be installed on shared storage (SAN).

Source and destination physical servers must be connected to same SAN.

Destination physical server must not end up with over-subscribed hardware after the migration. Supported capacity and co-residency rules for UC must be followed before and after the migration.

VMware “Long Distance vMotion” (site to site) is not supported.

The only supported scenario is a manual move to a different server, e.g. for planned maintenance on the server or VMware software, or during troubleshooting to move software off of a physical server having issues.

Use of vMotion for real-time load-balancing of live UC VMs is not supported, whether alone or in conjunction with VMware Dynamic Resource Scheduler (DRS) or Dynamic Power Management (DPM).

Moving a shut down VM during a maintenance window, i.e. a "cold migration" or "host to host migration", is not vMotion and is supported.

If the UC app is listed as "Supported with Caveats", then support is as described below:

Migration of UC VMs that are live and processing live traffic is supported, but note that Cisco testing cannot cover every possible operational scenario. Testing has shown there is a slight risk of calls in progress being impacted for a few seconds as the migration occurs, with worst case result of the affected calls being dropped. If vMotion is suspected as the cause of dropped calls, customers should gather appropriate application logs as well as performance data from VMware vCenter and send to Cisco TAC for analysis.

If the UC app is listed as "Partial" support, then support is “maintenance mode only” as described below:

"Maintenance mode only" - VMware vMotion by definition operates on live VMs, but the VM running the UC app must be “live but quiescent”. I.e. in a maintenance window, not in production, not processing live traffic. This is because during the vMotion cutover, the system is paused, which for real-time UC apps creates service interruption which degrade voice quality after the migration for calls in progress.

Specifically for Cisco Unified Attendant Consoles, this means the CUxAC VM must not be doing any Hot Swap or taking any active calls, with no active Directory Synchronization in progress.

Storage vMotion

This “customer convenience” feature provides easy migration of a live system from one SAN to another SAN. For UC apps, an easier suggested alternative is to just perform manual VM shutdown and migration to the new SAN. However, if Storage vMotion must be used, it is only under the following conditions:

This feature automates patching and updating of VMware vSphere hosts and Guest OS.

Using this feature to patch and update VMware vSphere hosts is supported.

However, using this feature to patch and update the guest OS is only supported by some applications and some versions, this is what is shown on this page when referring to VUM support. Note that Cisco Unified Communications applications upgrades, patches and updates can not be delivered through VMware Update Manager.

This feature provides integration with 3rd-party backup utilities so that they can non-disruptively backup the OS and application in a Virtual Machine (VM). See also VMware Data Recovery and Copy Virtual Machine.

Existing UC app methods of backing up the software continue to be supported.

VMware Boot from SAN

VMware ESXi 4.1 is required for this feature. Even it works with 4.0, VMware's official support is only for 4.1 and later. Requires use of a "diskless" server - see Supported Hardware for tested reference configurations. Both VMware ESXi and UC apps are installed on, and boot from, the fibre channel SAN. See UCS page at www.cisco.com/go/swonly for storage support policy.

vSphere Storage Appliance (VSA)

If VSA is desired to be used as shared storage for a virtualized Cisco Collaboration deployment, it must meet the storage requirements for UC on UCS Specs-based or 3rd-party Server Specs-based (e.g. HCL, latencies, application VM capacity and performance needs).

Services and Support Contracts for VMware are Required

Customers deploying virtualized UC must have a valid support contract for the VMware software in order to be supported by Cisco.

Customers purchasing VMware software licenses from Cisco must also purchase a subscription services part number from Cisco (for part number examples, see the UC on UCS page at www.cisco.com/go/swonly).

Customers purchasing VMware software from a 3rd-party must purchase subscription services from that 3rd-party or from VMware.

Customers should note that for VMware vSphere Hypervisor (formerly called “ESXi Single Server Edition” or “free ESXi”), VMware does not offer the same services options and terms as they do for their Standard, Advanced, Enterprise or Enterprise Plus Editions. Customers should take this into account when planning and pricing their support strategy.

Cisco Field and Channel Partners may consult the User Connect Licensing Ordering Guide for more information.

Cisco TAC Support Expectations

The following table describes how TAC support works for VMware in a UC on UCS context, based on who VMware was purchased from.

Special case: when Cisco as a VMware reseller sells VMware Enterprise License Agreements, it is treated as a VMware direct sale for TAC support purposes based on how the maintenance contracts are structured.

TAC Responsibility: Note that multi-vendor triage is the norm in virtualized deployments, where the storage, server, hypervisor, OS and application are potentially all from different vendors. Cisco Voice TAC responsibility is the UC application, demarcated at the Virtual Machine. Cisco Server Virtualization TAC responsibility is for VMware (via triage), Cisco UCS, Cisco storage access (or triage with customer and their vendor) and storage array (via triage with customer and their vendor). Escalation to VMware, the customer, or the customer's storage vendors will be done as needed for solution components not produced by Cisco.