上一节创建了 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 的连通性。
将 instance 部署到 OVS Local Network - 每天5分钟玩转 OpenStack（130）
原文地址：http://cloudman.blog.51cto.com/10425448/1886080
