信创环境实战：在OpenStack中为海光C86节点配置英伟达T4 GPU直通

1. 从硬件到云信创环境下的异构算力集成挑战最近几年信创产业搞得是风生水起越来越多的企业和单位开始尝试在国产化的技术栈上构建自己的核心业务平台。我手头就来了这么个活儿在一个基于海光C86处理器的信创服务器集群上集成英伟达的Tesla T4 GPU并且要在OpenStack云环境里实现GPU的直通PCI Passthrough给上层的AI训练和推理应用提供算力。这活儿听起来挺酷但实际干起来真是一步一个脚印踩了不少坑也积累了不少经验。海光C86处理器大家应该不陌生性能不错生态也在逐步完善。英伟达T4更是数据中心里常见的“多面手”兼顾了推理和部分训练任务。但把这俩“混搭”在一起放到OpenStack里做直通问题就来了。这不像在标准的x86平台上那么“理所当然”从BIOS设置、内核参数到OpenStack服务的配置每一步都可能遇到兼容性或者配置上的“小脾气”。我记得最开始拿到两台配置几乎一样的海光C86机器结果只有一台能成功直通另一台死活不行这就很能说明问题——细节决定成败。这篇文章我就想把自己趟过的路、踩过的坑原原本本地分享出来。目标很明确让后来者哪怕是对OpenStack和海光平台不太熟悉的朋友也能按照这个指南一步步地把T4 GPU成功挂载到云主机上快速用起来。我们不谈太多空洞的理论就聚焦在“怎么做”和“为什么这么做”上保证你跟着操作就能看到结果。2. 实战第一步深度检查你的硬件状态在动手改任何配置文件之前有一项工作至关重要甚至能帮你省下后面80%的排查时间那就是彻底检查你的硬件状态。很多人一上来就照着教程改GRUB、改Nova配置结果云主机启动失败回头一看才发现GPU卡本身在物理机上就没被系统正确识别。所以咱们先当个“硬件医生”给机器做个全面体检。2.1 使用lspci进行初步诊断打开计算节点的终端我们最得力的工具就是lspci命令。但别只用lspci | grep -i nvidia这种简单命令那样信息太少了。我强烈建议使用lspci -v或者lspci -vvv来获取详细信息。关键要看几个点设备ID与状态找到你的T4显卡。英伟达T4的设备ID通常是1eb8这是十六进制表示。在lspci -v的输出中你会看到类似3D controller: NVIDIA Corporation Device 1eb8 (rev a1)的一行。这确认了系统“看见”了这张卡。内存映射区域这是最关键的判断依据。在输出信息里寻找Memory at开头的行。它们后面绝对不能跟着[disabled]。如果内存区域是disabled状态就像我遇到的第一台机器那样那么这张卡在硬件层面或BIOS层面就没有被正确初始化和分配资源后续无论如何配置软件都是徒劳。正常的输出应该像这样Memory at d9000000 (32-bit, non-prefetchable) [size16M] Memory at 16fd0000000 (64-bit, prefetchable) [size256M] Memory at 17000000000 (64-bit, prefetchable) [size32M]这表示GPU的显存和寄存器空间已经被成功映射到了系统的物理地址空间这是直通能进行的前提。驱动绑定查看Kernel driver in use:这一行。在准备做直通时我们不希望它被nouveau开源驱动或nvidia闭源驱动占用。理想的状态是它已经被vfio-pci驱动绑定或者至少没有被任何驱动绑定显示为(none)。如果被其他驱动占用了我们需要先解除绑定。2.2 对比分析成功与失败的案例在我实际的项目里两台海光C86机器就上演了生动的对比。第一台机器的lspci -v输出中关键的内存区域全部显示为[disabled]并且IRQ是255通常表示未分配或错误。这种情况下我尝试了重启、重插卡、更新BIOS但问题依旧。最终判断可能是主板PCIe插槽或固件层面的兼容性问题这台机器暂时就不适合做GPU直通转而用作纯CPU计算节点。而第二台机器所有内存区域状态正常IRQ也有明确的数字如747这给了我很大的信心。同时我还找了一台标准的x86服务器搭载Intel CPU作为对照。在x86机器上T4的显示信息更加“完整”比如Capabilities: [c8] MSI-X: Enable中的Enable表示MSI-X中断能力已启用而在海光机器上可能是Enable-。这些细微差别需要留意但只要核心的内存映射是正常的就不影响直通的基本功能。注意如果你的卡显示内存[disabled]先别放弃。可以尝试以下步骤1) 重启服务器进入BIOS检查PCIe相关设置确保Above 4G Decoding、SR-IOV如果涉及等选项是开启的2) 更换PCIe插槽试试优先使用CPU直连的插槽3) 更新主板BIOS和BMC固件到最新版本。如果这些都试过了还不行那可能就是硬件兼容性列表之外的问题了。3. 核心配置打通硬件虚拟化的任督二脉确认硬件状态良好后我们就可以开始进行核心的系统与OpenStack配置了。这个过程就像是给系统“开权限”告诉它“这台设备可以单独划给某个虚拟机直接管理”。3.1 基础中的基础启用IOMMUIOMMUInput-Output Memory Management Unit是CPU提供的一种硬件特性它允许系统将DMA直接内存访问操作重新映射并提供了设备隔离的能力。没有它PCI设备直通就无法实现因为虚拟机无法安全、直接地访问物理设备的内存空间。对于海光AMD架构的C86平台我们需要在Linux内核启动参数中启用AMD的IOMMU。编辑/etc/default/grub文件找到GRUB_CMDLINE_LINUX这一行。通常它看起来像这样GRUB_CMDLINE_LINUXcrashkernelauto rd.lvm.lvcentos/root rd.lvm.lvcentos/swap rhgb quiet我们需要在其中添加两个参数amd_iommuon和iommupt。修改后如下GRUB_CMDLINE_LINUXcrashkernelauto amd_iommuon iommupt rd.lvm.lvcentos/root rd.lvm.lvcentos/swap rhgb quietamd_iommuon显式开启AMD平台的IOMMU功能。iommupt这个参数非常有用它表示“Pass-Through”模式。在这种模式下内核只为那些真正需要做DMA重映射的设备即被直通的设备启用IOMMU页表而对于其他设备则保持原样。这能减少性能开销是直通场景下的推荐设置。修改完成后需要重新生成GRUB配置文件。根据你的引导方式BIOS或UEFI命令略有不同。对于常见的UEFI系统CentOS/RHEL 7grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg或者对于BIOS系统grub2-mkconfig -o /boot/grub2/grub.cfg操作完成后务必重启服务器。重启后可以通过检查内核启动参数来确认是否生效cat /proc/cmdline | grep iommu或者检查dmesg日志dmesg | grep -i iommu你应该能看到类似AMD-Vi: IOMMU performance counters supported和AMD-Vi: Found IOMMU at ...的信息这表明IOMMU已成功启用。3.2 精准定位配置OpenStack Nova的PCI透传白名单OpenStack Nova服务是管理计算资源的“大脑”。我们需要告诉它哪张PCI设备是可以被透传的。这是通过passthrough_whitelist配置项来实现的。这个配置就像一个“通行证”名单只有名单上的设备才会被Nova-compute服务识别为可直通设备。配置位置在计算节点即安装了GPU的物理机的/etc/kolla/nova-compute/nova.conf文件中如果你使用Kolla-Ansible部署。在[pci]配置段下添加[pci] passthrough_whitelist {vendor_id:10de,product_id:1eb8} alias {name:Tesla T4, vendor_id:10de, product_id:1eb8, device_type:type-PF}我们来拆解一下这几个参数passthrough_whitelist这是过滤器的核心。vendor_id“10de” 是英伟达的PCI厂商IDproduct_id“1eb8” 对应Tesla T4。这个JSON格式的过滤器会匹配所有符合该ID的PCI设备。如果你的节点上有多个同型号GPU它们会被全部匹配。alias这个别名配置不是必须的但强烈建议设置。它给这类设备起了一个在OpenStack内部使用的友好名字“Tesla T4”。后面我们在创建云主机类型Flavor时就会引用这个名字。device_type字段需要特别注意type-PF指物理功能Physical Function适用于普通直通和SR-IOV的PFtype-VF指虚拟功能Virtual Function仅用于SR-IOV。对于T4的普通直通如果你不确定或者配置后直通失败可以尝试直接移除device_type:type-PF这一整行。很多情况下不指定device_type反而能成功让Nova自动识别。踩坑提醒我最初就是在这里栽了跟头。我严格按照某些教程写上了device_type:type-PF结果创建云主机时调度失败。排查了很久最后注释掉这行就好了。所以如果你的T4不是用于SR-IOV不妨先不加这个参数试试。3.3 全局同步配置控制节点服务光计算节点自己知道还不够负责调度和创建虚拟机的控制节点服务也需要知晓这个“通行证”名单。我们需要在三个关键服务的配置文件中添加同样的alias信息。Nova-API(/etc/kolla/nova-api/nova.conf)在[pci]段添加别名。同时确保scheduler_default_filters列表中包含PciPassthroughFilter。这个过滤器是调度器用来根据PCI设备需求选择合适计算节点的。[DEFAULT] scheduler_default_filters AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,PciPassthroughFilter,IsolatedHostsFilter [pci] alias {name:Tesla T4, vendor_id:10de, product_id:1eb8}Nova-Conductor(/etc/kolla/nova-conductor/nova.conf)同样在[pci]段添加别名。scheduler_default_filters的配置通常与API节点保持一致。[DEFAULT] scheduler_default_filters AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,PciPassthroughFilter,IsolatedHostsFilter [pci] alias {name:Tesla T4, vendor_id:10de, product_id:1eb8}Nova-Scheduler(/etc/kolla/nova-scheduler/nova.conf)这是调度决策的核心。除了添加[pci]段的别名还要确认[filter_scheduler]下的enabled_filters包含了PciPassthroughFilter。[filter_scheduler] enabled_filters AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,PciPassthroughFilter,IsolatedHostsFilter [pci] alias {name:Tesla T4, vendor_id:10de, product_id:1eb8}修改完以上所有配置后需要重启相关的容器服务以Kolla部署为例docker restart nova_api nova_conductor nova_scheduler重启计算节点上的nova-compute服务docker restart nova_compute # 或者 systemctl restart nova-compute (非容器化部署)重启后务必检查各个服务的日志确保没有因配置错误而启动失败。4. 验证与部署让GPU资源在云中可见可用配置都改好了服务也重启了怎么知道OpenStack真的识别到了我们的T4显卡呢接下来就是验证和最终部署的环节。4.1 数据库验证PCI设备信息入库OpenStack会将所有计算节点上报的PCI设备信息存储在其数据库中通常是MariaDB/MySQL。我们可以直接查询数据库来确认。登录到控制节点连接到Nova数据库mysql -u root -p -D nova执行查询SELECT compute_node_id, address, vendor_id, product_id, status FROM pci_devices WHERE product_id1eb8;如果配置正确你应该能看到一条或多条记录其status字段为available。这证明计算节点已经成功将GPU信息上报并且该设备处于“可用”状态等待被虚拟机使用。这是配置成功的一个非常确凿的证据。如果这里查不到就需要回头去检查计算节点nova-compute的日志看它是否在启动时正确扫描并上报了PCI设备。4.2 创建GPU专属的云主机类型现在GPU资源已经在资源池里了我们需要一种方式让用户在创建云主机时申请它。这就是通过“云主机类型”Flavor的“额外规格”Extra Specs来实现的。首先你可以创建一个新的Flavor或者使用一个已有的。然后为这个Flavor设置元数据Extra Specs。关键的一条元数据是pci_passthrough:alias Tesla T4:1这条命令的意思是使用这个Flavor创建的云主机需要挂载1个别名为“Tesla T4”的PCI设备。冒号后面的数字就是需要的数量。如果你想一个虚拟机挂载2张T4就写成Tesla T4:2。你可以通过OpenStack命令行工具来设置# 假设你有一个名为‘gpu.large’的flavor openstack flavor set gpu.large --property “pci_passthrough:alias”“Tesla T4:1”设置完成后可以用openstack flavor show gpu.large命令来确认extra_specs中是否包含了这行配置。4.3 创建GPU云主机并验收成果激动人心的时刻到了使用刚才配置好的GPU Flavor选择一台合适的镜像建议使用已经安装了NVIDIA驱动和CUDA的基础镜像或者支持Cloud-Init的镜像以便后续安装驱动创建一台云主机。创建过程中OpenStack调度器Scheduler会寻找那些拥有“可用”状态“Tesla T4”设备的计算节点并将虚拟机调度到上面。创建成功后通过VNC或SSH登录到这台云主机。在云主机内部进行最终的验证再次使用lspci运行lspci | grep -i nvidia。你应该能看到T4显卡出现在虚拟机内部的PCI设备列表中。这直接证明了直通成功——虚拟机认为自己“拥有”了这块物理显卡。安装驱动并测试如果镜像里没有预装驱动需要安装对应的NVIDIA驱动。安装完成后运行nvidia-smi命令。如果一切顺利你将看到熟悉的T4显卡信息面板包括GPU利用率、显存占用、驱动版本等。此时你就可以像在物理机上一样运行CUDA程序、进行AI推理或训练了。我清晰地记得当在云主机里第一次看到nvidia-smi正常输出时那种成就感。这意味着在信创的海光C86平台上我们成功地将高性能的异构算力英伟达T4以直通的方式融入了OpenStack云资源池为上层应用提供了近乎原生的GPU性能。5. 排错锦囊与性能调优思考即使按照步骤操作也难免会遇到问题。这里分享几个我遇到过的典型问题及解决思路。常见问题一云主机创建失败提示“No valid host was found”。原因这是最经典的调度失败。根本原因是调度器找不到满足Flavor中PCI设备需求的计算节点。排查步骤检查计算节点状态openstack compute service list确保目标计算节点的nova-compute服务状态是up。检查PCI设备数据库如上所述在Nova数据库中查询pci_devices表确认设备状态为available并且compute_node_id对应正确的计算节点。检查过滤器配置确认控制节点nova-scheduler的enabled_filters和计算节点/API节点的scheduler_default_filters都包含了PciPassthroughFilter。少一个都不行。检查别名一致性确保所有节点compute, api, conductor, scheduler的nova.conf中[pci]段下的alias定义完全一致包括名字、vendor_id、product_id。一个字母的错误都会导致匹配失败。常见问题二云主机启动后内部lspci能看到设备但nvidia-smi报错如NVIDIA-SMI has failed because it couldn‘t communicate with the NVIDIA driver。原因这通常不是直通配置问题而是虚拟机内部的操作系统或驱动问题。解决确认虚拟机镜像的内核版本与安装的NVIDIA驱动版本是否兼容。尝试在虚拟机内重新安装官方驱动。对于Linux可能需要先禁用自带的nouveau驱动。检查虚拟机是否安装了pciutils和linux-modules-extra等基础包。关于性能的思考直通模式下虚拟机独占GPU性能损耗极小主要来自IOMMU映射和中断虚拟化。为了获得最佳性能可以考虑CPU绑定与NUMA亲和性如果海光C86平台是多路CPU多个NUMA节点而GPU插在某个CPU上尽量将虚拟机的vCPU和内存分配在同一个NUMA节点上可以大幅减少跨节点访问的延迟。在创建Flavor或云主机时可以通过hw:numa_nodes等元数据进行控制。巨页Huge Pages为虚拟机使用巨页内存可以减少TLB缺失对内存访问密集型的GPU应用有性能提升。需要在计算节点主机上预留巨页并在Flavor中设置hw:mem_page_sizelarge。PCIe ACSAccess Control Services确保BIOS中启用了PCIe ACS。这有助于IOMMU组进行更细粒度的隔离。如果一张显卡和其他设备如网卡在同一个IOMMU组里直通这张显卡时可能不得不把同组设备都直通出去。ACS可以解决这个问题但依赖于硬件支持。整个配置过程走下来你会发现在信创的海光平台上为OpenStack配置GPU直通其核心步骤和原理与标准的x86平台并无二致。最大的差异往往体现在最初的硬件兼容性检查和BIOS设置上。只要硬件层面通过了“体检”后续的软件配置就是一套相对标准化的流程。这份指南的目的就是帮你系统性地走完这个流程避开那些我曾经掉进去的坑最终在信创云环境中稳稳地跑起你的GPU应用。