我們將通過實驗詳細分析 instance 從 nova-api-metadata 獲取信息的完整過程。
環境介紹
1. 一個 all-in-one 環境（多節點類似）。
2. 已創建 neutron 網絡 test_net，DHCP 已啟動。在這個 metadata 實驗中， test_net 的 type 不重要，flat、vlan、vxlan 都可以。
3. 暫無 neutron router。
准備就緒，開始實驗。
啟動 instance
通過 cirros 鏡像部署一個 instance，命名為 c1，選擇網絡 test_net。啟動過程中，查看 instance 的啟動日志。
上面的 log 中我們看到兩個信息：
① instance 從 DHCP 拿到了 IP 17.17.17.5，這個好理解，因為我們在test_net 上開啟的 DHCP 服務。
② instance 會去訪問 http://169.254.169.254/2009-04-04/instance-id，嘗試了 20 次都失敗了。
神奇的 169.254.169.254
169.254.169.254 是個什么地址？
這是 metadata service 的 IP。
這個地址來源於 AWS，當年亞馬遜在設計公有雲的時候，為了讓 instance 能夠訪問 metadata，就將 169.254.169.254 這個特殊的 IP 作為 metadata 服務器的地址，instance 啟動時就會向 169.254.169.254 請求 metadata。OpenStack 之后也沿用了這個設計。
我們現在遇到的問題是 169.254.169.254 沒法訪問啊！cirros 的 cloud-init 顯然是沒有拿到 metadata 的，這點至少可以從 instance 的 hostname 沒有被設置為 c1 判斷出來。
前面我們在 Metadata Service 架構部分介紹了，instance 首先會將 metadata 請求發送給 DHCP agent 或者 L3_agent 管理的 neutron-ns-metadata-proxy。那目前到底是誰在管理 neutron-ns-metadata-proxy 呢？我們先在控制節點上查看一下 neutron-ns-metadata-proxy 的進程。
盡然沒有 neutron-ns-metadata-proxy 在運行！
其原因是：默認配置下，neutron-ns-metadata-proxy 是由 L3_agent 管理的（后面會討論讓 DHCP 來管理），由於當前 test_net 並沒有掛在 neutron router 上，所以沒有啟動 neutron-ns-metadata-proxy。
添加 router
要解決這個問題很簡單：創建虛擬路由器 test_router 並連接 test_net。
現在控制節點上已經能夠看到 test_router 管理的 neutron-ns-metadata-proxy 了。
重啟 instance c1，看會發生怎樣的變化。
instance 成功訪問到 169.254.169.254。從結果看，cloud-init 已經獲取到 metadata，因為 hostname 已經設置為 c1。
下一節我們詳細分析 c1 是如何拿到 metadata 的。
