正文
不支持。
分布式电源管理（DPM）
DPM提供了通过动态调整群集容量来匹配虚拟机资源需求，以达到节省电力的目的，DPM自动整合虚拟机到较少的ESXi主机上，并对一定周期内资源利用率低的多于ESXi主机执行断电，如果资源需求增加，ESXi主机重新通电回到群集，虚拟机重新分配到群集内所有可用的ESXI主机上。
不支持。
HA
持续监控资源池中的所有物理服务器，并重启受服务器故障影响的虚拟机。还可以监控和检测虚拟机的“客户操作系统”故障，并在用户指定的间隔后自动启动虚拟机
不支持。
FT
通过创建和维护等同于主虚拟机并可在发生故障切换时替换主虚拟机的辅助虚拟机来为虚拟机提供连续可用性
不支持。
vShield
VMware 安全虚拟设备套件
Neutron 的安全组和防火墙实现了 vShield 的部分功能
vDS（分布式虚拟交换机）
让用户可以从一个集中界面为整个数据中心设置虚拟机访问交换，从而简化虚拟机网络连接。
Neutron 利用 OVS 实现了部分功能
Storage API
Cinder
SRM
站点灾难恢复
有Freezer 项目，但尚不足以进入生产环境。
从上表可以看出，
大部分的vSphere 的功能OpenStack都没有实现，或者只实现了一点。那结果只能是，OpenStack 不具备对 VMware 的替代能力，也就无法驱动用户去放弃VMware 转向 OpenStack了。
大帐篷模式的问题到底在哪？
2015年，OpenStack 社区开始使用『大帐篷』模式。该模式把OpenStack项目分成两大类：核心项目和非核心项目。核心项目只有六个，其余都是非核心项目。
根据个人理解，我简单地对这个图的一些问题做下说明：
-
六个核心服务发展得确实不错，但是问题依然不少。
一方面，如下面2017年4月的用户调查结果，前几个核心项目的使用率都超过了90%。另一方面，用户对核心项目的吐槽一直没停止过，每年的用户调查报告中都有好几页记录着用户的槽点。
-
不管是对比VMware 还是对比AWS，OpenStack核心服务的范围都太小了，导致它缺乏了一些必要的功能。我认为至少以下几个服务需要进入核心服务列表：
-
编排服务Heat：编排服务是云的基础性服务之一。一来用户可以通过编排服务自行创建和销毁云资源，二来很多二级服务可以通过提供编排模版的方式来提供给用户，三来可以与第三方云管平台和工具对接，从而培育其生态。
-
监控服务Ceilometer：一个云生产环境离不开一个强壮的监控服务。到目前为止，Ceilometer 项目都还问题重重，比如规模性问题、性能问题、功能覆盖问题等。
-
裸机服务 Ironic：裸机在私有云中有很多的应用场景，比如运行数据库、大数据平台、容器平台等。如果OpenStack把Ironic做好了，那这就会成为与VMware相比的一大优势，同时还能成为一些需要利用裸机的应用的支撑平台。现在的Ironic项目，实在太重太复杂，与物理网络设备关联太深。但是，如果可以像LINUX的kickstart和cobbler一样，就灵活轻量多了，这个过程比如像vmware里物理机可以批量部署ESXI，然后把ESXI纳管进来，就可以使用VC里的所有服务，这样的过程就比较合理了。
-
日志服务：同监控服务一样，日志服务也是云平台的一个基础性服务，如同AWS 的CloudWatch和所有项目都打通了一样。遗憾的是，到现在为止，OpenStack都没有一个原生的日志服务项目。
