如上图,PCI 插槽都是等长的,防呆口位置靠上,大部分都是纯白色。PCIe 插槽大大小小,最小的 x1,最大的 x16,防呆口靠下。
SR-IOV(Single-Root I/O Virtualization,单根 I/O 虚拟化)是 PCI-SIG 推出的一项标准,定义了一种 PCIe 设备虚拟化技术的标准机制,是 “虚拟通道” 的一种技术实现,用于将一个 PCIe 设备虚拟成多个 PCIe 设备,每个虚拟 PCIe 设备都具有自己的 PCIe 配置空间,如同物理 PCIe 设备一样为上层软件提供服务。
SR-IOV 技术是一种基于物理硬件的虚拟化解决方案,可以提高物理 I/O 设备(常见的是网络适配器)的性能与可扩展性。SR-IOV 技术允许在虚拟机之间高效共享 PCIe 设备,由于 SR-IOV 技术是基于硬件实现的,可以使虚拟机获得与宿主机媲美的 I/O 性能。
SR-IOV 虚拟出来的通道分为两个类型:
PF(Physical Function,物理功能):管理 PCIe 设备在物理层面的通道功能,可以看作是一个完整的 PCIe 设备,包含了 SR-IOV 的功能结构,具有管理、配置 VF 的功能。
VF(Virtual Function,虚拟功能):是 PCIe 设备在虚拟层面的通道功能,即仅仅包含了 I/O 功能,VF 之间共享物理资源。VF 是一种裁剪版的 PCIe 设备,仅允许配置其自身的资源,虚拟机无法通过 VF 对 SR-IOV 网卡进行管理。所有的 VF 都是通过 PF 衍生而来,有些型号的 SR-IOV 网卡最多可以生成 256 个 VF。
简而言之,每个 VF 就像是物理网卡硬件资源的一个切片,而 PF 则是对所有物理网卡硬件资源的统筹者,包括管理众多 VF 可以协同工作。
SR-IOV 的实现依赖硬件和软件两部分,首先,SR-IOV 需要专门的网卡芯片和 BIOS 版本,其次上层 Hypervisor 还需要安装相应的驱动。这是因为,只有通过 PF 才能够直接管理物理网卡的 I/O 资源和生成 VF,而 Hypervisor 要具备区分 PF 和 VF 的能力,从而正确地对网卡进行配置。
当 Hypervisor 识别出一个 VF 后,会通过 PF 来管理和配置 VF 的 I/O 资源。对于 Hypervisor 来说,VF 如同普通的 PCIe 网卡一般,安装相应驱动后就能够直接使用。假设一台服务器上安装了一个单端口 SR-IOV 网卡,这个端口生成了 4 个 VF,则 Hypervisor 就得到了四个以太网连接。
在 SR-IOV 的基础上,通过进一步利用 Intel VT-d 或 AMD IOMMU(Input/Output Memory Management Unit)技术,可以直接在虚拟机和 VF 之间做一对一的映射(PCI-Passthought)。在这个过程中,Hypervisor 的软件交换机被完全 Bypass 掉,从而实现低延时和近线速。同 VMware 的 VM DirectPath 相比,这种方式即实现了虚拟机对 VF 硬件资源的直接访问,又无需随着虚拟机数量的增加而增加物理网卡的数量。
缺省情况下,SR-IOV 网卡的 VF 处于禁用状态,此时 PF 充当传统的 PCIe 设备。一旦启用了 VF,PF 通过寄存器创建 VF,并通过 PF 的总线、设备和功能编号(路由 ID)访问各个 VF 的 PCIe 配置空间。每个 VF 都具有一个 PCIe 内存空间,用于映射其寄存器集。VF 设备驱动程序对寄存器集进行操作以启用其功能,并且显示为实际存在的 PCIe 设备。
[root@overcloud-compute-0 ~]# virsh nodedev-list | grep pci
pci_0000_00_00_0
pci_0000_00_01_0
pci_0000_00_01_1
pci_0000_00_02_0
pci_0000_00_03_0
pci_0000_00_03_2
pci_0000_00_05_0
pci_0000_00_05_2
pci_0000_00_05_4
pci_0000_00_11_0
pci_0000_00_16_0
...
[root@overcloud-compute-0 ~]# virsh nodedev-dumpxml pci_0000_81_10_2
pci_0000_81_10_2
/sys/devices/pci0000:80/0000:80:03.0/0000:81:10.2
pci_0000_80_03_0
ixgbevf
0
129
16
2
82599 Ethernet Controller Virtual Function
Intel Corporation
NOTE:主要关注 设备信息,e.g.
domain='0x0000'
bus='0x81'
slot='0x10'
function='0x2'
上述这些字段组成了 PCI device 的唯一地址:address: 0000:81:10.2
。
Shut down the guest.
根据上述设备信息编写 new-dev XML 文件
$ cat /tmp/new-device.xml
$ virsh attach-device VM1 /tmp/new-device.xml --live --config
Device attached successfully
$ virsh dumpxml vm1
...
...
...
NOTE:或者可以直接 Edit 虚拟机的 XML 文件
virsh edit MyGuest
# 添加下述标签端:
root@vm1:~# ip addr show eth4
4: eth1: mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 2c:53:4a:02:20:3d brd ff:ff:ff:ff:ff:ff
inet 192.168.99.169/24 brd 192.168.99.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe3b:6128/64 scope link
valid_lft forever preferred_lft forever
virsh start MyGuest
$ virsh nodedev-dettach pci_0000_06_10_0
Device pci_0000_06_10_0 detached
qemu-system-x86_64 -enable-kvm -drive file=,if=virtio -cpu host -smp 16 -m 16G \
-name -device vfio-pci,host= -device vfio-pci,host= -vnc :1 -net none
重点在于通过 -device vfio-pci,host=
将 VF Passthrough 到虚拟机。
其实,从逻辑上可以认为启用了 SR-IOV 技术后的物理网卡内置了一个特别的 Switch,将所有的 PF 和 VF 端口连接起来,通过 VF 和 PF 的 MAC 地址以及 VLAN ID 来进行数据包分发。
在 Ingress 上(从外部进入网卡):如果数据包的目的 MAC 地址和 VLAN ID 都匹配某一个 VF,那么数据包会分发到该 VF,否则数据包会进入 PF;如果数据包的目的 MAC 地址是广播地址,那么数据包会在同一个 VLAN 内广播,所有 VLAN ID 一致的 VF 都会收到该数据包。
在 Egress 上(从 PF 或者 VF 发出):如果数据包的 MAC 地址不匹配同一 VLAN 内的任何端口(VF 或 PF),那么数据包会向网卡外部转发,否则会直接在内部转发给对应的端口;如果数据包的 MAC 地址为广播地址,那么数据包会在同一个 VLAN 内以及向网卡外部广播。
NOTE:所有未设置 VLAN ID 的 VF 和 PF,可以认为是在同一个 LAN 中,不带 VLAN 的数据包在该 LAN 中按照上述规则进行处理。此外,设置了 VLAN 的 VF,发出数据包时,会自动给数据包加上 VLAN,在接收到数据包时,可以设置是否由硬件剥离 VLAN 头部。