存储厂商都怎样使他们的产品更适应虚拟化？VAAI存储又对虚拟化的未来有什么影响呢？

Jon William Toigo：VMware有件事让我不太满意，大约两年前，VMware发布了VAAI（vStorage APIs for Array Integration），在SCSI上写了九个原语或者说有九条命令。而它们并没有事先得到ANSI T10技术委员会的批准，ANSI T10技术委员会负责监督用于和存储设备以及其它外围设备的SCSI控制语言。VMware就任意创建了九个新命令，并表示：“我们期望减少工作流，在VMware中将工作流卸载到存储阵列上非常困难。”所以如果你需要镜像操作，为什么VMware还要管理镜像操作？相反，通过一个特殊的指令来卸载到一个有阵列镜像的存储阵列，它将镜像到另一个物理阵列，这就有点走后门的意思了。这也许可以降低他们在服务器虚拟化环境中遇到的80%的拥堵量。他们只是想把所有繁重的负载卸载到存储阵列控制器上。

但是这一理论的问题是，如果你把命令和数据发送给一个不支持VAAI、不懂原语、不是VAAI存储，也不明白这些指令和控制语言的存储阵列后会发生什么事情？另外，谁给VMware做这个改变的权利？这也是这种情况下最大的问题。底线是这个行业发展的特别快，而且现在已经有很多VAAI存储选项。厂商的责任究竟是使虚拟化环境下的存储更容易，还是先要去解决控制器厂商制造出来的问题呢？

这是我对VMware更有意见的地方。在VMworld大会上，有190个厂商的展位，这些厂商都是VMware生态系统的一部分。但是如果你和任何一个厂商聊这个话题时，他们都会告诉你他们正在修复VMware中断的问题。所以这基本上就是一个由主流厂商创建的生态系统问题。这似乎并不是我想看到的。

目前，我们正面临一个非常糟糕的状况。从某种程度上来说，我们在云技术领域也看到了这个问题，每个虚拟化hypervisor厂商在关于存储如何工作的问题上都有自己的看法。你现在和VMware谈论做自己的存储hypervisor作为他们的套件的一部分，而这意味着我不得不将我花了十年才汇聚合成的光纤存储基础架构分开。所以我不得不削减服务其它厂商的时间来服务VMware？然后会怎样呢？我可能还得削减出更多的时间来服务那些运行Hyper-V、Citrix以及Oracle的服务器。这很荒谬。