甲骨文在其支持策略上不再明确地排除Real Application Cluster（RAC）产品能用于VMware服务器虚拟化。

　　这是迈向正确方向的一大步，IT人士表示。但是，将RAC带入甲骨文现有的用于甲骨文数据库的VMware支持策略时，就停滞不前了，意味着甲骨文仍然不能预知用户选择何种服务器虚拟化平台。该支持策略包括：

　　甲骨文的任何产品都不在VMware虚拟化环境中进行验证。甲骨文支持团队将帮助客户以下面方式在VMware上运行甲骨文产品：甲骨文只对在自身操作系统已知的或发生的问题，或者能证明不是由于运行VMware才出现问题的时候，才进行支持。

　　RAC不再是个特别的例外，这个事实至少表明甲骨文不再那么敌视VMware。但支持策略不是用户决定是否虚拟和如何虚拟甲骨文的首要因素。

　　甲骨文虚拟化的障碍

　　不管甲骨文对待VMware的方式如何，用户在独立的Oracle VM平台或者VMware运行甲骨文应用有着自己的想法。而且，在评估是否虚拟化甲骨文应用和数据库时，hypervisor平台的选择只是用户必须考虑的因素之一。

　　一些用户已经证实VMware的产品存在局限，所以他们避免虚拟化Oracle的RAC，而不是因为甲骨文的支持策略。

　　VMware对于附属在Raw Device Mapping（RDM）模式里的RAC集群共享SCSI总线的虚拟机不提供vMotion支持。因此，如果一台物理RAC服务器是处于维护模式，用户只能关掉Oracle虚拟机，才能将它们移动到另一台RAC集群节点，这在业务关键环境中违反了生产服务器级别协议。

　　另一些人指出，这也存在一些许可条例，在vSphere上运行Oracle之前需要考虑到，不管是支持还是技术问题。

　　例如Oracle Enterprise Edition版本仍然有个预配置处理器许可机制，尽管通常的策略是软件厂商实行的是预插槽或者预虚拟CPU许可策略来适应虚拟化。

　　不过，对于来自Sun或Oracle VM的硬分区有个例外，但是VMware不是硬分区，所以你得将与虚拟机相关的所有组件都进行许可。你可以限制虚拟机宿主的地点，但某些情况下这会让虚拟化失去意义。

　　然而，RAC支持策略的更改是“迈向正确方向的一大步，”Reiter说，“支持协议的更改将改变我们的计划，现在，如果一个客户来找我们，并想在我们的云环境中运行RAC，我们就能如他们所愿了。”他说，“虽然最终我比较希望看到一个许可模式能够与虚拟化技术协调工作。”

　　削减甲骨文成本

　　一些用户在避免复杂性，对虚拟化第一层应用（如数据库）作出了很大努力，而不理会虚拟化平台。同时，他们开始审查甲骨文环境中的其他可虚拟化组件。

　　Chris Rima就是这样的一位用户，在基于Sun SPARC的硬件上运行Oracle应用，这意味着他可能会使用甲骨文的全套产品，缺失的组件是Oracle VM。

　　Rima说他的虚拟化旅程进行得小心翼翼，尤其是在明年虚拟化甲骨文的中间件和管理软件层时，但是可能会使用vSphere来进行尝试，他组织中的其他一些应用已经在使用vSphere。

　　对于Rima来说，通过在Sun的专有SPARC处理器上只运行该软件最关键的分区，并将其他分区尽量移到一般的x86硬件上去，使用vSphere虚拟甲骨文应用的决定意味着削减硬件和运营成本。

　　“我们关于甲骨文数据库的核心经验在SPARC上，”Rima说，“对于一些没有数据库重要的非关键应用，我们就使用x86硬件来节约成本……并且我们内部也没有专门的工程师来支持两种hypervisor环境。”