關於這個問題，主要以文字描述爲主，最終解決方法其實就一個步驟。
問題描述：
某客戶需要部署某企業的雲平臺，但是由於年前沒有足夠的物理機資源，所以提供的資源均爲虛擬機，現在讓我們做技術評估。
其實觀察整個環境，沒有什麼好做技術評估的，平時一般情況下面，除了主機我們使用物理機外，其他的所有服務都沒有必要使用物理機資源，所以現在只要驗證虛擬機中創建虛擬機是否可以成功即可。關於我們使用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，都成功了！
至此，問題解決！