OpenStack企业私有云新需求（1）：Nova 虚机支持 GPU

作者：Sammy Liu 刘世民

本系列会介绍OpenStack 企业私有云的几个需求：

GPU 支持
自动扩展（Auto-scaling）支持
混合云（Hybrid cloud）支持
物理机（Bare metal）支持
CDN 支持
企业负载均衡器（F5）支持
大规模扩展性（100个计算节点）支持
商业SDN控制器支持

1.3 在虚机内使用 GPU 的几种方式（GPU 虚拟化）

1.3.1 集中 GPU 虚拟化实现技术

（1）API Remoting （远程API）

远程API 方法分为前端和后端两个部分。前端以动态库的形式被虚拟机中的CUDA程序加载，后端则是运行在宿主机中的一个程序。在这种机制下，首先由前端将虚拟机中的CUDA API重写，将API的名称和相应参数传递给后端。然后后端为前端每个CUDA应用程序创建一个进程，在该进程中转换来自前端重写后的API，获得API的名称和参数，接着使用宿主机上真实的GPU硬件设备执行相应的API，最后将 API执行结果返回给前端。

这种方法需要进行大量虚拟机与宿主机之间的数据传输，导致GPU虚拟化的性能严重下降。在CUDA程序规模较小时，这些GPU虚拟化框架的性能下降并不太明显。但在进行实际应用中的高性能计算时性能下降非常明显。

Parallels Desktop 所使用的技术和该技术非常接近。

（2） Device Emulation （GPU 设备仿真）

在客户机中提供一个仿真虚拟GPU，客户机上应用对它的调用都会被仿真层转化为对Hypervisor上物理 GPU 的调用。

（3）两种 Pass-through （透传）

（Fixed pass-through：固定透传，一个 GPU 只能给一个虚机使用）（Mediated pass-through：中介式透传，一个 GPU 可以给多个虚机使用）

（4）全虚拟化

全虚拟化方案中，每个虚机拥有一个虚拟的GPU实例，多个虚机共享一个物理 GPU。下图是 Intel 的 GPU 全虚拟化示意图：

1.3.2 Intel 实现的 GPU 虚拟化

Intel 有如下几种 GPU 虚拟化技术：

三者之间的比较：

第三个最先进，它支持 GPU 全虚拟化，以及在多个虚机之间共享一个物理GPU。目前已经在 Xen 中完整地支持该技术（XenGT 项目）。但是在 KVM 中，KVMGT 是在 KVM 内的实现，但是直到 2014/12月 Intel 才出一个 KVMGT 版本，目前仍然处于初级阶段（资料来源）。

Nvidia 实现的 GPU 全虚拟化

跟 Intel 的情况差不多，Nvidia K1/K2 GPU 也有 GPU 全虚拟化技术，但是目前也是不支持 KVM，而是只支持几家主流的虚拟化软件比如 Hyper-V 和 VMware 等(资料来源)。

1.4 透传（Pass-through）技术

从上面的介绍可以看出，目前主要的 GPU厂商包括 Intel 和 Nvidia 的全虚拟化方案主要还是针对某几种商业虚拟化软件比如 Hyper-V 和 VMware 等，对于 KVM 的支持要么没有，要么还处于早期阶段。鉴于 KVM 在 OpenStack 计算虚拟化层的地位，OpenStack Nova 支持的也只是 GPU 透传给客户机。QEMU/KVM GPU 透传主要有两种实现方式。

1.4.1 两种实现方式

（1）pci-assign 方式

主流地，QEMU/KVM 使用 PCI Assign 技术将KVM主机上的一个 PCI 设备比如 GPU 和网卡等直接分配给一个虚机。这技术需要 Intel VT-d 或者 AMD IOMMU 硬件支持。下面是一个 Intel 平台上的实现步骤的例子：

# Boot kernel with ‘intel_iommu=on’# Unbind driver from the device and bind ‘pci-stub’ to it

echo “168c 0030″ > /sys/bus/pci/drivers/pci-stub/new_id

echo 0000:0b:00.0 > /sys/bus/pci/devices/0000:0b:00.0/driver/unbind

echo 0000:0b:00.0 > /sys/bus/pci/drivers/pci-stub/bind

# Then just run

sudo qemu-system-i386 -m 1024 \ -device pci-assign,host=0b:00.0,rombar=0 \ -enable-kvm \ -kernel $KERNEL \ -hda $DISK \ -boot c \ -append “root=/dev/sda rw”

（2） VFIO 方式

VFIO 在 Linux kernel3.6/qemu1.4 以后支持，目前只支持 PCI 设备。VFIO 是一套用户态驱动框架，提供两种基本服务：向用户态提供设备访问接口和向用户态提供配置IOMMU 接口。它第一次向用户态开放了 IOMMU 接口，能完全在用户态配置 IOMMU，将 DMA 地址空间映射进而限制在进程虚拟地址空间之内。

VFIO 可以用于实现高效的用户态驱动。在虚拟化场景可以用于 PCI 设备透传。通过用户态配置IOMMU接口，可以将DMA地址空间映射限制在进程虚拟空间中，这对高性能驱动和虚拟化场景device passthrough尤其重要。相对于传统方式，VFIO对UEFI支持更好。VFIO 技术实现了用户空间直接访问设备。无须root特权，更安全，功能更多。

它对环境有如下要求：

AMD-Vi or Intel VT-d capable hardware
Linux 3.6+ host
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO=m
CONFIG_VFIO_PCI=m
modprobe vfio-pci
Qemu 92e1fb5e+ (1.3 development tree)

透传技术的局限性

