SR-IOV 网卡虚拟化技术_sriov网卡

目录

目录

目录

SR-IOV

 在 KVM 中启用 SR-IOV 网卡

 手动挂载 VF 到虚拟机

指令方式挂载

SR-IOV 的数据包分发机制

---

SR-IOV

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 虚拟出来的通道分为两个类型：

1. ​PF（Physical Function，物理功能）​：管理 PCIe 设备在物理层面的通道功能，可以看作是一个完整的 PCIe 设备，包含了 SR-IOV 的功能结构，具有管理、配置 VF 的功能。
2. ​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 设备。
 

 在 KVM 中启用 SR-IOV 网卡

 手动挂载 VF 到虚拟机

1.查看 PCI 设备清单：

[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
...

2.查看选择的 PCI 设备详情：

[root@overcloud-compute-0 ~]# virsh nodedev-dumpxml pci_0000_81_10_2
<device>
  <name>pci_0000_81_10_2</name>
  <path>/sys/devices/pci0000:80/0000:80:03.0/0000:81:10.2</path>
  <parent>pci_0000_80_03_0</parent>
  <driver>
    <name>ixgbevf</name>
  </driver>
  <capability type='pci'>
    <domain>0</domain>
    <bus>129</bus>
    <slot>16</slot>
    <function>2</function>
    <product id='0x10ed'>82599 Ethernet Controller Virtual Function</product>
    <vendor id='0x8086'>Intel Corporation</vendor>
    <capability type='phys_function'>
      <address domain='0x0000' bus='0x81' slot='0x00' function='0x0'/>
    </capability>
    <iommuGroup number='46'>
      <address domain='0x0000' bus='0x81' slot='0x10' function='0x2'/>
    </iommuGroup>
    <numa node='1'/>
    <pci-express>
      <link validity='cap' port='0' width='0'/>
      <link validity='sta' width='0'/>
    </pci-express>
  </capability>
</device>

NOTE：主要关注 ​​<address domain='0x0000' bus='0x81' slot='0x10' function='0x2'/>​​ 设备信息，e.g.

domain='0x0000'
bus='0x81'
slot='0x10'
function='0x2'

上述这些字段组成了 PCI device 的唯一地址：​​address: 0000:81:10.2​​。

3.Shut down the guest.

4.根据上述设备信息编写 new-dev XML 文件

$ cat /tmp/new-device.xml
<interface type='hostdev' managed='yes'>
   <source>
     <address type='pci' domain='0x0000' bus='0x81' slot='0x10' function='0x2' />
   </source>
</interface>

5.将 New Device Attach 到 GuestOS

$ virsh attach-device VM1 /tmp/new-device.xml --live --config
Device attached successfully

6.查看 VM1 的 XML 更新

$ virsh dumpxml vm1
 ...
 <devices>
   ...
   <interface type='hostdev' managed='yes'>
      <mac address='52:54:00:f0:d3:b8'/>
      <driver name='kvm'/>
      <source>
        <address type='pci' domain='0x0000' bus='0x81' slot='0x10' function='0x2' />
      </source>
      <alias name='hostdev0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </interface>
    ...
  </devices>

​NOTE​：或者可以直接 Edit 虚拟机的 XML 文件

virsh edit MyGuest
 
# 添加下述标签端：
<hostdev mode='subsystem' type='pci' managed='yes'>
   <source>
      <address bus='0x81' slot='0x10' function='0x2'/>
   </source>
</hostdev>

7.进入 GuestOS 查看网卡信息

root@vm1:~# ip addr show eth4
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> 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

8.启动虚拟机

virsh start MyGuest

9.Dettach 虚拟机的 PCI 设备

$ virsh nodedev-dettach pci_0000_06_10_0
Device pci_0000_06_10_0 detached

指令方式挂载

qemu-system-x86_64 -enable-kvm -drive file=<vm img>,if=virtio -cpu host -smp 16 -m 16G \
  -name <vm name> -device vfio-pci,host=<vf pci bus addr> -device vfio-pci,host=<vf pci bus addr> -vnc :1 -net none

重点在于通过 ​​-device vfio-pci,host=<vf pci bus addr>​​ 将 VF Passthrough 到虚拟机。

SR-IOV 的数据包分发机制

其实，从逻辑上可以认为启用了 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 头部。