由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，都成功了！
至此，問題解決！
總結
以上是生活随笔為你收集整理的由CloudStack项目引起的ESXI嵌套虚拟化引起的二级虚拟机无法被访问的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 判断质数5个程序
- 下一篇： 揭秘马云帝国内幕：马云的野心有多大