Taking a Look at VMware Feature Limitations

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.

Share this Article:

The following two tabs change content below.
Steve Beaver
Stephen Beaver is the co-author of VMware ESX Essentials in the Virtual Data Center and Scripting VMware Power Tools: Automating Virtual Infrastructure Administration as well as being contributing author of Mastering VMware vSphere 4 and How to Cheat at Configuring VMware ESX Server. Stephen is an IT Veteran with over 15 years experience in the industry. Stephen is a moderator on the VMware Communities Forum and was elected vExpert for 2009 and 2010. Stephen can also be seen regularly presenting on different topics at national and international virtualization conferences.
Steve Beaver

Latest posts by Steve Beaver (see all)

Related Posts:

Leave a Reply

2 Comments on "Taking a Look at VMware Feature Limitations"

Sort by:   newest | oldest | most voted

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.