Since the introduction of virtualization there has been sheer joy and excitement when having to work with application owners on the amount of resources they will need and not what they really think they want. I have seen all kinds of minimum, maximum, and special recommendation for all kinds of application over the years. In most cases, applications have evolved to be able to thrive in a virtual environment without too many limitations. Now it seems we have to verify which VMware features are fully supported with certain virtualized application also.
I was looking through some documentation on running Cisco applications like Contact Center, Unity, Customer Voice Portal, Contact Center Enterprise, and Unified Communication in a virtualized environment. I found each feature spelled out for each product and I have to wonder how long CISCO is going to be able to have all these feature limitations in place or do they really want things to continue running in physical infrastructure. So far CISCO will only really support the application on the UCS platform and will only support VMware ESXi 4.x and above.
Here is a look at one specific features sets that was taken from Cisco’s Unified Communications VMware Requirements Documentation.
Legend for Feature Support Tables
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.
VMware Feature Support for Contact Center 8.0(2) through 8.6(1)
vSphere Feature | Unified CCX | Cisco WFO, QM, and WFM | Unified CCE, CVP | Unified IC | Cisco MediaSense | SocialMiner |
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) | No | Y(C) |
Restart Virtual Machine on Different ESXi Host | Y(C) | Y(C) | Y(C) | Y(C) | No | Y(C) |
Resize Virtual Machine | Y(P) | Y(P) | No | Y(P) | No | No |
VMware Hot Add | No | No | 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 | No | No | No | No |
VMware Site Recovery Manager (SRM) | No | No | No | No | No | No |
VMware vNetwork Distributed Switch | Y(C) | Y(C) | No | Y(C) | Y(C) | No |
VMware vMotion | Y(C) | Y(P) | No | No | No | No |
VMware Dynamic Resource Scheduler (DRS) | No | No | No | No | No | No |
VMware Dynamic Power Management | No | No | No | No | No | No |
Long Distance vMotion | No | No | No | No | No | No |
VMware Storage vMotion | Y(C) | Y(C) | No | No | No | No |
VMware vCenter Update Manager (VUM) | No | No | No | No | No | No |
VMware Consolidated Backup (VCB) | No | No | No | No | No | No |
VMware Data Recovery (DR, VDR) | No | No | No | No | No | No |
VMware Snapshots | No | No | No | No | No | No |
VMware Fault Tolerance (FT) | No | No | No | No | No | No |
VMware vCenter Converter | No | No | No | No | No | No |
VMsafe | No | No | No | No | No | No |
VMware vShield | No | No | No | No | No | No |
Virtual Appliance Packaging of UC apps | No | No | No | No | No | No |
3rd-Party VM-based Backup Tools (e.g. Veeam, Viziocore, esXpress) | No | No | No | No | No | No |
3rd-Party VM-based Deployment Tools (e.g. rPath, Platespin) | No | No | No | No | No | No |
3rd-Party Physical To Virtual (P2V) Migration Tools | No | No | No | No | No | No |
All others not listed | No | No | No | No | No | No |
VMware Boot from SAN | Y(C) | Y(C) | Y(C) | Y(C) | Y(C) | Y(C) |
All other vSphere Features | No | No | No | No | No | No |
All these limitations go against what cloud computing is really supposed to be about, availability. To design an environment for these applications, a specific cluster with basically all the VMware features disabled with no ability to perform backups or maintain availability of the application is required. This alone would prohibit the ability to run in the true general cloud population but would really have to be isolated to a few hosts in a specific cluster. With the release of VMware ESX5, even more of the new features will be off limits for these applications. I do understand the technical reasons of why these features are presented with their limitation (such as no time to test against). However, I really have to question the limitation of certain features and the reason it is not supported as they have nothing to do with the application but the virtual environment. I will let you come to your own conclusions. Let me know what you think.
I too am working on Cisco UC deploymnet. I agree with you that Cisco has managed to gut the features of virtualization. My biggest peeve with their design requirements is not the limitation of having to disable DRS and HA (along with the host of other features), it is the 1:1 vCPU to core requirement. That single requirement drives the cost of the solution through the root on the 2 CPUs they support. Only getting a 5:1 consolidation ratio in today’s world is just sad.
Yeah the affinity requirememnt for Unity left me scratching my head a little going “really”. As a part of the VCE I guess I was expecting / hoping for something better.