1. Security Group全部開啟，這是最基本的，但是很多人容易忘記

其實遇到過無數這種場景了，Debug了半天網路問題，各種手段都用上了，最後發現安全組竟然沒有開啟。

2. 通過介面檢視虛擬機器的log，也可以在compute節點上檢視console.log檔案，看看裡面是否有DHCP獲取IP成功的日誌

在介面上可以看控制檯日誌

在compute節點上可以檢視

/var/lib/nova/instances/6323a941-de10-4ed3-9e2f-1b2b25e79b66/console.log

如果沒有日誌，則說明image有問題

在grub裡面

linux /boot/vmlinuz-3.2.0-49-virtual root=UUID=6d2231e4-0975-4f35-a94f-56738c1a8150 ro console=ttyS0

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0“

update-grub

3. 如果虛擬機器連不上DHCP Server，則需要準備一個不使用metadata server，而是用使用者名稱密碼可以登入的image

這種Image很好做，自己動手做一個就可以了，啟動映象後去掉cloud-init相關配置，然後設定一個預設的使用者名稱密碼。

4. 通過VNC登入

5. 如果VNC登入不進去，說明VNC配置的有問題，方法一重新配置VNC

VNC Proxy的功能：

• 將公網(public network)和私網(private network)隔離

• VNC client執行在公網上，VNCServer執行在私網上，VNC Proxy作為中間的橋樑將二者連線起來

• VNC Proxy通過token對VNC Client進行驗證

• VNC Proxy不僅僅使得私網的訪問更加安全，而且將具體的VNC Server的實現分離，可以支援不同Hypervisor的VNC Server但不影響使用者體驗

VNC Proxy的部署

• 在Controller節點上部署nova-consoleauth 程序，用於Token驗證

• 在Controller節點上部署nova-novncproxy 服務，使用者的VNC Client會直接連線這個服務

• Controller節點一般有兩張網絡卡，連線到兩個網路，一張用於外部訪問，我們稱為public network，或者API network，這張網絡卡的IP地址是外網IP，如圖中172.24.1.1，另外一張網絡卡用於openstack各個模組之間的通訊，稱為management network，一般是內網IP，如圖中10.10.10.2

• 在Compute節點上部署nova-compute，在nova.conf檔案中有下面的配置

• vnc_enabled=True

• vncserver_listen=0.0.0.0 //VNC Server的監聽地址

• vncserver_proxyclient_address=10.10.10.2 //nova vnc proxy是通過內網IP來訪問vnc server的，所以nova-compute會告知vnc proxy用這個IP來連線我。

• novncproxy_base_url=http://172.24.1.1:6080/vnc_auto.html //這個url是返回給客戶的url，因而裡面的IP是外網IP

VNC Proxy的執行過程：

1. 一個使用者試圖從瀏覽器裡面開啟連線到虛擬機器的VNC Client

2. 瀏覽器向nova-api傳送請求，要求返回訪問vnc的url

3. nova-api呼叫nova-compute的get vnc console方法，要求返回連線VNC的資訊

4. nova-compute呼叫libvirt的get vnc console函式

5. libvirt會通過解析虛擬機器執行的/etc/libvirt/qemu/instance-0000000c.xml檔案來獲得VNC Server的資訊

6. libvirt將host, port等資訊以json格式返回給nova-compute

7. nova-compute會隨機生成一個UUID作為Token

8. nova-compute將libvirt返回的資訊以及配置檔案中的資訊綜合成connect_info返回給nova-api

9. nova-api會呼叫nova-consoleauth的authorize_console函式

10. nova-consoleauth會將instance –> token, token –> connect_info的資訊cache起來

11. nova-api將connect_info中的access url資訊返回給瀏覽器：http://172.24.1.1:6080/vnc_auto.html?token=7efaee3f-eada-4731-a87c-e173cbd25e98&title=helloworld%289169fdb2-5b74-46b1-9803-60d2926bd97c%29

12. 瀏覽器會試圖開啟這個連結

13. 這個連結會將請求傳送給nova-novncproxy

14. nova-novncproxy呼叫nova-consoleauth的check_token函式

15. nova-consoleauth驗證了這個token，將這個instance對應的connect_info返回給nova-novncproxy

16. nova-novncproxy通過connect_info中的host, port等資訊，連線compute節點上的VNC Server，從而開始了proxy的工作

6. 如果VNC登入不進去，還有一個方法，使用自己的VNC Client，通過compute物理節點的IP地址登陸

qemu-system-x86_64 有引數 -vnc 0.0.0.0:5

就可以通過compute node的ip地址進入

