Neutron中的网络I/O虚拟化

network

为了提升网络I/O性能，虚拟化的网络I/O模型也在不断的演化：
１，全虚拟化网卡(emulation），如VMware中的E1000用来仿真intel 82545千兆网卡，它的功能更完备，如相比一些半虚拟化的网卡（如vmnet3）会对vlan的支持更好(这点可参见作者的另一篇博客《Vmware中的虚拟网络》一文）。纯软件模拟不需要硬件支持，通过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网卡中实现。参考：英特尔SR-IOV实现PCI硬件资源共享
linux传统tap + bridge(VEB, Virtual Ethernet Bridge)实现网络虚拟化技术有一个重要特点, 就是使用服务器的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), 简单来说它通过端口汇聚和数据分类转发, 把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之间相互隔离。
4, 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模型创建升级版的虚拟网络，引出虚拟机网络流量，减少Host服务器负载;
3, 当有支持 SRIOV 的网卡存在时，可以使用 Passthrough 技术近一步减少Host负载
KVM中使用Pass-through的步骤如下：
http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM
1，cpu要支持VT-d或AMD I/O Virtualization Technology
2, linux kernel要支持：set "Bus options (PCI etc.)" -> "Support for DMA Remapping Devices" to "*"set "Bus options (PCI etc.)" -> "Enable DMA Remapping Devices" to "*"set "Bus options (PCI etc.)" -> "PCI Stub driver" to "*"optional setting: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)Load the PCI Stub Driver if it is compiled as a modulemodprobe pci_stublspci -nlocate the entry for device 01:00.0 and note down the vendor & device ID 8086:10b9...01:00.0 0200: 8086:10b9 (rev 06)...echo "8086 10b9" > /sys/bus/pci/drivers/pci-stub/new_idecho 0000:01:00.0 > /sys/bus/pci/devices/0000:01:00.0/driver/unbindecho 0000:01:00.0 > /sys/bus/pci/drivers/pci-stub/bind
5, assign device: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设备pci_passthrough_whitelist=[{ "vendor_id":"8086","product_id":"1520"}]
２，控制节点中定义别名：pci_alias={"vendor_id":"8086", "product_id":"1520", "name":"a1"}3, 启动pci devices filterscheduler_driver=nova.scheduler.filter_scheduler.FilterSchedulerscheduler_available_filters=nova.scheduler.filters.all_filtersscheduler_available_filters=nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilterscheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter
4, 根据别名定义flavor，a1:2中的2是指要求两块pci设备:nova flavor-key m1.large set "pci_passthrough:alias"="a1:2"
5, 根据flavor启动虚机：nova boot --image new1 --key_name test --flavor m1.large 123
KVM中使用SR-IOV配置可参见：Red Hat KVM SR-IOV 配置, 对于硬件支持SR-IOV的网卡，在启动igb模块后（modprobe /etc/modprobe.d/igb.conf igb max_vfs=7）就能用lspci命令看到这块物理网卡已经被注册成了多个SR-IOV网卡，使用virsh　nodedev-dupxml命令查看这些SR-IOV的具体信息格式如下：virsh nodedev-dumpxml pci_0000_0b_00_0<device><name>pci_0000_0b_00_0</name><parent>pci_0000_00_01_0</parent><driver><name>igb</name></driver><capability type='pci'><domain>0</domain><bus>11</bus><slot>0</slot><function>0</function><product id='0x10c9'>Intel Corporation</product><vendor id='0x8086'>82576 Gigabit Network Connection</vendor></capability></device>
使用“virsh nodedev-dettach pci_0000_0b_10_0”命令可以将一块SR-IOV网卡的虚拟功能从host分离，从而使虚机可以通过如下格式用到它的虚拟功能。<hostdev mode='subsystem' type='pci' managed='yes'><source><address bus='0x0b' slot='0x10' function='0x01'/></source></hostdev>
OpenStack是如何使用并实现SR-IOV特性的呢？见：https://review.openstack.org/#/c/67500/nova boot --flavor m1.large --image <image-uuid> --nic net-id=<net-uuid>,vnic-type=<normal|direct|macvtap> vmneutron port-create <net-uuid-or-name> --binding:vnic-type <normal|direct|macvtap>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/neutron/+spec/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/