Unified Communications VMware Requirements

From DocWiki

Revision as of 20:34, 13 December 2010 by Wamaxwel (Talk | contribs)
Jump to: navigation, search

This article describes VMware requirements, feature support, and services and support contracts for virtualized Unified Communications applications.

Contents

VMware is Mandatory for UC on UCS

All UC on UCS servers require use of VMware ESXi 4.0 to be supported. See the other sections on this page for specific VMware product and version support, and specific VMware feature support.

Nonvirtualized, physical, or bare-metal installations are not supported with UCS servers.

UC on UCS requires Cisco Unified Communications 8.0(2) or higher - specific applications and versions are covered at http://www.cisco.com/go/uc-virtualized.

For "legacy" virtualization support of Version 7.x applications on VMware on 3rd-party servers, see the following documents:

Required VMware Licensing and Customer Purchase Options

VMware licenses software on a per-physical-CPU-socket basis (not physical CPU cores or virtual CPUs or virtual CPU cores). Each populated CPU socket per server requires a VMware license (with VMware product and version that is supported by Cisco UC).

While VMware ESXi 4.0 is mandatory for UC to run on UCS servers, customers may purchase this license from any of the following sources:

  • From Cisco, as a preset “per-server” Cisco Collaboration part number. This part number is separate from server hardware part numbers. You can use the same part number for Cisco UCS B-Series and C‑Series deployments. Note that for the Cisco UCS B-Series, you need to add this part number to a group of data center part numbers ordered through the Netformx DesignXpert ordering tool UCS Advisor. Only VMware ESXi Standard Edition is available via this option. The part number is “hard-coded” for two CPU sockets (no more, no less) and one year service subscription (no multi-year or auto-renewals).
  • From Cisco, as an option under a build-to-order “per CPU socket” data center part number for the server: Note that for the Cisco UCS B-Series, you must order this option through the Netformx DesignXpert ordering tool UCS Advisor. Only VMware Advanced, Enterprise or Enterprise Plus Editions are available via this option. One year and three year service subscription options are available.
  • From VMware directly or other 3rd-party: With this option, you can order any VMware ESXi Edition you want, as well as take advantage of any existing customer licensing arrangement with VMware (such as a site or enterprise license).
  • When running Virtual machines with more than 4 vCPUs, VMWare ESXi Enterprise Plus license is required by VMWare.

For part number and SKU examples, see Table 1 of the UC on UCS page at www.cisco.com/go/swonly . Cisco employees and Channel Partners may also consult the UC on UCS chapter of the Cisco User Connect Licensing ordering guide on Cisco Partner Central.

Note: in all cases, the customer is required to have a valid service contract with VMware to be supported (see Services and Support Contracts for VMware are Required)

Hypervisor Support for Virtualized UC (Vendors, Products, Versions, Editions)

At this time, the only hypervisor vendor supported for virtualized UC is VMware.


VMware vSphere ESXi 4.0 is required for UC on UCS.

  • VMware ESX, regardless of version, is not supported for servers hosting Cisco Unified Communications. This is due to technical reasons and VMware’s direction to transition from ESX to ESXi. Note a VMware ESX cluster can contain VMware ESXi servers running Cisco Unified Communications.
  • Versions of VMware ESXi prior to 4.0 are not supported due to technical reasons. Maintenance and patch versions and updates on 4.0 (such as 4.0 Update 1 or "4.0U1") are supported at the time of release from VMware. At this time ESXi 4.1 is only supported for CUCMS. Future ESXi minor and major releases (such as hypothetically 4.2 or 5.0) are not supported for Cisco Unified Communications until explicitly indicated on this site.


VMware ESXi is sold in several editions with different levels of feature support. A comparison of VMware ESXi 4.0 editions is available at https://www.vmware.com/products/vsphere/buy/editions_comparison.html and in the “A La Carte Features” chapter of https://www.vmware.com/files/pdf/vsphere_pricing.pdf.

VMware vSphere Hypervisor (formerly named VMware ESXi Single Server Edition or “free ESXi”) is the minimum edition required for most software to install, but an edition that supports robust, multihost management via VMware vCenter - Standard, Advanced, Enterprise, or Enterprise Plus - is strongly recommended. Enterprise Plus license is mandatory is required when installing virtual machines that use more than 4 vCPUs, e.g. is the 20,000 user Unity Connection overlay.