7. 通過ovs-vsctl show和brctl來檢視，各個網絡卡和bridge之間關係是否正確，tunnel之間是否能夠通，網絡卡是否都處於up的狀態

8. 如果從虛擬機器的虛擬網絡卡到DHCP Server的網絡卡一路都是配置正確的，則需要檢視br-tun上ovs-ofctl dumpflows檢視flows規則，是否對包的改寫正確，是否有正確的規則

9. 通過VNC登入進去後，就可以通過命令列執行dhclient，來重啟連線DHCP Server, 從compute節點上的網絡卡和bridge，一個個進行tcpdump，看到底哪個網絡卡或者bridge沒有收到包，收到的包裡面的VLAN ID等是否正確

10. 如果VM能從DHCP Server獲得IP，則好事成了一半，接下來換一個有cloud-init的image，看metadata server能夠連線成功，能夠注入key，也是通過console.log來看

11. 如果metadata server不能連線成功，就需要順著metadata server的整個流程，一個一個模組看，看每個模組的log，埠是否正確，是否收到請求，也可以在VM裡面用curl來模擬metadata server的請求

openstack裡的metadata，是提供一個機制給使用者，可以設定每一個instance 的引數。比如你想給instance設定某個屬性，比如主機名。

Instance訪問metadata server http://169.254.169.254

metadata的一個重要應用，是設定每個instance的ssh公鑰。

獲取metadata的api介面是：

http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key 

這個IP地址，在 openstack 是不存在的。為什麼可以獲取到metadata呢？

這是由於Amazon的原因，最早metadata是亞馬遜提出來的，參見：http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html

後來很多人給亞馬遜定製了一些作業系統的映象，比如 ubuntu, fedora, centos 等等，而且將裡面獲取 metadta 的api地址也寫死了。所以opentack為了相容，保留了這個地址169.254.169.254。

然後通過iptables nat對映到真實的api上：

iptables -A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 16.158.166.197:8775 

nova如何區分到底是哪個虛擬機器請求metadata？採取的方法是在HTTP頭部識別是哪個虛擬機器。

一個虛擬機器訪問169.254.169.254的流程如下：

(1) 虛擬機發出請求

• 虛擬機器啟動時會訪問169.254.169.254

• 資料包會直接傳送到虛擬機器的預設閘道器172.71.71.1

• 預設閘道器在network node上，qr-XXXXX

(2) namespace中的iptables

• 因為使用了namespace，在network node上每個namespace裡都會有相應的iptables規則和網路裝置。

• iptables規則中，會把目的地址169.254.169.254的資料包，重定向到本地埠9697

ip netns exec qrouter-5a74908c-712c-485c-aa9f-6c1e8b57e3e1 iptables -t nat -nvL

(3) namespace-metadata-proxy

啟用namespace場景下，對於每一個router，都會建立這樣一個程序。該程序監聽9697埠，其主要功能：

1、向請求頭部新增X-Forwarded-For和X-Neutron-Router-ID，分別表示虛擬機器的fixedIP和router的ID

2、將請求代理至Unix domain socket（/var/lib/neutron/metadata_proxy）

(4) Neutron-metadata-agent

• network node上的metadata agent監聽/var/lib/neutron/metadata_proxy：

• 該程序的功能是，根據請求頭部的X-Forwarded-For和X-Neutron-Router-ID引數，向Neutron service查詢虛擬機器ID，然後向Nova Metadata服務傳送請求（預設埠8775），訊息頭：X-Forwarded-For，X-Instance-ID、X-Instance- ID-Signature分別表示虛擬機器的fixedIP，虛擬機器ID和虛擬機器ID的簽名。

12. 如果metadata server能夠連線成功，key成功注入，下一步需要從namespace裡面看是否能夠ping通，能夠ssh

13. 如果namespace裡面能夠成功，則在network節點上，ping floating ip和ssh，是否能夠成功，如果不成功，看br-ex的網絡卡是否新增正確，是否配置了ip，路由表是否正確，namespace裡面floating ip的iptables規則是否新增正確

14. 在network節點上能夠ssh到floating ip，則需要從其他節點上ssh，如果不成功，可能br-ex的網址配置有問題，很可能是br-ex新增的物理網絡卡不是混合狀態，也可能是路由配置有問題，對於floating ip所在的網段，不指向network節點

15. 如果floating ip能夠成功，則需要進去VM裡面執行apt-get update，如果不可以，看能否ping通openstack裡面的gateway(10.0.0.1)，然後看能否ping通物理網路環境的gateway(16.158.XXX.1)

16. 看DNS Server是否配置正確，是否能夠ping通，如果能，apt-get update執行成功

歡迎關注微信公眾號