VMware的补丁记录至少可以说是质量参差不齐的。VMware Update Manager (VUM)是类似于微软的Windows Update和SUSE Linux的Yellow Dog Updater Modified的产品。VMware当初推出它的过程是很缓慢的。在VUM发布的2008年以前，客户们被迫只能写脚本来对ESX主机进行补丁更新。通常的做法是使用文本操作来查询.XML文件，以确定VMware的补丁都按照合适的顺序进行了安装。

　　ESXi和VUM是为了减少VMware的补丁更新频率和复杂度而设计的。虽然VUM擅长于下载和安装补丁，但是它依赖于VMware参差不齐的质量控制(QA)。不少VMware的补丁和更新都使它的Hypervisor产生了问题。最近受到影响的是VMvare View虚拟桌面产品。

　　中断VMware View服务的补丁

　　2010年六月，VMware一位负责推广新Knowledge Base (KB)文章的专员，在Twitter上发布了一条紧急的消息： vSphere 4的Update 2 (U2) 会破坏Vmware View的PC-over-IP (PCoIP) 协议功能。

　　当我看到这条微博的时候，我已经在我的实验室完成了U2一半的安装。幸运的是，我还没有升级中断View中PCoIP协议功能的VMware Tools。

　　VMware起初发布了一条新的KB，告诉用户避免使用U2升级。在解决了那些已经安装了U2的用户的问题后，这片KB文章也相应作了修改。

　　为了修补U2补丁，VMware用旧版本替换了引发问题的VMware Super Video Graphics Array驱动。管理员必须对每个虚拟桌面，模板，以及VMware Composer中Linked Clone特性使用的母镜像进行修复。

　　另一例VMware补丁的崩溃

　　可悲的是，类似的情形以前也曾发生过。当VMware Update 1 (U1)发布的时候，我是最早下载和升级自己VMware环境的用户之一。

　　但是U1升级和HP服务器中的Hewlett-Packard (HP) Management Agent存在兼容问题。结果是U1在HP服务器上引发了极少出现的Purple Screen of Death (PSOD) 紫屏关键错误。

　　PSOD紫屏通常是由诸如内存故障这类Hypervisor所无法控制的故障而引起的。（作为一个悲伤的小Geek，我在我的RTFM blog收集PSOD。我不经常出门，总得找点事情打发时间。）

　　VMware补丁以及质量控制：展望

　　我们如何对待这些VUM的恶作剧？通常的反应是，立刻安装VMware补丁是一种愚蠢的行为。在部署任何厂商的任何主要更新前，聪明和有经验的管理员都会三思而后行。

　　但是这建议对那些已经下载安装了问题补丁的客户们于事无补。另一方面，当你向一个软件厂商提交技术支持请求的时候，他们通常第一件事就是问你是否已经安装了最新的版本。如果没有，他们不会提供进一步的支持，直到你完成更新。

　　我之所以安装U2是因为新的VMware View 4.5 beta。具有讽刺意味的是，U2并没有影响VMware View 4.5 Beta 2中的PCoIP协议功能。

　　是的，beta版的产品是兼容的，可正式版却不是。

　　我担心VMware的质量保证已经有一段时间了。我第一次对产生这些关注是在2007年北卡夏洛特的用户峰会。当VI3还是个不成熟的系统的时候，我注意到一条“Object Reference not set to an instance of an object”的错误信息按小时出现。

　　我担心的是，VMware以一个如此快速的步伐成长，在公布一系列眼花缭乱的新功能的同时，它的质量控制会下滑。目前，在产品的可靠性上，VMware享有几乎和苹果公司一样的声誉。我厌恨这种因为补丁的质量控制而破坏的感觉。这只会给VMware的竞争者们以打击它把柄。

　　值得一提的是，vSphere 4和最早被广泛采用的VMware虚拟化平台VI2是有很大不同的。在早期，VMware严格控制它的hypervisor。那时还发布仅作小幅修正的Maintenance Release版本。针对一份谨慎确立的服务器制造商和型号的名单，VMware确保对其硬件的稳定性和可靠性。

　　随着vSphere4的发布带来了重大变化。现在的ESX对其它厂商更加友好。很多公司可以通过他们自己的产品在hypervisor中添加功能。

　　除了EMC PowerPath, Xsigo以及Cisco Nexus 1000V VEM, 一些公司实际上为ESX编写特定的代码。

　　最终，VMware会中止ESX并只提供ESXi。但是VMware需要改变他们内部的QA流程，以及VUM的工作方式。如果VMware采用类似于Microsoft Windows Update的方式，我不会表示惊讶。这种模式中，用户可以从VMware的网站下载第三方的插件。这样第三方的工程师将提供兼容性测试，而不是仅仅依靠VMware的工程师们。如果采用这种方式，客户们也许就可以避免之前由于VMware的补丁而面对的HP和Cisco设备的问题。

　　VMware也许会改变它的路线图，以使得它的工程师团队能够排除同时开发新本版的压力，找出并修复当前的bug。与此同时，对于当前的产品，我也不会惊讶于看到VMware做出一个关于补丁QA的更大的承诺。如果VMware能够迅速完善这个补丁质量的问题，那将会是个美好的一天。