Also note that while any Edition may be used, Cisco Unified Communications may not yet support all the features in the desired Edition (such as vMotion). See VMware Infrastructure Feature Support.

Any virtualized deployment that does not align with the above rules (even non-production labs) is not supported by Cisco TAC.

Support of Cisco VN-Link and Cisco Nexus 1000V

Note that Cisco Unified Contact Center Enterprise does NOT support this – see UCS Network Configuration for Unified CCE.

Unless otherwise indicated above, Cisco VN-Link and Cisco Nexus 1000V are supported by UC applications that support the VMware vNetwork Distributed Switch (see VMware Infrastructure Feature Support).

Cisco VN-Link, Cisco Nexus® 1000V and VMware vNetwork Distributed Switch all require VMware ESXi Enterprise Plus Edition (see VMware Infrastructure Feature Support). Other editions do not support these capabilities.

For UC on UCS B-series, Cisco UCS 6100 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 the only way to manage traffic congestion through the current UCS 6100. Please recall that traffic congestion risk will vary and is dependent on many factors such as UC vs. non-UC virtual machine count and their traffic characteristics across all blades, chassis and fabric extenders connected to the same UCS 6100.

For UC on UCS C-series, Cisco Nexus® 1000V is recommended but not mandatory as there is no intermediate UCS 6100 to design around.


For more information on Cisco VN-Link and Cisco Nexus 1000V, see http://www.cisco.com/en/US/netsol/ns894/index.html and http://www.cisco.com/en/US/products/ps9902/index.html.

VMware Infrastructure Feature Support

NOTE: VMware Infrastructure feature support for Cisco Unified Contact Center Enterprise varies by component - this section will give a summary support position, but for individual components see Support for Virtualization on the ESXi/UCS Platform.

VMware vSphere and vCenter include a number of innovative features such as vMotion that are not available with traditional physical hardware installations. Not all of these features lend themselves to real-time streaming media applications such as Cisco Unified Communications. The table below lists VMware features and their current support status for use with Cisco Unified Communications application virtual machines.

As Cisco Unified Communications adds support for additional VMware features, this site will be updated as applicable. For an authoritative description of each feature, see VMware collateral at http://www.vmware.com/products/vsphere/buy/editions_comparison.html. Note that virtualized UC usually only supports a subset of available VMware features as described in the table below. Feature support may vary by UC application, and features are usually supported only with conditions or caveats due to the real-time nature of UC.


Legend:

  • C = Supported with Caveats - see Best Practices for details
  • 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.


VMware Feature Support for Cisco Unified Communications 8.0(2) through 8.5(1)
Feature Unified CM Unity Connection Unity Unified Presence Unified CCX Unified CCE Unified IC Cisco MediaSense CER SME Unified Attendant Consoles UC Management Suite (OM, SM, SSM, PM)
vSphere ESXi 4.0 Features
VM Templates (OVAs) C C C C C C C C C C C C
Copy Virtual Machine C C C C C C C No C C No No
Restart Virtual Machine on Different ESXi Host C C C C C C C No C C C C
Resize Virtual Machine P P P P P No P No P P No No
VMware Hot Add No No No No No No No No No No No No
Multiple Physical NICs and vNICs P P P P P P P No P P P P
VMware High Availability (HA) C C C C No No No No C C No C (PM only)
VMware Site Recovery Manager (SRM) C No No No No No No No C C No No
VMware vNetwork Distributed Switch C C C C C C C No C C No No
VMware vMotion P P No P P No No No P No No P (PM only)
VMware Dynamic Resource Scheduler (DRS) No No No No No No No No No No No No
VMware Dynamic Power Management No No No No No No No No No No No No
Long Distance vMotion No No No No No No No No No No No No
VMware Storage vMotion C No No No C No No No C No No No
VMware vCenter Update Manager (VUM) No No C No No No No No No No No No
VMware Consolidated Backup (VCB) No No C No No No No No No No No No
VMware Data Recovery (DR, VDR) No No No No No No No No No No No No
VMware Snapshots No No C No No No No No No No No No
VMware Fault Tolerance (FT) No No No No No No No No No No No No
VMware vCenter Converter No No No No No No No No No No No No
VMsafe No No No No No No No No No No No No
VMware vShield No No No No No No No No No No No No
Virtual Appliance Packaging of UC apps No No No No No No No No No No No No
3rd-Party VM-based Backup Tools (e.g. Veeam, Viziocore, esXpress) No No No No No No No No No No No
3rd-Party VM-based Deployment Tools (e.g. rPath, Platespin) No No No No No No No No No No No No
3rd-Party Physical To Virtual (P2V) Migration Tools No No No No No No No No No No No No
All others not listed No No No No No No No No No No No No
vSphere ESXi 4.1 Features
Boot from SAN No No No No No No No No No No No No
All other vSphere ESXi 4.1 Features No No No No No No No No No No No No

