由思科/EMC/VMware/英特尔四方组建的VCE联盟（点击此处查看更多VCE联盟介绍）一直遵循着非常直观的运营思路：将各类硬件与软件集中起来构建成vBlock设备（什么是vBlock?），并在对说明文档及具体细节进行深入测试之后以整体配置方案形式投放市场。没错，VCE方面在电子邮件中明确表示“我们所交付的系统已经作为整体经过严格的工程调试、测试与认证。”
VCE在技术支持方面同样实力强大，神出鬼没的系统管理员甚至能够在某套管理控制台上的某个指示灯由绿转红的一瞬间现身当场并着手解决问题。
然而这样的规划并不总能实际起效，一家VCE客户抱怨称。该客户曾购买了一套运行有VCE Release Certification Matrix 4.07版本的vBlock设备。所谓Release Certification Matrix（简称RCM）已经拥有二十年历史，是VCE集硬件、软件与说明文档于一体的捆绑型产品方案。
在vBlock捆绑方案中包含有该软件的2.2.2-17（SP2）版本以及EMC XtremIO阵列。可悲的是，这套软件中的一项漏洞让用户的vBlock饱受摧残，并直接导致“我们的整套阵列陷入瘫痪。VCE/EMC方面花了六个多小时才使其重新上线（且处于版本降级状态），而恢复全部功能又额外用掉了约八个小时。”
这家不愿透露名号的客户在Reddit网站上公布了自己的遭遇，透露出一系列具体信息并同意我们将这段经历与大家分享。
“我认为任何一家vBlock客户都拥有同样的怨言，即在RCM模式下进行代码发布时会在牺牲一定灵活性，”他们写道。“有鉴于此，VCE方面所承诺的各组件‘顺畅协作’口号无疑会在我们心中大打折扣。”
VCE迅速对此作出了回应。在与我们的沟通当中，该公司的一位发言人表示“当新的组件/代码被投放市场时，VCE会在接下来的四十五天内对支持代码进行持续更新。”而这四十五天属于断档期，RCM更新要在半年后“才有可能彻底取代vBlock发布时所配备的全部原有代码”。
不过VCE一直在努力发布并支持安全性补丁，并承诺“在漏洞曝光的一到两周之内完成更新”。
但这位用户的控诉重点并不在于这段断档期，而是对EMC的消极回应表示不满。因为对方表示“该问题目前尚未被收录入公共咨询内容当中，且无法提供预计解决时间。”
由于缺乏相关信息，就连作为合作伙伴的VCE也很难有效解决这一难题。
“我对VCE的表现非常不满，因为他们对这项漏洞似乎一无所知。EMC至少明确知晓该问题的存在，但VCE呢？一问三不知。”这位用户强调称。
“直到现在我也没能就这个问题得到确切答复。其实在使用过程中发现一些供应商也没意识到的漏洞并不是无法接受，但在沟通过程中发现对方早已知晓这种状况、却依然将其正常推出就很难让人信服了，”这位用户写道，并总结称“我希望这能让他们得到一些教训，并在未来的认证流程中进一步加强合作、避免此类问题再次发生。”
此次事件对于其它开箱即用堆栈供应商也算是很好的借鉴，希望其它更新周期较长的参考架构厂商或者用户也能引以为戒、以更加审慎的态度对待自己的vBlock配置方案。