4月25日，VMwareCloudFoundry云服务因存储柜的电供应导致停机，虽然应用仍然在线，但是开发者已经不能进行最基本的操作，例如登录和创建新应用的操作。该中断事故持续了将近10个小时后，服务恢复。
　　
　　但是，就在CloudFoundry云服务中断恢复的第二天，VMware一官员进行检测以防止第一天的事故再发生，却意外导致了第二次的云服务的中断。
　　
　　VMware官员DekelTankel解释道，“4月25日的中断是偶尔会发生的”，并表示VMwareVMware已经确保其软件，监控系统和运作模式的性能，使其足以防止客户系统的停电脱机。
　　
　　有了这样的思路，VMware在第二天就开始开发“一个完整的业务脚本来进行早期的检测、预防和恢复”。
　　
　　“4月26号上午8点，这个脚本拉开帷幕，中午整个工程团队进行审查，但都还只是纸上谈兵还未落实到实处，待到脚本的审查才可进行实践。不幸的是，上午10:15分，一位运营工程师开始了实战，直接导致了CloudFoundry云服务的整个网络基础设施的中断，这个举动摧毁了所有负载平衡器、路由器和防火墙，导致VMware内部部分DNS基础设施停止工作，最终导致CloudFoundry与外部链接的中断。”
　　
　　可以看出第二次中断的影响比第一天的中断更为严重。
　　
　　“这是我们第一次整体中断，这个事件需要我们为此建造一个维护页面，”Tankel表示，“这次的中断，所有应用和系统部件继续运行，然而网络前台中断，我们是唯一知道系统启动的。直到上午11:30，网络前台才全面运行。”
　　
　　VMware第二天的云服务中断是由于人为操作导致了云服务的中断，与亚马逊云服务中断的根源分析很类似。在亚马逊的案例中，是由于系统升级过程中的错误导致了好几天的云服务中断。
　　
　　VMware主要是以其服务器虚拟化技术著称，在提供共有的云计算服务领域可谓是一个新手。在此之前，VMware也曾向用户粗手技术和服务来帮助他们建立自己的云计算。
　　
　　有云CloudFoundry对于用户来说比较新，所以其影响远不及亚马逊产生的影响，因为亚马逊云服务的中断，导致众多依赖亚马逊服务的知名网站中断服务。但是这次的中断事件也让VMware尝到了服务提供商的艰辛，毕竟这么诱人的果实不是什么人都可以吃得到的。