由CloudStack项目引起的ESXI嵌套虚拟化引起的二级虚拟机无法被访问

   关于这个问题，主要以文字描述为主，最终解决方法其实就一个步骤。

   问题描述：

  某客户需要部署某企业的云平台，但是由于年前没有足够的物理机资源，所以提供的资源均为虚拟机，现在让我们做技术评估。

  其实观察整个环境，没有什么好做技术评估的，平时一般情况下面，除了主机我们使用物理机外，其他的所有服务都没有必要使用物理机资源，所以现在只要验证虚拟机中创建虚拟机是否可以成功即可。关于我们使用VMWare Workstation ，实现嵌套虚拟化没有一点问题，相应的配置可以参考博主这篇文章：在VMWare Workstation 9 实现嵌套虚拟化设置【虚拟机再虚拟化】

http://clovemfong.blog.51cto.com/3297559/1198184

   那么现在客户的用的是ESXI5.0，给我们使用的虚拟机自然也是从ESXI5.0主机上面划出来的，于是乎，本人就在内部进行了测试。大部分步骤都是一样的，仅仅把新建的虚拟机CPU配置支持虚拟化。

按照相同的步骤创建好ESXI或者KVM虚拟机，叫做也成功通过CloudStack管理节点将其进行纳管，启动Zone,最后发现两个系统VM全部启动成功，也显示Running状态，但是，问题出现了，两个系统VM只能在KVM虚拟机上面ping通，登录两个系统VM，也不能访问网关，只能访问虚拟化过的ESXI跟KVM系统。

几个系统的关系是：

物理机    --- ESXI5.0   IP: 192.168.153.6  Netmask: 255.255.255.0  Gateway: 192.168.153.1

一级虚拟机：---ESXI5.0  IP: 192.168.153.40 Netmask: 255.255.255.0  Gateway: 192.168.153.1

二级虚拟机：---linux    IP:192.168.153.107 Netmask: 255.255.255.0  Gateway: 192.168.153.1

状态：

IP为192.168.153.40跟192.168.153.6可以正常互通。

IP为192.168.153.107跟192.168.153.40可以正常互通，但是跟192.168.153.6无法互通，也无法ping通网关192.168.153.1。

问题分析：

这个问题一开始真的无从下手。

1. 防火墙的原因？

通过 VSphere Client登录VCenter 检测防火墙，发现没有作严格的防火墙策略限制。

2. 难道是因为两个二级虚拟机【两个系统VM】是由CloudStack调用接口创建的？所以才会产生这样的问题？

验证： 手动通过vsphere client 连接ESXI或者VCenter创建虚拟机，选择同样的网卡，然后配置好IP地址，结果发现结果是一样的， 所以排除了CloudStack引起的问题。

但是在本人机器上面通过VMWare Workstation创建一个虚拟机作为Agent节点，然后纳管资源，系统创建系统VM，实例，网络访问都是没有问题的。

最终定位到是ESXI跟VMWare Workstation的网络配置不同，VMWare Workstation用的是桥接模式，而ESXI上面的网络模式是没有选择的，应该默认也是桥接模式，也排除了网卡连接模式的问题，那最后定位到ESXI跟VMWare Workstation网卡配置的其他不同上面，最终点击ESXI主机网卡VM Network的编辑按钮，点击安全标签，发现有几个策略异常选项：

混杂模式

MAC地址更改

伪传

本人对网络不是非常精通，于是搜索了下”混杂模式“的含义，度娘说：是指一台机器能够接收所有经过它的数据流，而不论其目的地址是否是他。

看解释好像有点像哦，如果默认设置为拒绝的话，那么也就是：是指一台机器不能够接收所有经过它的数据流，而不论其目的地址是否是他。把这个混杂模式设置为接受？

然后再次登录两个系统VM，Ping网关，ping物理主机，OK了！通过其他子网里面其他IP地址的系统Ping这两台系统VM，都成功了！

至此，问题解决！