关于这个问题，主要以文字描述为主，最终解决方法其实就一个步骤。
问题描述：
某客户需要部署某企业的云平台，但是由于年前没有足够的物理机资源，所以提供的资源均为虚拟机，现在让我们做技术评估。
其实观察整个环境，没有什么好做技术评估的，平时一般情况下面，除了主机我们使用物理机外，其他的所有服务都没有必要使用物理机资源，所以现在只要验证虚拟机中创建虚拟机是否可以成功即可。关于我们使用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，都成功了！
至此，问题解决！
