Neutron中的网络I/O虚拟化

为了提升网络I/O性能。虚拟化的网络I/O模型也在不断的演化：

１，全虚拟化网卡(emulation）。如VMware中的E1000用来仿真intel 82545千兆网卡，它的功能更完备，如相比一些半虚拟化的网卡（如vmnet3）会对vlan的支持更好(这点可參见我的还有一篇博客《Vmware中的虚拟网络》一文:http://blog.csdn.net/quqi99/article/details/8727130）。纯软件模拟不须要硬件支持，通过CPU计算来模拟。跟宿主机的物理网卡隔离，没有平台要求。对虚拟机的操作系统也不须要改动（由于模拟的都是一个常见的硬件网卡，如IntelE1000,主流操作系统一般都自带这些驱动。因此默认情下虚拟机不须要再安装驱动。

缺点就是性能差了。



２，半虚拟化网卡，如上面提到的VMware中的vnet3，以及KVM中的virtio等。在半虚拟化模型中，物理硬件资源是统一由Hypervisor来管理的，这样虚拟机和Hypervisor之间通信有可能直接接触到硬件。因此性能相对较高。缺点就是须要改动虚拟机操作系统须要安装这些半虚拟化网卡的驱动程序。



３，Pass-through直通方式，Hypervisor直接把硬件PCI设备分配给虚拟独占使用，性能当然好啦。可是浪费硬件设备，且配置复杂，首先须要在hypervisor指定通过PCIid方式分配给指定的虚拟机，然后虚拟机再识别到设备再安装驱动来使用。OpenStack中怎样使用它可參见：https://wiki.openstack.org/wiki/Pci_passthrough



４。SR-IOV（Single Root I/O Virtualization and Sharing Specification），用来解决虚拟最后一公里的问题，即多个虚机能够同一时候共享使用同一个PCI硬件。

它须要专门支持SR-IOV的硬件网卡，它会在Hypervisor里注冊成多个网卡（每一个网卡都有独立的中断，收发队列。QoS等机制）,将虚拟网卡中的数据分类功能挪到了硬件SR-IOV网卡中实现。

 









linux传统tap + bridge(VEB, Virtual Ethernet Bridge)实现网络虚拟化技术有一个重要特点, 就是使用server的CPU来通过软件模拟网络, 而硬件厂商出于某些目的希望将由软件实现的网络虚拟化改为由硬件来实现网络虚拟化.于是, 针对云计算中的复杂网络问题,
业办提出了两种扩展技术标准:802.1Qbh和802.1Qbg:

1, 802.1Qbh Bridge Port Extension主要由Vmware和Cisco提出, 尝试从接入层到汇聚层提供一个完整的虚拟化网络解决方式, 尽可能达到软件定义一个可控网络的目的, 它扩展了传统的网络协议, 因此须要新的网络硬件设备, 成本较高.

2, 802.1Qbg Edge Virtual Bridging(EVB)主要由HP等公司联合提交, 尝试以较低成本利用现有设备改进软件模型的网络. 802.1Qbg的一个核心概念是VEPA(Virtual Ethernet Port Aggregator), 简单来说它通过port汇聚和数据分类转发,
把Host上原来由CPU和软件做的网络处理工作通过发卡模式转移到一级硬件交换机上, 减小Host CPU负载,同一时候使在一级交换机上做虚拟机的流量监控成为可能, 也更加清晰地切割Host与网络设备的势力范围, 方便系统管理. EVB又分两种:

1, Tag-less VEPA, 用MAC-VID来导流,  即VEPA模式, 不管host内部的流量还是出外部的流量统统经发卡模式再到外部交换机转发

2, VN-Tagged, 用全新的Tag来导流, 如VEPA一样也须要对物理交换机做定制。核心思想是在标准以太网帧中为虚机定制添加一段专用的标记VN-Tag，用以区分不同的vif。从而识别特定的虚机的流量。





Linux Host側的扩展技术

macvtap(SRIOV用于将硬件网卡虚机非常多中断号不同的独立的虚拟网卡给虚机用, macvtap的bridge模式更像是取代了tap设备与bridge设备的组合给虚机直接用的), linux引入的新的网络设备模型, 和tap设备一样, 每个macvtap设备拥有一个相应的linux字符设置,
并拥有和tap设备一样的IOCTL接口, 因此能直接被qemu使用.引入它的目的是: 简化虚拟环境中的交换网络, 取代传统的tap设备加bridge设备组合, 同一时候支持新的虚拟化网络技术, 如802.1 Qbg.

macvtap和vlan设备一样是以一对多的母子关系出现的(ip link add link eth1 name macvtap0 type macvtap, 会生成名Ϊmacvtap0@eth1的macvtap接口),
可无限嵌套子设备再做母设备创建macvtap子设备, 母设备与子设备被隐含桥接起来, 母设备相当于交换机的TRUNK品, 实际上当 MACVTAP 设备被创建而且模式不为 Passthrough时。内核隐含的创建了MACVLAN网络(如:ip link add link eth1 name eth1.10 type vlan id 10)，完毕转发功能。MACVTAP 设备有四种工作模式：Bridge、VEPA、Private，Passthrough:



1, Bridge, 完毕与 Bridge 设备类似功能，数据能够在属于同一个母设备的子设备间交换转发. 当前的Linux实现有一个缺陷。此模式下MACVTAP子设备无法和Linux Host通讯，即虚拟机无法和Host通讯，而使用传统的Bridge设备，通过给Bridge设置IP能够完毕。但使用VEPA模式能够去除这一限制.
macvtap的这样的bridge模式等同于传统的tap+bridge的模式.

2, VEPA, 式是对802.1Qbg标准中的VEPA机制的部分软件实现，工作在此模式下的MACVTAP设备简单的将数据转发到母设备中，完毕数据汇聚功能，通常须要外部交换机支持Hairpin模式才干正常工作。

3, Private, Private模式和VEPA模式类似。差别是子 MACVTAP之间相互隔离。

3, Passthrough, 能够配合直接使用SRIOV网卡, 内核的MACVLAN数据处理逻辑被跳过，硬件决定数据怎样处理，从而释放了Host CPU资源。MACVTAP Passthrough 概念与PCI Passthrough概念不同。PCI Passthrough针对的是随意PCI设备，不一定是网络设备。目的是让Guest
OS直接使用Host上的 PCI 硬件以提高效率。MACVTAP Passthrough只针对 MACVTAP网络设备，目的是饶过内核里MACVTAP的部分软件处理过程，转而交给硬件处理。综上所述。对于一个 SRIOV 网络设备，能够用两种模式使用它：MACVTAP Passthrough 与 PCI Passthrough



所以使用网络虚拟化具有三个层次:

1, 用户能够零成本地使用 Linux 软件实现的 Bridge、VLAN、MACVTAP设备定制与现实世界类似的虚拟网络;

2, 也能够用很低的成本依照802.1Qbg中的VEPA模型创建升级版的虚拟网络，引出虚拟机网络流量。降低Hostserver负载;

3, 当有支持 SRIOV 的网卡存在时，能够使用 Passthrough 技术近一步降低Host负载





KVM中使用Pass-through的过程例如以下：

http://www.linux-kvm.org/page/Ho
... es_with_VT-d_in_KVM

1，cpu要支持VT-d或AMD I/O Virtualization Technology

2, linux kernel要支持：

1. set "Bus options (PCI etc.)" -> "Support for DMA Remapping Devices" to "*"
2. set "Bus options (PCI etc.)" -> "Enable DMA Remapping Devices" to "*"
3. set "Bus options (PCI etc.)" -> "PCI Stub driver" to "*"
4. optional setting:
5. set "Bus options (PCI etc.)" -> "Support for Interrupt Remapping" to "*"

复制代码

3,　上述两步准备好后重新启动机器验证是否支持：　dmesg | grep -e DMAR -e IOMMU

4,  unbind device from host kernel driver (example PCI device 01:00.0)

1. Load the PCI Stub Driver if it is compiled as a module
2. modprobe pci_stub
3. lspci -n
4. locate the entry for device 01:00.0 and note down the vendor & device ID 8086:10b9
5. ...
6. 01:00.0 0200: 8086:10b9 (rev 06)
7. ...
8. echo "8086 10b9" > /sys/bus/pci/drivers/pci-stub/new_id
9. echo 0000:01:00.0 > /sys/bus/pci/devices/0000:01:00.0/driver/unbind
10. echo 0000:01:00.0 > /sys/bus/pci/drivers/pci-stub/bind

复制代码

5, assign device:

1. qemu-system-x86_64 -m 512 -boot c -net none -hda /root/ia32e_rhel5u1.img -device pci-assign,host=01:00.0

复制代码

OpenStack中使用的Pass-through过程例如以下：

https://wiki.openstack.org/wiki/Pci_passthrough

１，计算节点中定义虚机中可用的pci设备

1. 　pci_passthrough_whitelist=[{ "vendor_id":"8086","product_id":"1520"}]

复制代码

２。控制节点中定义别名：

1. pci_alias={"vendor_id":"8086", "product_id":"1520", "name":"a1"}

复制代码

3, 启动pci devices filter

1. scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
2. scheduler_available_filters=nova.scheduler.filters.all_filters
3. scheduler_available_filters=nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter
4. scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter

复制代码

4, 依据别名定义flavor，a1:2中的2是指要求两块pci设备:

1. nova flavor-key  m1.large set "pci_passthrough:alias"="a1:2"

复制代码

5, 依据flavor启动虚机：

1. 　nova boot --image new1 --key_name test --flavor m1.large 123

复制代码

KVM中使用SR-IOV配置可參见：http://hj192837.blog.51cto.com/655995/1061407/,
对于硬件支持SR-IOV的网卡，在启动igb模块后（modprobe /etc/modprobe.d/igb.conf igb max_vfs=7）就能用lspci命令看到这块物理网卡已经被注冊成了多个SR-IOV网卡。使用virsh　nodedev-dupxml命令查看这些SR-IOV的详细信息格式例如以下：

1. virsh nodedev-dumpxml pci_0000_0b_00_0
2. <device>
3. <name>pci_0000_0b_00_0</name>
4. <parent>pci_0000_00_01_0</parent>
5. <driver>
6. <name>igb</name>
7. </driver>
8. <capability type='pci'>
9. <domain>0</domain>
10. <bus>11</bus>
11. <slot>0</slot>
12. <function>0</function>
13. <product id='0x10c9'>Intel Corporation</product>
14. <vendor id='0x8086'>82576 Gigabit Network Connection</vendor>
15. </capability>
16. </device>

复制代码

使用“virsh nodedev-dettach pci_0000_0b_10_0”命令能够将一块SR-IOV网卡的虚拟功能从host分离，从而使虚机能够通过例如以下格式用到它的虚拟功能。

1. <hostdev mode='subsystem' type='pci' managed='yes'>
2. <source>
3. <address bus='0x0b' slot='0x10' function='0x01'/>
4. </source>
5. </hostdev>

复制代码

OpenStack是怎样使用并实现SR-IOV特性的呢？见：https://review.openstack.org/#/c/67500/

1. nova boot --flavor m1.large --image <image-uuid> --nic net-id=<net-uuid>,vnic-type=<normal|direct|macvtap> vm
2. neutron port-create <net-uuid-or-name> --binding:vnic-type <normal|direct|macvtap>
3. nova boot --flavor m1.large --image <image-uuid> --nic port-id=<port-uuid-from-above> vm

复制代码

１，port-binding用于nova和neutron之间传递数据。所以port-binding要添加vnic-type參数。见：https://review.openstack.org/#/c/72334/

　　最后它也要挪到能存储随意key-val的binding:profile字典中去，见：https://blueprints.launchpad.net
... ml2-binding-profile

   Replace binding:capabilities with binding:vif_details, https://review.openstack.org/#/c/72452/



２。Implements ML2 mechanism driver for SR-IOV capable NIC based switching, https://review.openstack.org/#/c/74464/



使用了SR-IOV后，就是由硬件桥（Hardware-based Virtual Ethernet Bridging, HW VEB)来通过direct和macvtap方式提供port (VF).

1, Nova端通过pci_passthrough_whitelist将VFs关联到physical_network来支持对sr-iov port的调度.

1. pci_passthrough_whitelist = {"address":"*:0a:00.*","physical_network":"physnet1"}

复制代码

2, Neutron端

   Neutron sriovnicswitch ML2用来提供port binding功能向nova提供信息

   Nuetron sriovnicswitch agent当SR-IOV硬件支持VF link state更新时能够用来处理port更新事件

   a、cat /etc/neutron/plugins/ml2/ml2_conf.ini

1. [securitygroup]
2. firewall_driver = neutron.agent.firewall.NoopFirewallDriver
3. [ml2]
4. tenant_network_types = vlan
5. type_drivers = vlan
6. mechanism_drivers = openvswitch,sriovnicswitch
7. [ml2_type_vlan]
8. network_vlan_ranges = physnet1:2:100

复制代码

b、cat /etc/neutron/plugins/ml2/ml2_conf_sriov.ini

1. [ml2_sriov]
2. agent_required = True
3. [sriov_nic]
4. physical_device_mappings = physnet1:eth1
5. # eth1:0000:07:00.2; 0000:07:00.3, eth2:0000:05:00.1; 0000:05:00.2
6. neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/plugins/ml2/ml2_conf_sriov.ini

复制代码

演化的根本思想是：虚机  --  虚机网卡（tap)  -- 虚拟化层（用户空间） -- 内核网桥 --  物理网卡。

1, virtio技术通过同一时候改动物理机操作系统与虚拟化软件从而不须要再模拟完整的虚机网卡，从而绕开一层，提升性能。

2, vhost_net使虚拟机的网络通讯直接绕过用户空间的虚拟化层，直接能够和内核通讯，从而提供虚拟机的网络性能

3, macvtap则是绕过内核网桥





        传统的neutron实际技术是tap + linux bridge + veth，然后通过iptables或ovs流表来实际anti-spoofing与security-group的支持.

Snabb NFV switch的思想是将能将硬件做的事尽量由硬件网卡来做， 如iptables/ebtables/ovs/bridge这些事。

在openstack中执行Snabb须要两个插件：

1, ML2 Snabb Mechanism Driver, 

2, Snabb Switch, 执行在每一个计算节点上。类似于ovs, 可是它集成了neturon snabb l2 agent的功能, 它在软件和硬件SR-IOV之上提供数据平面，软件提供virtio-net抽象，security group过滤，带宽控制。ethernet-over-ip遂道。SR-IOV硬件则提供zero-copy
DMA加速功能, 见：https://github.com/SnabbCo/snabb
... bb-switch-operation