當發現你的OpenStack虛擬機網絡有問題，不妨先試一下這16個步驟

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運行成功

 

歡迎關注微信公眾號