透传技术能带来几乎和物理设备同等的性能，但是它也带来了一些局限性。设备透传带来的一个问题体现在实时迁移方面。实时迁移是指一个 VM 在迁移到一个新的物理主机期间暂停迁移，然后又继续迁移，该 VM 在这个时间点上重新启动。实时迁移是在一个物理主机网络上支持负载平衡的一个很好的特性，但使用透传设备时它会产生问题。PCI 热插拔（有几个关于它的规范）就是需要解决的一个问题。PCI 热插拔允许 PCI 设备从一个给定内核进出，这很理想 — 特别是将 VM 迁移到新主机上的管理程序时（设备需要在这个新管理程序中拔出然后再插入）。当设备被模拟（比如虚拟网络适配器）时，模拟提供一个抽象层以抽象物理硬件。这样，一个虚拟网络适配器可以在该 VM 内轻松迁移（这个 VM 还得到 Linux® 绑定驱动程序的支持，该驱动程序支持将多个逻辑网络适配器绑定到相同的接口上）。

更详细的介绍，可以阅读文档 http://www.linux-kvm.org/images/b/b4/2012-forum-VFIO.pdf。

1.5 公有云上的 GPU 支持

（1）阿里云 GPU 物理机，用于高新能计算

阿里云（来源）为高性能计算提供带 GPU 的物理机，配置如下：

双路Xeon E5－2650v2 2.6GHz
128G 内存
Raid5 13T 数据盘
K40M x2 GPU

该物理机的单机峰值计算能力可达每秒11万亿次单精度浮点运算。

（2）Amazon GPU 虚拟机，可用于 3D 应用程序流、机器学习、视频编码和其他服务器端图形或 GPU 计算工作等负载，包括 Linux GPU 虚机和 Windows GPU 虚机。虚拟机配置如下：

（资料来源）

2. OpenStack Nova（QEMU/KVM）对 GPU 的支持

OpenStack 官网的 https://wiki.openstack.org/wiki/Pci_passthrough 文章说明了 Nova 对 GPU 的支持。本章节就从配置和代码等角度来分析Nova是如何支持 GPU 透传的。

2.1 环境准备

可以使用 lspci 命令来获取 GPU PCI 设备：

# lspci -nn | grep NVI85:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104GL [GRID K2] [10de:11bf] (rev a1)86:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104GL [GRID K2] [10de:11bf] (rev a1)

输出中各个值的说明：

输出值	含义	详细解释
“85:00.0″ 和 “86::00.0”	以 ”bus:slot.func“ 格式来唯一标识一个 PCI 功能设备	唯一定位一个 PCI 设备的虚拟功能，可以是一个物理设备，也可以是一个多功能设备的功能设备，一个多功能设备可以最多有8个功能。

总线号（bus）：从系统中的256条总线中选择一条，0–255。
设备号（slot）：在一条给定的总线上选择32个设备中的一个。0–31。
功能号（func）：选择多功能设备中的某一个功能，有八种功能，0–7。 PCI规范规定，功能0是必须实现的。

”0300“PCI 设备类型指 PCI 设备的类型，来自不同厂商的同一类设备的类型码可以是相同的。“10de”供应商识别字段（Vendor ID）该字段用一标明设备的制造者。一个有效的供应商标识由 PCI SIG 来分配，以保证它的唯一性。Intel 的 ID 为 0×8086，Nvidia 的 ID 为 0x10de“11bf”设备识别字段（Device ID）用以标明特定的设备，具体代码由供应商来分配。本例中表示的是 GPU 图形卡的设备 ID。“a1” 版本识别字段（Revision ID）用来指定一个设备特有的版本识别代码，其值由供应商提供

下图说明了 PCI 域、总线、设备等概念之间的联系（lspci 的输出没有标明域，但对于一台 PC 而言，一般只有一个域，即0号域。）：

（来源）

2.2 KVM主机和Nova 配置

2.2.1 修改 Nova 配置

节点	配置文件	需要修改的配置	说明
控制（API）节点	/etc/nova/nova.conf	添加配置项：pci_alias={“vendor_id”:”10de”, “product_id”:”11bf”, “name”:”a1″}	这是为了在 Nova flavor 中可以很方便的使用 alias的需要而添加的。
计算节点	/etc/nova/nova.conf	添加配置项：pci_passthrough_whitelist=[{ "vendor_id":"10de","product_id":"11bf"}]	并不是一个计算节点上的所有 PCI 设备都运行被分配给客户机，云管理员可以使用该配置项来指定可以分配的 PCI 设备的范围。

在 Nova 中，PCI 设备可以分为几类：1、普通的 PCI 设备 2. SR-IOV PF 设备 3. SR-IOV VF 设备。通常 SR-IOV PF 设备都是不可以直接分配给客户机的，因此，该配置项是来指定可以分配的 “普通 PCI 设备”以及 “SR-IOV VF” 的范围。Nova scheduler 节点/etc/nova/nova.confscheduler_available_filters=nova.scheduler.filters.all_filters

scheduler_available_filters=nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter

修改配置项：scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,

ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter增加 PciPassthroughFilter

2.2.2 Nova 步骤

（1）创建一个 nova flavor 并设置属性。本例子中直接设置已有 m1.small 的属性：

nova flavor-key m1.small set “pci_passthrough:alias”=”a1:1″

其中，

“pci_passthrough:alias” 是固定的 key 字符串，用于指定该 flavor 对 PCI 设备的需求
“a1:1″ 的格式是 ‘alias_name_x:count, alias_name_y:count, … ‘ ，可以指定多个，每个 alias_name 由 pci_alias 配置项中的 ”name“ 指定。

（2）使用该 flavor 创建一个虚机

nova boot –image new1 –key_name test –flavor m1.small 123

（3）待虚机变为可用状态后，登录，使用 lspci 命令查看 GPU 设备

nova ssh –private 123 -i test.pem