作者：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