Best Practices

Virtual Machine Templates (OVA files)

NOTE: support varies by app and version. Before reading the best practices below, verify support at VMware Infrastructure Feature Support.

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

NOTE: support varies by app and version. Before reading the best practices below, verify support at VMware Infrastructure Feature Support.

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

NOTE: support varies by app and version. Before reading the best practices below, verify support at VMware Infrastructure Feature Support.

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 VMware Infrastructure Feature Support.

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.

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 VMware Infrastructure Feature Support.

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 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 VMware Infrastructure Feature Support.

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 VMware Infrastructure Feature Support.

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 vNetwork Distributed Switch

NOTE: support varies by app and version. Before reading the best practices below, verify support at VMware Infrastructure Feature Support.

Supporting apps in UC on UCS may either use this feature, or the Cisco VN-Link technology (such as Cisco Nexus 1000V).


VMware vMotion

NOTE: support varies by app and version. Before reading the best practices below, verify support at VMware Infrastructure Feature Support.

This feature migrates a live, running Virtual Machine (VM) from one physical server to another. While used in general data centers for a variety of maintenance and cost savings activities, only a “maintenance mode” usage is supported at this time for UC:

  • 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.
  • "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.
  • The only supported scenario is a “live but quiescent” software 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.

VMware Dynamic Resource Scheduler

Not supported. 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 VMware Infrastructure Feature Support.

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 vCenter Update Manager (VUM)

NOTE: Support varies by application and version. Before reading the best practices below, verify support at VMware Infrastructure Feature Support. For more details on Cisco Unity support, see http://www.cisco.com/en/US/docs/voice_ip_comm/unity/virtualization_design/guide/cuvirtualdg010.html#wp82246.

This feature automates patching and updating of VMware vSphere hosts. Note that Cisco Unified Communications applications upgrades, patches and updates can not be delivered through vCenter Update Manager.

VMware Consolidated Backup (VCB)

NOTE: support varies by app and version. Before reading the best practices below, verify support at #VMware Infrastructure Feature Support. For more details on Cisco Unity support, see http://www.cisco.com/en/US/docs/voice_ip_comm/unity/virtualization_design/guide/cuvirtualdg010.html#wp82246.

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 VMware Infrastructure Feature Support. For more details on Cisco Unity support, see http://www.cisco.com/en/US/docs/voice_ip_comm/unity/virtualization_design/guide/cuvirtualdg010.html#wp82246.

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.

Boot from SAN

Not supported. Pre-requisite to support is UC certfication of VMware ESXi 4.1 which is not supported at this time.

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.


Buy from Cisco as Collaboration SKU Buy from Cisco as Data Center SKU Buy from 3rd-party, or enterprise/site license
Available VMware ESXi Editions Standard Advanced, Enterprise or Enterprise Plus Standard, Advanced, Enterprise, Enterprise Plus or vSphere Hypervisor (formerly "Single Server Edition" or "free ESXi"
Mandatory Support Contracts ISV1 from Cisco as Collaboration Service SKU ISV1 from Cisco as Data Center Service SKU "SnS" subscription from VMware
Who takes first call? Cisco Cisco VMware

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.


Back to Unified Communications Virtualization main page

Rating: 4.2/5 (37 votes cast)

Personal tools