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 FeatureUnified CCXCisco WFO, QM, and WFMUnified CCE, CVPUnified ICCisco MediaSenseSocialMiner
VM Templates (OVAs)Y(C)Y(C)Y(C)Y(C)Y(C)Y(C)
Copy Virtual MachineY(C)Y(C)Y(C)Y(C)NoY(C)
Restart Virtual Machine on Different ESXi HostY(C)Y(C)Y(C)Y(C)NoY(C)
Resize Virtual MachineY(P)Y(P)NoY(P)NoNo
VMware Hot AddNoNoNoNoNoNo
Multiple Physical NICs and vNICsY(P)Y(P)Y(P)Y(P)NoNo
VMware High Availability (HA)NoNoNoNoNoNo
VMware Site Recovery Manager (SRM)NoNoNoNoNoNo
VMware vNetwork Distributed SwitchY(C)Y(C)NoY(C)Y(C)No
VMware vMotionY(C)Y(P)NoNoNoNo
VMware Dynamic Resource Scheduler (DRS)NoNoNoNoNoNo
VMware Dynamic Power ManagementNoNoNoNoNoNo
Long Distance vMotionNoNoNoNoNoNo
VMware Storage vMotionY(C)Y(C)NoNoNoNo
VMware vCenter Update Manager (VUM)NoNoNoNoNoNo
VMware Consolidated Backup (VCB)NoNoNoNoNoNo
VMware Data Recovery (DR, VDR)NoNoNoNoNoNo
VMware SnapshotsNoNoNoNoNoNo
VMware Fault Tolerance (FT)NoNoNoNoNoNo
VMware vCenter ConverterNoNoNoNoNoNo
VMware vShieldNoNoNoNoNoNo
Virtual Appliance Packaging of UC appsNoNoNoNoNoNo
3rd-Party VM-based Backup Tools (e.g. Veeam, Viziocore, esXpress)NoNoNoNoNoNo
3rd-Party VM-based Deployment Tools (e.g. rPath, Platespin)NoNoNoNoNoNo
3rd-Party Physical To Virtual (P2V) Migration ToolsNoNoNoNoNoNo
All others not listedNoNoNoNoNoNo
VMware Boot from SANY(C)Y(C)Y(C)Y(C)Y(C)Y(C)
All other vSphere FeaturesNoNoNoNoNoNo

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:

Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInShare on RedditEmail this to someone
Steve Beaver (181 Posts)

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.

Connect with Steve Beaver:

Related Posts:

2 thoughts on “Taking a Look at VMware Feature Limitations”

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *

17 − two =