將 instance 部署到 OVS Local Network - 天天5分鐘玩轉 OpenStack（130）

上一節建立了 OVS 本地網絡 first_local_net，今天咱們會部署一個 instance 到該網絡並分析網絡結構。
launch 一個 instance，選擇 first_local_net 網絡

instance 部署成功，分配的 IP 地址爲 172.16.1.3

底層網絡發生了什麼變化？

對於 instance 「cirros-vm1」，Neutron 會在 subnet 中建立一個 port，分配 IP 和 MAC 地址，並將 port 分配給 cirros-vm1。

如上圖所示，port 列表中增長了一個 port 「(fc1c6ebb-719d)」，IP 爲 172.16.1.3，點擊 port 名稱查看 MAC 信息。

咱們能夠先按照在 linux bridge driver 章節學到的知識推測一下： Open vSwitch driver 會如何將 cirros-vm1 鏈接到 first_local_net？

若是採用相似的實現方法，neutron-openvswitch-agent 會根據 port 信息建立 tap 設備 tapfc1c6ebb-71，並將其鏈接到 br-int 網橋，tapfc1c6ebb-71 就是 cirros-vm1 的虛擬網卡。

下面咱們驗證一下事實是否如此：

cirros-vm1 部署到了控制節點，經過 ovs-vsctl show 查看 bridge 的配置：

很是遺憾，在 br-int 上並無看到 tapfc1c6ebb-71，而是多了一個 qvofc1c6ebb-71。
目前咱們並不知道 qvofc1c6ebb-71 是什麼，咱們再用 brctl show 查看一下 linux bridge 的配置：

這裏咱們看到有一個新建的網橋 qbrfc1c6ebb-71，上面鏈接了兩個設備 qvbfc1c6ebb-71 和 tapfc1c6ebb-71。
從命名上看，他們都應該與 cirros-vm1 的虛擬網卡有關。

經過 virsh edit 查看 cirros-vm1 的配置：

確實 tapfc1c6ebb-71 是 cirros-vm1 的虛擬網卡。 那麼 linux bridge qbrfc1c6ebb-71 上的 qvbfc1c6ebb-71 設備與 Open vSwitch br-int 上的 qvofc1c6ebb-71 是什麼關係呢？

下面的內容稍微須要一些技巧了。 咱們用 ethtool -S 分別查看 qvbfc1c6ebb-71 和 qvofc1c6ebb-71 的 statistics。

原來 qvbfc1c6ebb-71 和 qvofc1c6ebb-71 都是 veth 設備，它們對應的另外一端 veth 設備 的 index 分別是 12 和 13。 經過 ip a 命令找到 index 12 和 13 的設備。

到這裏，相信有同窗已經看出來了：qvbfc1c6ebb-71 和 qvofc1c6ebb-71 組成了一個 veth pair。
咱們以前介紹過，veth pair 是一種成對出現的特殊網絡設備，它們象一根虛擬的網線鏈接兩個網絡設備。
這裏 qvbfc1c6ebb-71 和 qvofc1c6ebb-71 的做用就是鏈接網橋 qbrfc1c6ebb-71 和 br-int。

文字描述每每是不夠直觀的，下面咱們將前面梳理好的信息經過圖片展現出來。

由圖所示，tapfc1c6ebb-71 經過 qbrfc1c6ebb-71 間接鏈接到 br-int。

那問題來了，爲何 tapfc1c6ebb-71 不能像左邊的 DHCP 設備 tap7970bdcd-f2 那樣直接鏈接到 br-int 呢？

其緣由是： Open vSwitch 目前還不支持將 iptables 規則放在與它直接相連的 tap 設備上。

若是作不到這一點，就沒法實現 Security Group 功能。 爲了支持 Security Group，不得很少引入一個 Linux Bridge 支持 iptables。

這樣的後果就是網絡結構更復雜了，路徑上多了一個 linux bridge 和 一對 veth pair 設備。

下節咱們再部署一個 instance 到 first_local_network 並驗證兩個 instance 的連通性。