当我们谈到服务器虚拟化的阻碍因素时，我们的行业经常着眼于技术。但是通常，厂商的应用支持策略和许可条款是阻碍对应用进行虚拟的最大障碍。

　　单词“支持”不再准确，短语“不受支持”成为IT词典里最滥用的词，此含义如下：

• 这种配置不受支持，不要尝试！
• 这种配置可以，但会影响性能。
• 这种配置运行很好，但是，我们没有足够的资源测试每个可能的配置。如果没通过我们的验证将不受支持。

　　应用支持与虚拟化兼容

　　在虚拟化领域还有另外一种司空见惯的意思：我们不支持这种配置，因为它有助于我们的竞争者。厂商经常讲“倾听用户”与“帮助用户应对他们的挑战”，但大部分是厂商在保护和提升他们的市场份额。

　　厂商公开说的与其实际做的存在差距，尤其是在你阅读他们的应用支持策略时感受最深。例如，甲骨文将VMware、微软与思杰叫做“第三方虚拟化”。

　　甲骨文应用虚拟化

　　在其他厂商的虚拟化平台上能够运行的甲骨文软件有着严格限制。最近该公司改变其对VMware的支持策略。在我看来，这种改变微乎其微，没多大变化。

　　这个支持策略特别指出VMware，但我希望甲骨文对所有虚拟化厂商一视同仁。这份声明很长，所以我只引用突出的部分（注意事项是我的看法。）

　　如果问题出在甲骨文已知的问题，甲骨文支持将在自身操作系统上推荐最合适的解决方案。如果该解决方案在VMware虚拟环境中不起作用的话，用户最好向VMware寻求支持。当在原生操作系统上运行时，用户能证明甲骨文解决方案不起作用，甲骨文将重新支持，包括在需要的时候便于调查而使用Oracle Development登入漏洞。

　　注意：甲骨文没有在VMware上验证它自己的产品。对于Oracle RAC，甲骨文只接受如上所述的Oracle RAC 11.2.0.2及以上的版本。
　
　　基本上，甲骨文的定位就是“不要找我们。找他们。”它迫使用户在甲骨文担起责任之前在物理硬件复制问题。

　　现在，甲骨文不能支持完全不同厂商的产品的理由充分。这也是VMware在vCenter里不支持微软集群服务的原因。能运行，只是VMware不支持另一个厂商的产品。但这对用户没帮助。没人想通过构建不受支持的配置让昂贵的支持合同失效。

　　甲骨文故意让用户觉得为难。在绝大部分支持案例中，你会发现虚拟机里面的应用对虚拟机毫无办法。（对不住，我需要强调这一点。）甲骨文使用这种蛋疼的支持策略是因为想在用户那偷偷插入自己的虚拟化平台。这就难怪自从在2007年购得自己的hypervisor后，它与其亲密合作伙伴VMware的关系变得尴尬了，

　　熟悉虚拟化的人们对甲骨文的应用支持策略见怪不怪了。毕竟，它类似于微软几年前对不是微软虚拟化的产品的支持策略。幸好，微软最终更改了其策略。但甲骨文仍在孤行。

　　在用户咨询我时，我看到他们的焦虑在增加。“这种配置受支持么？”这使得一些应用厂商开始反思他们的支持条款。当然，厂商又不是吃素的，也需要盈利，但这并不代表允许他们减少竞争与选择。