Virtualization Software Requirements


Virtualization Software Requirements - Required vs. Supported Vendors, Products, Versions and Feature Editions

(top)

Note: 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/virtualized-collaborationd.

Mandatory Virtualization Software

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

Unsupported Infrastructure / Virtualization Software
  • 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.



Purchasing / Sourcing Options for Required Virtualization Software

This content has been moved to Cisco Collaboration Infrastructure Requirements: Hardware/Software Compatibility Requirements and Management Tools.

License Comparison- Shipping

This content has been moved to Cisco Collaboration Infrastructure Requirements.

License Comparison - Install Base

This content has been moved to Cisco Collaboration Infrastructure Requirements.


Supported Versions, Patches and Updates of VMware vSphere ESXi

(top)

ESXi Major/Minor Versions, Maintenance Versions and Patches/Updates

  • Cisco Collaboration apps will explicitly indicate which Major/Minor versions they support (e.g. ESXi 4.0, 4.1, 5.0, 5.1, 5.5). There is no "or later" ... unlisted versions are not tested/supported.
  • With a particular supported major/minor version (such as ESXi 5.1)...
    • A Cisco Collaboration app will only specifiy a minimum maintenance release (e.g. 5.1 U1) if required by its guest OS or for hardware compatibility.
    • A Cisco Collaboration app will only specify a MAXIMUM maintenance release if there are known incompatibilitites. To date this has never been the case, so if the hardware vendor supports it, it is allowed even if unlisted. Cisco recommendation is to use the latest Maintenance release supported by the hardware vendor.
    • Cisco Collaboration apps do not prescribe or proscribe individual ESXi patches and updates. Cisco recommendation is to apply the latest patches and updates recommended by VMware and your hardware vendor. The following links can be used to determine if an individual Maintenance Release or patch "can" or "should" be deployed:
      • VMware Compatibilty Guide (http://www.vmware.com/go/hcl)  for the the vSphere ESXi Major/Minor version supported by Cisco Collaboration.
      • Server Vendor's hardware compatiblity information for the vSphere ESXi Major/Minor version required by Cisco Collaboration. E.g. for Cisco UCS, see the Server Compatiblity documents at http://www.cisco.com/en/US/partner/products/ps10477/prod_technical_reference_list.html.
      • Always verify with server vendor if a hardware-vendor-specific ESXi image is required. E.g. you want to upgrade from 5.0 to 5.0 U3. If the server is Cisco UCS, you may need to use a UCS-specific image for U3 on vmware.com.
      • Always verify with server vendor that the update is compatible with server model's bios/firmware/driver state. E.g. 5.0 U3 on UCS C220 M3 SFF, check the UCS interop matrix to see if any updates required before U3 will work on that hardware.
      • Before applying a VMware upgrade or update to a host, always verify compatibility with each Cisco Collaboration app (At a Glance table at http://www.cisco.com/go/virtualized-collaboration.)
Note that use of VMware vSphere ESXi 4.1 requires disabling the "LRO" setting (click here for details).

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:


Virtual Machine Version (vmv)

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.

Virtual Machine File System (VMFS)

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

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.

Which method to use: Early versions of the Collaboration applications required a COP file in order to upgrade the VMware Tools. Later, a CLI command was created to make the upgrades easier. Finally once the applications ran on newer embedded OS versions, it became possible to support automatic tools upgrades.

For a given application/release, use ONLY the supported method(s) to upgrade the tools. The use of the wrong method almost certainly will fail and at worst may corrupt your virtual machine.

Application Release Method
Unified CM
(includes standalone ELM)
9.0 and later 2 or 3
Cisco Emergency Responder 9.0 1, 2 or 3
10.0 and later 3
Cisco Unity Connection 9.0 and later 2 or 3
IM and Presence Service 9.x 1
10.0 2 or 3
10.5 and later 3
Unified CCX 9.0 and later 1
Unified CCE 9.0 and later 2
Cisco Finesse 9.1(1) and later 1, 2 or 3
Cisco MediaSense 9.0(1) and later 2 or 3
Cisco Social Miner 9.0 and later 2
Cisco Unified Intelligence Center 9.0(1) to 11.6(1) 1
Cisco Virtualized Voice Browser 11.5(1) and later 2 or 3

Method 1: CLI command

   Step 1 From the vSphere Client log in to vCenter, or your ESXi host, and go to the Hosts and Clusters view (Ctrl+Shift+H).

Step 2 To mount the correct version of the VMware Tools software in the Guest virtual CD/DVD drive, perform the following sub-steps.

    a. Right-click the virtual machine that you are upgrading, and choose Guest > Install/Upgrade VMware Tools.

    b. In the popup window choose Interactive Tools Upgrade.

Step 3 From the Unified CM CLI, enter the CLI command utils vmtools upgrade. ( For Cisco Unified Intelligence Center 11.0 and later enter CLI command utils vmtools refresh. See the Install and Upgrade guide for Cisco Unified Intelligence Center 11.0 and later for more details.)

The system reboots twice. Monitor the virtual machine console from the vSphere Client to see the system status.

Step 4 When the system is back up, the tools status is updated to OK from the vCenter Summary tab for the virtual machine that you upgraded.

Step 5 After installation of the new version of VMware Tools is complete, remove the VMware Tools tar file from the virtual CD/DVD drive. (Usually, the VMware Tools tar file is called linux.iso). To remove the VMware Tools tar file, perform the following substeps.

    a. Right-click the virtual machine that you are upgrading, and choose VM > Edit Settings > CD/DVD drive.

    b. Choose Device Type as Client Device.



Method 2: Upgrade from viClient

   Use the following procedure to perform this upgrade.

Step 1 From the viClient, Initiate the tools upgrade by clicking on VM > Guest > Install / Upgrade VMware Tools (this can also be done by right-clicking on the VM).

Step 2 Choose the automatic tools update and press OK.

Step 3 The process will take a few minutes. The task should then be complete and the tools should be shown as "OK". No reboot is required.
 



Method 3: Automatically check and upgrade VMware Tools at boot time

   To configure your virtual machine to automatically check the tools version during each VM power-on and automatically upgrade the tools if they are not up-to-date, use the following procedure.

Step 1 Edit the VM settings by clicking on the Options tab, and select VMware tools. Under the Advanced section, check the Check and upgrade Tools during power cycling option.

    A check will now be performed each time the VM powers on to determine if the tools need to be updated. Updates are performed automatically.

    Note: If the tools do need to be updated, the VM may go through an additional boot cycle to update the tools. This will occur automatically.




Supported Features of VMware vSphere ESXi, VMware vCenter and VMware vSphere Client

(top)

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.

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
VMware Feature Support for Unified Communications

For guide to abbreviations, see At a Glance table at http://www.cisco.com/go/virtualized-collaboration.

Feature CUCM PCD
PLM
Cisco
Paging
Server
CER SME CUxAC PCP PCA Unity
Connection
IM&P Expwy
VM Templates (OVAs) Y(C) Y(C) Y Y(C) Y(C) Y(C) Y Y Y(C) Y(C) Y(C)
Copy Virtual Machine Y(C) Y(C) Y(C) Y(C) Y(C) No Y(C) No Y(C) Y(C) No
Large Receive Offload (LRO) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) No
Restart Virtual Machine on Different ESXi Host Y(C) Y(C) Yes Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C)
Resize Virtual Machine Y(P) Y(P) No Y(P) Y(P) Y(P) Y(P) Y(P) Y(P) Y(P) No
Multiple Physical NICs and vNICs Y(P) Y(P) No Y(P) Y(P) Y(P) Yes Y(P) Y(P) Y(P) Y(P)
VMware High Availability (HA) Y(C) Y(C) No Y(C) Y(C) No Y(C) No Y(C) Y(C) No
VMware Site Recovery Manager (SRM) Y(C) Y(C) No Y(C) Y(C) No Y(C) No Y(C) Y(C) No
Softswitches
  • VMware vNetwork Distributed Switch (vDS)
  • Cisco Nexus 1000V
  • Cisco Application Virtual Switch (AVS)
  • Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C)
    VMware vMotion Y(C) Y(C) No Y(C) Y(C) Y(P) Yes No Y(C) Y(C) Y(C)
    Distributed Resource Scheduler (DRS) Y(C) No No No No No No No Y(C) Y(C) No
    Long Distance vMotion No No No No No No Y(C) No No No No
    VMware Storage vMotion Y(C) Y(C) No Y(C) No No Yes No No No No
    VMware Update Manager (VUM) Y(P) Y(P) No Y(P) Y(P) Y(P) Y(P) Y(P) Y(P) Y(P) Y(P)
    VMware Data Recovery (DR, VDR) No No No No No No Yes No No No No
    VMware Boot from SAN Y(C) Y(C) No Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C)
    VMware Snapshots No No Y(C) No No No Y(C) No No No No
    VMware Fault Tolerance (FT) No No No No No No Y(C) No No No No
    VMware vCenter Converter No No No No No No No No No No No
    Virtual Appliance Packaging of UC apps No No Yes No No No Y(C) No No No No
    vSphere Storage Appliance See Storage Requirements for Specs-based hardware support

    VMware Feature Support for Contact Center

    Feature Unified
    CCX
    Cisco WFO,
    QM, and WFM
    CVP Unified
    CCE, PCCE
    CUIC/ Finesse/ Ids/
    SocialMiner/ Virtual Voice Browser
    ECE
    VM Templates (OVAs) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C)
    Copy Virtual Machine Y(C) Y(C) Y(C) Y(C) Y(C) Y(C)
    Large Receive Offload (LRO) Y(C) Y(C) Y(C) Y(C) Y(C) Y(C)
    Restart Virtual Machine on Different ESXi Host Y(C) Y(C) Y(C) Y(C) Y(C) Y(C)
    Resize Virtual Machine Y(P) Y(P) No No No No
    Multiple Physical NICs and vNICs Y(P) Y(P) Y(P) Y(P) No No
    VMware High Availability (HA) No No Y(C) Y(C) No No
    Softswitches
  • VMware vNetwork Distributed Switch (vDS)
  • Cisco Nexus 1000V
  • Cisco Application Virtual Switch (AVS)
  • Y(C) No Y(C) See CCE documentation Y(C) Y(C)
    VMware vMotion Y(P) Y(P) Y(C) Y(C) Y(C) Y(C)
    VMware Storage vMotion No Y(C) No No No No
    VMware Boot from SAN Y(C) Y(C) Y(C) Y(C) Y(C) Y(C)
    VMware Snapshots No No Y(P)* Y(P)* No No
    vSphere Storage Appliance See Storage Requirements for Specs-based hardware support

    * Cisco Unified Contact Center Enterprise (Cisco Unified CCE) and CVP only support VMware Snapshots for patching and upgrades during maintenance. The snapshots must be merged before the Cisco Unified CCE and CVP systems transition to production.


    Best Practices

    (top)

    Virtual Machine Templates (OVA files)

    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.

    Copy Virtual Machine

    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 that copying a VM results in a change of the MAC address if it was not configured manually. This may result in having to request new licenses for applications where licensing is based on the MAC address (for example PLM or UCCX).

    Large Receive Offload (LRO)

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

    Collaboration Application & Version VMware vSphere ESXi Version Disable LRO required?
    CUCM 8.0(2) to 8.5 4.1 Yes
    CUCM 8.6 or higher 4.1 No
    CUCCX / IPIVR 8.0 to 8.5 4.1 Yes
    CUCCX / IPIVR 9.0 or higher 4.1 No
    All others Disable LRO if on ESX 4.1 and app version < 8.6.

    Otherwise disable LRO is optional. If you experience FTP/TCP latency, then disable LRO.

    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 normal TCP networking performance.

    Restart Virtual Machine on Different ESXi Host

    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.

    Resize Virtual Machine

    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.

    VMware Hot Add

    Not supported. See Resize Virtual Machine instead.

    Multiple Physical NICs and vNICs

    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.

    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)

    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.

    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)

    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.

    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. Cisco recommends to power off the VMs before the SAN replication occurs. Also always ensure a DRS backup of the Cisco Collaboration applications is available in case there are issues with the replicated VMs.

    Softswitches

    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.

    Please note the following caveats:

    • Cisco physical / virtual networking infrastructure is presumed transparent to Collaboration workloads.
    • Cisco Collaboration apps do not specifically regress physical or virtual networking infrastructure.
    • Cisco Collaboration apps do not consult on or debug virtual switch configuration outside of networking guidance in design guides.
    • Cisco TAC will isolate Collaboration app issues to the app or infrastructure.
    For deployments leveraging NAS/SAN storage and FCoE (such as UC on UCS B-Series / C-Series connected to Cisco 6x00 Fabric Interconnect Switches), a QoS-capable softswitch (like Cisco Nexus 1000V or alternatives) is strongly recommended.
    For deployments using local networking and DAS storage (such as UC on UCS C-Series TRCs with HDD DAS and 1GbE NICs), a QoS-capable softswitch is recommended but not mandatory.
    Note that 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.

    VMware vMotion

    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.

    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:

    • Prior to ESXi 5.1, VM must be installed on shared storage (SAN) and source and destination physical servers must be connected to same SAN. In ESXi 5.1+ vMotion allows "DAS to DAS", i.e. VM can be installed on DAS and source/destination physical servers can have different DAS yet still vMotion the VM.
    • 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.
    • For real-time load-balancing of live UC VMs (e.g. via Distributed Resource Scheduler [DRS]), a few applications have caveated support (see here for details); otherwise it is not supported.
    • 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.

    Distributed Resource Scheduler (DRS)

    UCM, IMP and CUC have caveated support (see Caveated Support for VMware CPU Reservations and Distributed Resource Scheduler). Not supported for other applications. See vMotion for what is supported.

    VMware Dynamic Power Management

    Not supported. See vMotion for what is supported.

    Long Distance vMotion

    Not supported. See vMotion for what is supported.Long Distance vMotion is a joint Cisco and VMware validated architecture for using the vMotion feature across data centers. For more information, see http://blogs.cisco.com/datacenter/comments/cisco_and_vmware_validated_architecture_for_long_distance_vmotion/ and http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns836/white_paper_c11-557822.pdf.

    Storage vMotion

    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.

    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:

    • Requires SAN storage.
    • May only be done during a maintenance window with UC VMs shut down.

    VMware Update Manager (VUM)

    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.

    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.

    VMware Consolidated Backup (VCB)

    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.

    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 Data Recovery

    Not supported. See VMware Consolidated Backup for what is supported.

    VMware Snapshots

    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.

    Used to preserve the state of a VM without copying or creating additional VMs, effectively as a backup/restore or reversion technique. See also VMware Data Recovery and Copy Virtual Machine.

    VMware Fault Tolerance

    Not supported. See VMware High Availability for what is supported. Another alternative is manual Virtual Machine shutdown and migration.

    VMware vCenter Converter

    P2V tools are not supported. To migrate from bare-metal servers (e.g. Cisco 7800 Series Media Convergence Server) to UC on UCS, the supported procedure is:

    • upgrade to 8.x software version on the bare-metal server
    • take a software backup
    • fresh install 8.x software on VMware / UC on UCS
    • restore from backup

    VMsafe

    Not supported. See the documentation for the UC application software or UC appliance software to see what is supported.

    VMware vShield

    Not supported. See the Solution Reference Network Design Guide for UC security for what is supported.

    Virtual Appliance Packaging of UC apps

    Not supported. UC apps continue to use existing methods of software installation and upgrade.

    3rd-Party VM-based Backup Tools

    Not supported. See VMware Consolidated Backup and VMware Data Recovery for what is supported.

    3rd-Party VM-based Deployment Tools

    Not supported. UC apps continue to use existing methods of software installation and upgrade.

    3rd-Party Physical To Virtual (P2V) Migration Tools

    Not supported. See VMware vCenter Converter for what is supported.

    VMware Boot from SAN

    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.

    vSphere Storage Appliance (VSA)

    VSA is not really a "feature" but rather a storage product from VMware.

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

    vSphere Data Protection (VDP)

    Not supported. VDP in vSphere ESXi 5.1 replaces "VDR" (vSphere Data Recovery / VMware Data Recovery) in prior ESXi releases: see http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2016565.