1. 先把需求拆开你说的“用上 GPU”到底是哪一种虚拟机里跑 Ubuntu想借用宿主机那块显卡这个问题在我这些年接的咨询里出现频率相当高。很多人上手第一步就是打开虚拟机设置找“显卡”选项翻遍了也没看到能指定物理 GPU 的地方于是开始怀疑是不是软件版本不对、是不是少装了什么插件。实际情况是VMware Ubuntu 虚拟机使用宿主机 GPU 资源这件事本身分成两条完全不同的技术路线它们的原理、前提、能达成的效果差得非常远如果不先分清自己要的是哪一种后面所有操作都是白费劲。我一般会让对方先回答一个问题你在 Ubuntu 里到底要干嘛是要跑桌面、看视频不卡还是要开 Blender 做三维建模、跑 OpenGL 渲染还是要跑 PyTorch 训练模型、跑 CUDA 程序这三个诉求对应的方案完全不同甚至可以说第三个诉求在 VMware Workstation 这个平台上根本没有解。把需求分清楚比急着改配置文件重要得多。这篇文章我按“方案一Workstation 内置的虚拟 3D 加速通道”和“方案二PCIe 直通把整块物理卡交给 Ubuntu”两条主线来写中间穿插一条很多人忽略的折中路线。方案一零成本、十分钟能验证适合图形界面和轻量 OpenGL方案二要换虚拟化平台、要折腾内核参数但能拿到接近原生的 CUDA 算力。两条路的坑我都踩过下面会一条条拆。1.1 三个层次显示加速、图形渲染、通用计算我把虚拟机用 GPU 的需求粗分成三层从上往下难度递增能拿到的性能递减。第一层是显示加速。目标只是让 Ubuntu 桌面拖动窗口不撕裂、分辨率能上到 2K、看 4K 视频不掉帧。这一层其实是 CPU 在做光栅化GPU 参与度很低Workstation 自带的虚拟显卡配合open-vm-tools-desktop基本够用很多时候你甚至不需要开 3D 加速。第二层是图形渲染。跑 OpenGL 应用、跑 glmark2、跑轻量级的 CAD 查看器、跑一些基于 Qt 的图形程序。这一层必须打开 Workstation 的 3D 加速让客户机里的 Mesa 通过vmwgfx驱动把 OpenGL 指令转发到宿主机由宿主机真实的 GPU 完成渲染再回传画面。这条路能跑通但性能是打折的而且有明确的版本上限。第三层是通用计算。CUDA、OpenCL、ROCm、TensorFlow、PyTorch、视频硬编码NVENC、大模型推理。这一层的关键不是“画面”而是显存和计算单元的直接访问虚拟显卡完全无能为力必须走 PCIe 直通让 Ubuntu 看到一张货真价实的物理显卡装原厂驱动。提示判断自己在哪一层最简单的办法是想一下“这个程序需不需要知道显卡型号”。nvidia-smi能看到卡就是第三层只有glxinfo能看到渲染器名字那是第二层连glxinfo都显示软件渲染那就是第一层。我见过太多人想用方案一去跑 CUDA折腾两天最后一查nvidia-smi报“command not found”才意识到方向从一开始就错了。所以下面这张表建议先看一遍再决定往下读哪一章。需求层次典型场景VMware Workstation 能否满足推荐路线显示加速桌面流畅、多显示器、高清视频能原生支持装 open-vm-tools-desktop 即可图形渲染OpenGL 应用、轻量建模、界面预览能但有性能损耗和版本天花板方案一通用计算CUDA、PyTorch、视频编码、推理不能方案二混合场景一边建模一边渲染部分能需要权衡方案一 折中路线1.2 为什么虚拟机里永远看不到真实的显卡型号Workstation 给虚拟机提供的显卡是一块虚拟设备PCI 标识是 VMware 自己的厂商 ID客户机里的lspci看到的是一行SVGA II Adapter。这块虚拟卡的作用是接管客户机的显示输出把帧缓冲通过共享内存交给宿主机上的 MKS鼠标键盘屏幕进程去合成。开了 3D 加速之后虚拟卡会多出一条通路客户机里 Mesa 的svga驱动把 OpenGL 命令序列化通过 VMCI 或共享内存送到宿主机宿主机的 MKS 用本机真实的 OpenGL 驱动也就是你装的显卡驱动去执行渲染结果再作为帧数据回传。所以你在 Ubuntu 里glxinfo看到的渲染器名字是SVGA3D开头而不是GeForce或Radeon。这个设计的本质是命令转发不是设备透传。宿主机 GPU 确实参与了工作但客户机全程不知道它的存在拿不到显存地址装不了原厂驱动自然也跑不了 CUDA。理解这一点后面所有的行为就都能解释了为什么帧率上不去、为什么某些 OpenGL 扩展不支持、为什么nvidia-smi找不到设备。还有一层容易被忽略这条转发链路上的每一环都可能成为瓶颈。宿主机的 OpenGL 驱动版本、MKS 的编译选项、客户机 Mesa 的版本、虚拟显存的大小、甚至宿主机的电源管理策略独显被降频都会影响最终表现。这也是为什么同样配置的两台机器一个人跑 glmark2 能到 2000 分另一个人只有 800 分。1.3 两条路线的全景对比在动手之前先把两条路线的代价摆清楚避免做到一半发现方向不对。对比项方案一内置 3D 加速方案二PCIe 直通虚拟化平台VMware Workstation ProKVM/QEMU VFIO 或 ESXi硬件要求无特殊要求CPU 支持 VT-d/AMD-Vi主板支持 IOMMU显卡要求任意需要至少两块显卡一块给宿主输出客户机看到的设备SVGA II 虚拟显卡真实物理显卡能否装原厂驱动不能能CUDA 支持不支持完整支持OpenGL 上限受转发链路限制通常到 4.x 级别与原生一致性能损耗图形 40%~70%计算不可用图形 5%~10%计算 3%~5%配置耗时10 分钟半天到两天主要风险几乎无分组不理想、单卡直通失败、vBIOS 问题这张表最需要关注的是“显卡要求”和“配置耗时”两行。方案二看起来香但它有个硬前提宿主机得有一块能独立输出画面的显卡。如果你的机器只有一块独显又想让这块独显直通给 Ubuntu那么在直通生效期间宿主机是没有画面的后面的操作全靠 SSH。这种“单卡直通”不是不能做但对新手极不友好。我的建议比较直接如果需求停在第二层老老实实用方案一把时间省下来干正事如果明确要跑 CUDA那就别在 Workstation 上耗了直接上方案二Workstation 在这件事上帮不了你。2. 方案一把 Workstation 的 3D 加速通道真正打开这一章是给那些“只是想跑个图形程序”“想看看 Ubuntu 桌面能不能顺滑一点”的人准备的。整个流程加起来不超过半小时绝大多数失败案例的原因都可以归结为三个字没生效。配置看起来都改了glxinfo一跑还是软件渲染。我先把结论放前面方案一要生效需要宿主机驱动正常 .vmx 参数正确 客户机驱动栈完整三个条件同时满足缺一不可。下面按这三个条件依次拆。2.1 宿主机侧的准备与自检宿主机这一侧的准备工作经常被跳过但它是整条链路的地基。MKS 最终是用宿主机的 OpenGL 驱动去执行渲染的如果宿主机自己都没装好显卡驱动虚拟机里再折腾也没用。先确认宿主机显卡驱动状态。Windows 宿主机打开设备管理器看显示适配器下面有没有黄色感叹号右键属性看驱动版本顺手跑一下dxdiag在“显示”标签页确认 DirectX 功能级别正常。Linux 宿主机用glxinfo -B看渲染器是不是独显名字如果显示llvmpipe说明走的是软件渲染得先把驱动装好。第二件事是确认 Workstation 版本。3D 加速的能力上限跟版本强相关较新的版本对 OpenGL 4.x 级别和 DirectX 11 级别的虚拟图形支持更完整老版本可能只到 OpenGL 3.3。虚拟机的硬件兼容性版本也要跟着提上去在虚拟机设置里把“兼容性”调到当前 Workstation 支持的最高档否则新特性会被硬件版本卡住。第三件事是宿主机电源管理。笔记本上这一点特别明显独显被系统判定为空闲后会自动降频甚至断电虚拟机里的渲染请求过去时 GPU 还在“醒神”表现出来就是前几秒卡顿、后面才正常。可以的话把宿主机电源计划切成高性能或者把 Workstation 进程加到显卡控制面板的“高性能”列表里。注意宿主机如果有双显卡核显 独显要确认 Workstation 用的是哪一块。Windows 上可以在“图形设置”里给vmware.exe指定“高性能”不然默认可能被分配到核显性能差一大截。2.2 .vmx 关键参数逐条拆解Workstation 的图形相关配置在虚拟机设置界面只能勾一个“加速 3D 图形”剩下的大量参数藏在.vmx文件里。这个文件在虚拟机的存放目录下用文本编辑器打开就能改改之前先把虚拟机关机——运行中改会被覆盖。下面这组是我目前用得最稳的配置逐条说明mks.enable3d TRUE mks.enableGLES TRUE mks.gl.allowBlacklistedDrivers TRUE svga.autodetect FALSE svga.vramSize 536870912 svga.maxWidth 3840 svga.maxHeight 2160 vmotion.checkpointFBSize 536870912 mks.maxRefreshRate 60mks.enable3d是总开关等价于界面上的“加速 3D 图形”勾选框必须为 TRUE。这一项如果为 FALSE后面所有参数都没意义。mks.enableGLES打开 OpenGL ES 通路。有些图形栈尤其是基于 Qt 或 Wayland 的现代应用走的是 GLES 而不是桌面 OpenGL不开这一项可能会出现窗口黑屏、界面渲染异常。mks.gl.allowBlacklistedDrivers是应急开关。Workstation 内部维护了一份宿主驱动黑名单某些版本的驱动会被判定为“不兼容”而强制退回软件渲染。如果你确认宿主机驱动工作正常、glxinfo也没问题但虚拟机里就是不加速把这个设成 TRUE 大概率能解决。svga.autodetect设为 FALSE 是为了让下面的显存和分辨率参数生效。设为 TRUE 时 Workstation 会自动决定显存大小通常是 128MB 或 256MB跑高分辨率或者多显示器会不够。svga.vramSize是虚拟显存单位是字节。536870912就是 512MB。这个值不是越大越好超过一定范围对性能没有帮助反而会占用宿主机内存。我一般按分辨率给1080p 给 256MB4K 或多显示器给 512MB 到 1GB。如果客户机里要开比较大的纹理或者多窗口并行渲染可以再往上调一档。svga.maxWidth和svga.maxHeight是虚拟显示的最大分辨率。这两个值如果你不改虚拟机里设置分辨率时会发现超过某个值就被截断了。4K 场景下设成 3840×2160超宽屏可以设 5120×1440。vmotion.checkpointFBSize这个参数名字很误导它跟迁移没关系实际控制的是快照和挂起时保留的帧缓冲大小。必须和svga.vramSize保持一致否则虚拟机挂起再恢复可能黑屏。这个坑我踩过一次排查了半天才发现是这两项对不上。mks.maxRefreshRate限制客户机的刷新率上限。默认值在某些高刷屏上会导致 CPU 占用异常设成 60 是比较保守稳妥的做法追求高刷可以设 120 试试。改完之后保存启动虚拟机进系统验证。2.3 Ubuntu 客户机驱动栈与验证方法客户机侧最常犯的错误是只装了open-vm-tools没装open-vm-tools-desktop。前者是基础服务后者才包含图形相关的组件包括分辨率自适应、剪贴板共享、3D 加速的客户机侧支持。sudo apt update sudo apt install -y open-vm-tools open-vm-tools-desktop mesa-utilsmesa-utils里包含glxinfo和glxgears是验证的核心工具。装完重启一次让vmwgfx内核模块重新加载。重启后先确认内核模块lsmod | grep vmwgfx有输出说明模块加载正常。如果为空检查是不是把nomodeset加到内核参数里了——这个参数会禁用内核态显卡驱动vmwgfx起不来3D 加速必然失效。然后验证 OpenGLglxinfo -B重点看三行OpenGL renderer string正常应该是SVGA3D开头的字符串例如SVGA3D; build: RELEASE; LLVM;。如果显示llvmpipe (LLVM xx.x, 256 bits)说明走的是 CPU 软件渲染3D 加速没生效。OpenGL version string这里能看到客户机支持的 OpenGL 版本上限通常和虚拟硬件版本、Mesa 版本有关。Device显示的是虚拟显卡标识。如果是 Wayland 会话glxinfo可能会连到 XWayland 上读出来的信息不一定准。先确认会话类型echo $XDG_SESSION_TYPE如果是wayland而glxinfo结果异常可以注销后在登录界面右下角的齿轮里切回Ubuntu on Xorg再测。Xorg 会话下glxinfo的结果更能反映真实状态。想更直观地看性能装一个glmark2sudo apt install -y glmark2 glmark2跑完会给出一个总分。这个分数不用跟网上的数据比因为差异太大它的价值在于你自己机器的前后对比改参数前跑一次改完再跑一次看有没有提升。2.4 实测表现与能力边界我在一台配备中端独显的机器上做过一组对比宿主机是 WindowsWorkstation 版本较新Ubuntu 22.04 客户机配置 4 核 8G 内存。同一套glmark2结果大致如下配置状态glmark2 总分glxinfo 渲染器CPU 占用未开 3D 加速约 300llvmpipe极高跑分时占满两核开 3D 加速显存 256MB约 1500SVGA3D中等开 3D 加速显存 512MB4K 上限约 1800SVGA3D中等同硬件实体机原生约 8000独显型号低这组数据里最值得注意的是最后一行的对比。即便配置调到最优虚拟机的图形性能也只有实体机的两成出头。这个差距不是配置问题是转发架构本身的代价——每一条 OpenGL 命令都要序列化、跨虚拟机边界传输、在宿主机上重放链路越长损耗越大。所以方案一的适用边界很清晰够用的场景Ubuntu 桌面日常操作、浏览器多标签、看高清视频、跑轻量级的 Qt 或 GTK 应用、做界面预览、跑一些对帧率不敏感的可视化脚本、教学演示。不够用的场景三维建模的实时预览拖个模型就掉到个位数帧、游戏、视频剪辑的时间线预览、任何需要 CUDA 或 OpenCL 的任务、任何需要 GPU 硬件编解码的任务。实操心得有个细节很多人不知道虚拟机窗口的尺寸会直接影响渲染性能。客户机分辨率和虚拟机窗口尺寸不匹配时MKS 需要做一次额外的缩放这一层缩放是纯 CPU 干的帧率会掉得很明显。把客户机分辨率设成和窗口大小一致或者反过来让窗口自动适应能省下不少性能。另外提一句开启 3D 加速之后如果发现客户机启动变慢或者宿主机 CPU 占用异常可以先把svga.vramSize往回调小一档试试显存分配过大在某些宿主机上会触发内存压缩反而拖慢整体。3. 方案二PCIe 直通把整块显卡交给 Ubuntu如果你读到这一章说明你的需求是第三层——要 CUDA、要真显存、要原厂驱动。那么第一句话必须说清楚VMware Workstation 做不到这件事。它的产品定位是桌面级虚拟化图形部分只提供命令转发的虚拟显卡没有实现 PCIe 设备的直接分配。网上有些文章会提到“VMDirectPath”这个词那是 ESXi 的功能而且需要在 BIOS 里开启 VT-d、在 ESXi 的“管理 硬件 PCI 设备”里勾选直通跟 Workstation 是两个产品线。Workstation 的虚拟机设置里翻遍也找不到直通选项不是版本问题是没这个功能。所以要实现真正的直通路线是换平台。工程上用得多的是 KVM/QEMU 配合 VFIO 框架成熟、文档多、可控性强如果偏好图形化界面基于同一套内核能力的虚拟化管理平台也可以本质一样。下面按 KVM 这条线讲因为它最能说明每一层发生了什么。3.1 更换平台前的硬件与固件检查清单这一步跳过了后面一定会在某个莫名其妙的地方卡住。我把检查项整理成清单一条条过。CPU 虚拟化与 IOMMU 支持。Intel 平台需要 VT-x 加 VT-dAMD 平台需要 AMD-V 加 AMD-Vi。查一下lscpu | grep -i -E virtualization|vt-d|iommu输出里有VT-x或AMD-V说明基础虚拟化有但 VT-d/IOMMU 不一定会在这里显示更可靠的是查主板手册或者看 BIOS 里有没有对应开关。BIOS/UEFI 设置。需要打开三个东西虚拟化技术Intel VT-x / SVM Mode、I/O 虚拟化Intel VT-d / IOMMU、Above 4G Decoding。第三项很多人漏掉它决定了系统能不能给 PCIe 设备分配 64 位地址空间不打开的话大显存的卡16G 以上直通时容易出问题。显卡数量。这是最硬的门槛。直通之后这块卡就归虚拟机独占了宿主机完全用不了它。所以宿主机必须还有另一块显卡负责输出画面——可以是 CPU 核显也可以是一块便宜的亮机卡。如果只有一块独显那就变成“单卡直通”需要在启动时决定把卡给谁配置复杂度和翻车率都高一个档次。IOMMU 分组。这个后面单独讲但先说结论理想情况下目标显卡和它的音频功能单独成组组的边界干净。如果不干净就得考虑 ACS 覆盖补丁而那个补丁有安全代价。电源和散热。直通状态下 GPU 长时间高负载机箱风道和电源余量要留够。听起来像废话但我确实见过因为电源功率不足导致直通后跑满载就重启的情况。3.2 IOMMU 分组直通成败的关键IOMMU 分组是直通里最容易出问题的一环。简单说IOMMU 把 PCIe 设备按“能不能被独立隔离”分成若干组直通的最小单位是组不是设备。也就是说你要直通的那块显卡所在的组里所有设备必须一起交给虚拟机否则内核会拒绝。查看分组的脚本#!/bin/bash shopt -s nullglob for g in /sys/kernel/iommu_groups/*; do echo IOMMU Group ${g##*/}: for d in $g/devices/*; do echo -e \t$(lspci -nns ${d##*/}) done done把输出保存下来慢慢看。理想的结果是这样的IOMMU Group 14: 01:00.0 VGA compatible controller [0300]: ... 01:00.1 Audio device [0403]: ...显卡和它的 HDMI 音频功能在一个组里组里没有别的东西。这是最干净的形态。不理想的情况是显卡和一堆 PCIe 桥、网卡、SATA 控制器挤在一个组里原因通常是主板 PCIe 插槽的 ACS访问控制服务能力不足或者芯片组的拓扑结构限制了隔离粒度。这时候有几个应对思路第一换插槽。不同插槽挂在不同 PCIe 根端口下分组结果可能完全不同。把显卡从 CPU 直连的插槽换到芯片组提供的插槽或者反过来都值得试一次。这是成本最低的办法。第二BIOS 里找 ACS 相关选项。部分主板有“PCIe ACS Override”之类的开关打开能改善分组但这属于厂商自行实现的功能效果因板而异。第三ACS 覆盖补丁。内核提供pcie_acs_override参数可以强行把设备拆成独立组。代价是破坏了设备间的隔离性理论上存在 DMA 攻击面扩大的风险家庭实验室自己用问题不大生产环境慎用。第四接受现实换硬件。如果主板的分组实在很难看换一块支持更好的板子往往比折腾一周更省事。注意判断分组好坏有个经验法则——如果显卡所在组里的设备数量超过 3 个就要警惕了。组里每多一个设备直通时需要一起绑定的东西就多一份而其中任何一个设备比如你的系统盘控制器都不太可能被交出去。3.3 内核参数与 vfio-pci 绑定分组干净之后进入配置阶段。整体思路是让内核启动时就开启 IOMMU然后在显卡驱动加载之前把目标设备抢过来绑定到vfio-pci这样宿主机就再也不会去碰它。第一步改 GRUB 内核参数sudo nano /etc/default/grub找到GRUB_CMDLINE_LINUX_DEFAULTIntel 平台改成GRUB_CMDLINE_LINUX_DEFAULTquiet splash intel_iommuon iommuptAMD 平台改成GRUB_CMDLINE_LINUX_DEFAULTquiet splash amd_iommuon iommuptiommupt的意思是“只对需要直通的设备启用 IOMMU 转换”对没有直通的设备走直通模式能减少一点性能开销。改完更新 GRUBsudo update-grub重启后验证 IOMMU 是否真的开了dmesg | grep -i -E DMAR|IOMMU看到DMAR: IOMMU enabled或AMD-Vi: Interrupt remapping enabled之类的输出就对了。如果什么都没看到说明 BIOS 里那个开关没打开回去检查。第二步获取设备的 PCI IDlspci -nn | grep -i vga lspci -nn | grep -i audio输出形如01:00.0 VGA compatible controller [0300]: ... [10de:2489] (rev a1)方括号里的10de:2489就是厂商 ID 加设备 ID。第三步创建绑定配置sudo nano /etc/modprobe.d/vfio.conf内容options vfio-pci ids10de:2489,10de:228b softdep nvidia pre: vfio-pci softdep nouveau pre: vfio-pciids那里填上一步拿到的两个 ID用逗号分隔显卡本体和它的音频功能都要写上不写音频的话虚拟机会出现“有画面但没声音”的诡异状态。softdep两行是关键。它告诉内核在加载nvidia或nouveau驱动之前先加载vfio-pci这样 vfio 会先一步抢到设备原厂驱动再去枚举时就看不到这张卡了自然不会来抢。少了这两行大概率出现设备已经被 nvidia 驱动接管、vfio 绑不上的情况。第四步把 vfio 模块写进 initramfs让它在启动早期就可用echo vfio | sudo tee -a /etc/initramfs-tools/modules echo vfio_iommu_type1 | sudo tee -a /etc/initramfs-tools/modules echo vfio_pci | sudo tee -a /etc/initramfs-tools/modules echo vfio_virqfd | sudo tee -a /etc/initramfs-tools/modules sudo update-initramfs -u -k all第五步重启然后验证绑定结果lspci -nnk -d 10de:看目标设备那一行的Kernel driver in use如果是vfio-pci恭喜绑定成功。如果显示nvidia或nouveau说明softdep没起作用或者 initramfs 没更新干净重新走一遍第四步。3.4 虚拟机侧配置与客户机验证在虚拟化管理工具里给虚拟机添加 PCI 主机设备时本质上是往虚拟机配置里写一段hostdev。手写的话长这样hostdev modesubsystem typepci managedyes source address domain0x0000 bus0x01 slot0x00 function0x0/ /source rom baron/ address typepci domain0x0000 bus0x06 slot0x00 function0x0/ /hostdevsource里填的是宿主机上那张卡的真实总线地址从lspci里读出来的 01:00.0address里填的是它在虚拟机内部被映射到的位置这个可以随便指定一个空闲位置但要在虚拟机的 PCI 拓扑里合法。rom baron/这一行是给显卡暴露 vBIOS ROM 的。有些消费级显卡在直通时因为 vBIOS 不能被正确读取而初始化失败加上这一行通常能解决。如果还是不行可能需要从显卡里 dump 出 vBIOS 文件然后在配置里指定file路径那是另一个层级的操作了。虚拟机配置里还有一个必须注意的点芯片组和固件类型。用 UEFIOVMF固件比传统 BIOS 更容易让现代显卡正常初始化而且在 UEFI 下显卡的 GOP 驱动能正常跑开机画面能出来。如果用传统 BIOS 固件很多新卡直通后会黑屏但系统实际在跑只能靠 SSH 操作。客户机启动后先在lspci里确认真实显卡出现了lspci -nn | grep -i nvidia然后装原厂驱动。Ubuntu 上最省事的是ubuntu-drivers工具sudo ubuntu-drivers devices sudo ubuntu-drivers autoinstall sudo reboot重启后验证nvidia-smi正常输出会列出显卡型号、显存大小、驱动版本、当前温度功耗。这一行输出出现的那一刻说明整条链路彻底打通了。之后装 CUDA Toolkit、装 PyTorch、跑torch.cuda.is_available()都是一路顺风。3.5 性能损耗实测与几个必须知道的代价直通的性能表现是我最常被问到的第二个问题。我在几套配置上跑过对比结论是计算几乎无损图形有轻微损耗延迟略有增加。测试项实体机原生直通虚拟机损耗CUDA 带宽测试100%96%~98%2%~4%矩阵乘法算力100%95%~97%3%~5%图形渲染帧率100%90%~95%5%~10%显存访问延迟100%略高可感知但不明显视频硬编码速度100%接近原生很低计算损耗主要来自 IOMMU 地址转换和中断重映射这部分开销是固定的跟负载大小关系不大所以跑大任务时占比可以忽略。图形损耗除了地址转换还多了一层帧缓冲的搬运所以比计算略高。代价方面有几个必须提前接受宿主机失去这块卡。直通期间宿主机完全用不了它包括跑 CUDA、跑推理、玩游戏。如果宿主机平时也需要用显卡就得在“给虚拟机”和“给宿主”之间做取舍或者配置动态绑定启动虚拟机时解绑、关闭时归还但那又是另一套复杂度。功耗和发热。直通状态下 GPU 无法被宿主机的电源管理降频空闲时也可能保持较高功耗。笔记本上尤其明显风扇会一直转。快照和迁移受限。带直通设备的虚拟机通常不能做内存快照也不能在线迁移到别的宿主机。做实验时要养成关机前保存状态的习惯。内核升级后可能失效。这是最容易被忽略的一条。内核大版本升级后模块加载顺序、initramfs 内容都可能变化出现过重启后vfio-pci没绑上的情况。建议每次内核升级后跑一遍lspci -nnk -d 10de:确认绑定状态。4. 折中路线把宿主机当成 GPU 服务端前两章是两个极端一个是完全虚拟化、性能打折但简单一个是完全直通、性能接近原生但代价大。实际工作中还有第三条路很多人没想到但在我做的项目里用得最多——不把 GPU 交给虚拟机而是把计算任务送到宿主机执行。这个思路的核心是Ubuntu 虚拟机里跑的往往不是“需要 GPU 的完整桌面”而是“需要 GPU 的某个任务”。既然是任务就可以通过网络或进程间通信把它扔出去算完了把结果拿回来。虚拟机只负责编辑代码、跑前端、做数据分析重活全在宿主机上干。4.1 三种落地方式与各自适用场景第一种远程执行命令。最土但最可靠。虚拟机里通过 SSH 连到宿主机把训练脚本、渲染任务提交过去输出文件通过共享目录或者scp拿回来。ssh userhost-ip cd /work/project CUDA_VISIBLE_DEVICES0 python train.py --config cfg.yaml这种方式的好处是零额外组件宿主机上装好驱动和运行环境就行虚拟机里连 CUDA 都不用装。缺点是交互性差调试不方便适合“提交-等待-取结果”的批处理型任务。第二种网络化服务。在宿主机上起一个常驻服务虚拟机作为客户端调用。常见形态有几种Jupyter Notebook 服务端跑在宿主机虚拟机里用浏览器连过去写代码推理服务用 HTTP 或 gRPC 暴露接口虚拟机里当普通 API 调渲染集群用任务队列分发虚拟机只提交任务描述。import requests resp requests.post( http://host-ip:8000/infer, json{prompt: a cat sitting on a keyboard, steps: 30}, timeout120, ) print(resp.json()[image_base64][:64])这种方式的优势是把 GPU 资源变成了“服务”多个虚拟机、多个项目可以共享同一块卡按需排队。代价是要额外维护服务端接口设计要考虑并发和超时。第三种共享内存加本地套接字。如果虚拟机和宿主机之间有共享文件夹或者 VirtIO 的高速通道可以用本地套接字传递数据省掉网络协议栈的开销。这种方式配置最麻烦收益在数据量特别大比如视频帧流的时候才明显一般项目用不上。4.2 三条路线的选择依据判断维度方案一内置 3D 加速方案二PCIe 直通折中GPU 服务端主要用途图形界面、轻量渲染完整 GPU 能力批处理、推理、训练交互体验好好一般调试便利性好好较差多虚拟机共享天然支持不支持天然支持配置成本低高中适合人群办公、教学、演示单机深度学习、图形工作站团队共享、多项目并行我的实际选择逻辑是这样的如果只是想在虚拟机里舒服地用 Ubuntu 桌面走方案一顺手把 3D 加速开了就行如果这台机器就是给某个深度学习项目专用的走方案二一次性投入换长期收益如果是团队环境好几个人要用同一块卡那折中路线才是正解直通反而是浪费。实操心得折中路线上有个细节值得注意——宿主机和虚拟机的文件系统要打通。最省事的做法是虚拟机里挂载宿主机的共享目录代码在宿主机上虚拟机里直接编辑跑的时候在宿主机执行。这样避免了“改了代码忘了同步”这类低级错误。数据量大就用 NFS 或者干脆把数据集放宿主机上虚拟机只读路径。5. 常见问题与排查实录这一章是我这些年被问到最多的问题的汇总按现象归类方便对照排查。5.1 现象速查表现象最可能的原因处理方向glxinfo显示 llvmpipe3D 加速没生效检查 .vmx 的mks.enable3d检查宿主机驱动虚拟机里分辨率上不去svga.maxWidth/Height太小调到目标分辨率以上挂起恢复后黑屏vmotion.checkpointFBSize与显存不一致两项设成相同值开了加速反而更卡虚拟显存分配过大触发内存压缩把svga.vramSize降一档直通后虚拟机启动黑屏vBIOS 未正确暴露配置里加rom baron/或用 UEFI 固件lspci看不到直通卡vfio 绑定失败检查softdep和 initramfsnvidia-smi报驱动未加载客户机没装驱动或装错版本用ubuntu-drivers重装直通后宿主机重启进不去系统显卡被 vfio 抢走后宿主无输出用核显输出或临时移除绑定参数内核升级后直通失效模块顺序变化重新update-initramfs并验证绑定5.2 五个我实际踩过的坑坑一只改了.vmx没关虚拟机。Workstation 在虚拟机运行时会锁定.vmx文件你的修改要么被忽略要么在关机时被覆盖回去。改之前一定完整关机不是挂起。坑二宿主机驱动在黑名单里。这个最隐蔽因为宿主机自己跑得好好的glxinfo也正常就是虚拟机里不加速。加mks.gl.allowBlacklistedDrivers TRUE之后立刻好了。原因是 Workstation 对某些驱动版本有兼容性判断判断失准时会保守地退回软件渲染。坑三直通时只绑了显卡没绑音频。表现是虚拟机里画面正常但aplay -l找不到 HDMI 输出设备。查lspci会发现音频功能还挂在宿主机上。解决办法是把同一组的音频设备 ID 也加进vfio.conf的ids里。坑四Secure Boot 拦住了第三方模块。开启 Secure Boot 的系统上vfio-pci这类模块如果没签名会被拒绝加载dmesg里能看到module verification failed之类的信息。要么在 BIOS 里关掉 Secure Boot要么给模块签名前者简单得多。坑五直通后宿主机功耗飙升。这张卡在宿主机上时会被电源管理降频直通给虚拟机后客户机驱动接管空闲时也保持在较高功耗状态。解决办法是在客户机里配置持久模式或者在不用的时候关掉虚拟机。笔记本用户对这一条体会最深风扇声会明显变大。5.3 一套通用的排查顺序遇到问题别乱试按这个顺序走一遍八成能定位第一步确认需求层次。先搞清楚是图形问题还是计算问题这决定了往哪个方向查。图形问题查 MKS 和 Mesa计算问题查 vfio 和驱动。第二步逐层验证。方案一从宿主机驱动开始到.vmx参数到客户机模块每一层都用命令验证一遍不要凭感觉。方案二从 BIOS 开关开始到内核参数到 IOMMU 分组到 vfio 绑定每一层都有对应的验证命令。第三步看日志而不是猜。dmesg、journalctl -xe、/var/log/vmware/下面的日志信息量比任何猜测都大。我见过太多人凭“应该是驱动问题”这个判断折腾半天结果日志里明明白白写着绑定失败的原因。第四步最小化复现。如果配置改了很多版都失败就退回到最简配置只开mks.enable3d别的参数全删看能不能跑通再一项项加回来。直通也一样先只绑显卡不绑音频跑通了再加。我个人在这些年的操作里最深的体会是虚拟机用 GPU 这件事方向选对比参数调优重要一百倍。想清楚自己要的是哪一层能力再决定花十分钟还是花两天比闷头改配置高效得多。手上这台机器我刚配好直通那阵子为了一个分组问题换了三次插槽最后还是靠换主板解决的——但那是因为我明确知道必须要 CUDA如果你的需求只是桌面流畅一点真没必要走到这一步。 
长河君 · 2026/10/23 3:13:18 · 阅读 1.2k VMware Ubuntu虚拟机GPU使用：3D加速与PCIe直通指南
1. 先把需求拆开你说的“用上 GPU”到底是哪一种虚拟机里跑 Ubuntu想借用宿主机那块显卡这个问题在我这些年接的咨询里出现频率相当高。很多人上手第一步就是打开虚拟机设置找“显卡”选项翻遍了也没看到能指定物理 GPU 的地方于是开始怀疑是不是软件版本不对、是不是少装了什么插件。实际情况是VMware Ubuntu 虚拟机使用宿主机 GPU 资源这件事本身分成两条完全不同的技术路线它们的原理、前提、能达成的效果差得非常远如果不先分清自己要的是哪一种后面所有操作都是白费劲。我一般会让对方先回答一个问题你在 Ubuntu 里到底要干嘛是要跑桌面、看视频不卡还是要开 Blender 做三维建模、跑 OpenGL 渲染还是要跑 PyTorch 训练模型、跑 CUDA 程序这三个诉求对应的方案完全不同甚至可以说第三个诉求在 VMware Workstation 这个平台上根本没有解。把需求分清楚比急着改配置文件重要得多。这篇文章我按“方案一Workstation 内置的虚拟 3D 加速通道”和“方案二PCIe 直通把整块物理卡交给 Ubuntu”两条主线来写中间穿插一条很多人忽略的折中路线。方案一零成本、十分钟能验证适合图形界面和轻量 OpenGL方案二要换虚拟化平台、要折腾内核参数但能拿到接近原生的 CUDA 算力。两条路的坑我都踩过下面会一条条拆。1.1 三个层次显示加速、图形渲染、通用计算我把虚拟机用 GPU 的需求粗分成三层从上往下难度递增能拿到的性能递减。第一层是显示加速。目标只是让 Ubuntu 桌面拖动窗口不撕裂、分辨率能上到 2K、看 4K 视频不掉帧。这一层其实是 CPU 在做光栅化GPU 参与度很低Workstation 自带的虚拟显卡配合open-vm-tools-desktop基本够用很多时候你甚至不需要开 3D 加速。第二层是图形渲染。跑 OpenGL 应用、跑 glmark2、跑轻量级的 CAD 查看器、跑一些基于 Qt 的图形程序。这一层必须打开 Workstation 的 3D 加速让客户机里的 Mesa 通过vmwgfx驱动把 OpenGL 指令转发到宿主机由宿主机真实的 GPU 完成渲染再回传画面。这条路能跑通但性能是打折的而且有明确的版本上限。第三层是通用计算。CUDA、OpenCL、ROCm、TensorFlow、PyTorch、视频硬编码NVENC、大模型推理。这一层的关键不是“画面”而是显存和计算单元的直接访问虚拟显卡完全无能为力必须走 PCIe 直通让 Ubuntu 看到一张货真价实的物理显卡装原厂驱动。提示判断自己在哪一层最简单的办法是想一下“这个程序需不需要知道显卡型号”。nvidia-smi能看到卡就是第三层只有glxinfo能看到渲染器名字那是第二层连glxinfo都显示软件渲染那就是第一层。我见过太多人想用方案一去跑 CUDA折腾两天最后一查nvidia-smi报“command not found”才意识到方向从一开始就错了。所以下面这张表建议先看一遍再决定往下读哪一章。需求层次典型场景VMware Workstation 能否满足推荐路线显示加速桌面流畅、多显示器、高清视频能原生支持装 open-vm-tools-desktop 即可图形渲染OpenGL 应用、轻量建模、界面预览能但有性能损耗和版本天花板方案一通用计算CUDA、PyTorch、视频编码、推理不能方案二混合场景一边建模一边渲染部分能需要权衡方案一 折中路线1.2 为什么虚拟机里永远看不到真实的显卡型号Workstation 给虚拟机提供的显卡是一块虚拟设备PCI 标识是 VMware 自己的厂商 ID客户机里的lspci看到的是一行SVGA II Adapter。这块虚拟卡的作用是接管客户机的显示输出把帧缓冲通过共享内存交给宿主机上的 MKS鼠标键盘屏幕进程去合成。开了 3D 加速之后虚拟卡会多出一条通路客户机里 Mesa 的svga驱动把 OpenGL 命令序列化通过 VMCI 或共享内存送到宿主机宿主机的 MKS 用本机真实的 OpenGL 驱动也就是你装的显卡驱动去执行渲染结果再作为帧数据回传。所以你在 Ubuntu 里glxinfo看到的渲染器名字是SVGA3D开头而不是GeForce或Radeon。这个设计的本质是命令转发不是设备透传。宿主机 GPU 确实参与了工作但客户机全程不知道它的存在拿不到显存地址装不了原厂驱动自然也跑不了 CUDA。理解这一点后面所有的行为就都能解释了为什么帧率上不去、为什么某些 OpenGL 扩展不支持、为什么nvidia-smi找不到设备。还有一层容易被忽略这条转发链路上的每一环都可能成为瓶颈。宿主机的 OpenGL 驱动版本、MKS 的编译选项、客户机 Mesa 的版本、虚拟显存的大小、甚至宿主机的电源管理策略独显被降频都会影响最终表现。这也是为什么同样配置的两台机器一个人跑 glmark2 能到 2000 分另一个人只有 800 分。1.3 两条路线的全景对比在动手之前先把两条路线的代价摆清楚避免做到一半发现方向不对。对比项方案一内置 3D 加速方案二PCIe 直通虚拟化平台VMware Workstation ProKVM/QEMU VFIO 或 ESXi硬件要求无特殊要求CPU 支持 VT-d/AMD-Vi主板支持 IOMMU显卡要求任意需要至少两块显卡一块给宿主输出客户机看到的设备SVGA II 虚拟显卡真实物理显卡能否装原厂驱动不能能CUDA 支持不支持完整支持OpenGL 上限受转发链路限制通常到 4.x 级别与原生一致性能损耗图形 40%~70%计算不可用图形 5%~10%计算 3%~5%配置耗时10 分钟半天到两天主要风险几乎无分组不理想、单卡直通失败、vBIOS 问题这张表最需要关注的是“显卡要求”和“配置耗时”两行。方案二看起来香但它有个硬前提宿主机得有一块能独立输出画面的显卡。如果你的机器只有一块独显又想让这块独显直通给 Ubuntu那么在直通生效期间宿主机是没有画面的后面的操作全靠 SSH。这种“单卡直通”不是不能做但对新手极不友好。我的建议比较直接如果需求停在第二层老老实实用方案一把时间省下来干正事如果明确要跑 CUDA那就别在 Workstation 上耗了直接上方案二Workstation 在这件事上帮不了你。2. 方案一把 Workstation 的 3D 加速通道真正打开这一章是给那些“只是想跑个图形程序”“想看看 Ubuntu 桌面能不能顺滑一点”的人准备的。整个流程加起来不超过半小时绝大多数失败案例的原因都可以归结为三个字没生效。配置看起来都改了glxinfo一跑还是软件渲染。我先把结论放前面方案一要生效需要宿主机驱动正常 .vmx 参数正确 客户机驱动栈完整三个条件同时满足缺一不可。下面按这三个条件依次拆。2.1 宿主机侧的准备与自检宿主机这一侧的准备工作经常被跳过但它是整条链路的地基。MKS 最终是用宿主机的 OpenGL 驱动去执行渲染的如果宿主机自己都没装好显卡驱动虚拟机里再折腾也没用。先确认宿主机显卡驱动状态。Windows 宿主机打开设备管理器看显示适配器下面有没有黄色感叹号右键属性看驱动版本顺手跑一下dxdiag在“显示”标签页确认 DirectX 功能级别正常。Linux 宿主机用glxinfo -B看渲染器是不是独显名字如果显示llvmpipe说明走的是软件渲染得先把驱动装好。第二件事是确认 Workstation 版本。3D 加速的能力上限跟版本强相关较新的版本对 OpenGL 4.x 级别和 DirectX 11 级别的虚拟图形支持更完整老版本可能只到 OpenGL 3.3。虚拟机的硬件兼容性版本也要跟着提上去在虚拟机设置里把“兼容性”调到当前 Workstation 支持的最高档否则新特性会被硬件版本卡住。第三件事是宿主机电源管理。笔记本上这一点特别明显独显被系统判定为空闲后会自动降频甚至断电虚拟机里的渲染请求过去时 GPU 还在“醒神”表现出来就是前几秒卡顿、后面才正常。可以的话把宿主机电源计划切成高性能或者把 Workstation 进程加到显卡控制面板的“高性能”列表里。注意宿主机如果有双显卡核显 独显要确认 Workstation 用的是哪一块。Windows 上可以在“图形设置”里给vmware.exe指定“高性能”不然默认可能被分配到核显性能差一大截。2.2 .vmx 关键参数逐条拆解Workstation 的图形相关配置在虚拟机设置界面只能勾一个“加速 3D 图形”剩下的大量参数藏在.vmx文件里。这个文件在虚拟机的存放目录下用文本编辑器打开就能改改之前先把虚拟机关机——运行中改会被覆盖。下面这组是我目前用得最稳的配置逐条说明mks.enable3d TRUE mks.enableGLES TRUE mks.gl.allowBlacklistedDrivers TRUE svga.autodetect FALSE svga.vramSize 536870912 svga.maxWidth 3840 svga.maxHeight 2160 vmotion.checkpointFBSize 536870912 mks.maxRefreshRate 60mks.enable3d是总开关等价于界面上的“加速 3D 图形”勾选框必须为 TRUE。这一项如果为 FALSE后面所有参数都没意义。mks.enableGLES打开 OpenGL ES 通路。有些图形栈尤其是基于 Qt 或 Wayland 的现代应用走的是 GLES 而不是桌面 OpenGL不开这一项可能会出现窗口黑屏、界面渲染异常。mks.gl.allowBlacklistedDrivers是应急开关。Workstation 内部维护了一份宿主驱动黑名单某些版本的驱动会被判定为“不兼容”而强制退回软件渲染。如果你确认宿主机驱动工作正常、glxinfo也没问题但虚拟机里就是不加速把这个设成 TRUE 大概率能解决。svga.autodetect设为 FALSE 是为了让下面的显存和分辨率参数生效。设为 TRUE 时 Workstation 会自动决定显存大小通常是 128MB 或 256MB跑高分辨率或者多显示器会不够。svga.vramSize是虚拟显存单位是字节。536870912就是 512MB。这个值不是越大越好超过一定范围对性能没有帮助反而会占用宿主机内存。我一般按分辨率给1080p 给 256MB4K 或多显示器给 512MB 到 1GB。如果客户机里要开比较大的纹理或者多窗口并行渲染可以再往上调一档。svga.maxWidth和svga.maxHeight是虚拟显示的最大分辨率。这两个值如果你不改虚拟机里设置分辨率时会发现超过某个值就被截断了。4K 场景下设成 3840×2160超宽屏可以设 5120×1440。vmotion.checkpointFBSize这个参数名字很误导它跟迁移没关系实际控制的是快照和挂起时保留的帧缓冲大小。必须和svga.vramSize保持一致否则虚拟机挂起再恢复可能黑屏。这个坑我踩过一次排查了半天才发现是这两项对不上。mks.maxRefreshRate限制客户机的刷新率上限。默认值在某些高刷屏上会导致 CPU 占用异常设成 60 是比较保守稳妥的做法追求高刷可以设 120 试试。改完之后保存启动虚拟机进系统验证。2.3 Ubuntu 客户机驱动栈与验证方法客户机侧最常犯的错误是只装了open-vm-tools没装open-vm-tools-desktop。前者是基础服务后者才包含图形相关的组件包括分辨率自适应、剪贴板共享、3D 加速的客户机侧支持。sudo apt update sudo apt install -y open-vm-tools open-vm-tools-desktop mesa-utilsmesa-utils里包含glxinfo和glxgears是验证的核心工具。装完重启一次让vmwgfx内核模块重新加载。重启后先确认内核模块lsmod | grep vmwgfx有输出说明模块加载正常。如果为空检查是不是把nomodeset加到内核参数里了——这个参数会禁用内核态显卡驱动vmwgfx起不来3D 加速必然失效。然后验证 OpenGLglxinfo -B重点看三行OpenGL renderer string正常应该是SVGA3D开头的字符串例如SVGA3D; build: RELEASE; LLVM;。如果显示llvmpipe (LLVM xx.x, 256 bits)说明走的是 CPU 软件渲染3D 加速没生效。OpenGL version string这里能看到客户机支持的 OpenGL 版本上限通常和虚拟硬件版本、Mesa 版本有关。Device显示的是虚拟显卡标识。如果是 Wayland 会话glxinfo可能会连到 XWayland 上读出来的信息不一定准。先确认会话类型echo $XDG_SESSION_TYPE如果是wayland而glxinfo结果异常可以注销后在登录界面右下角的齿轮里切回Ubuntu on Xorg再测。Xorg 会话下glxinfo的结果更能反映真实状态。想更直观地看性能装一个glmark2sudo apt install -y glmark2 glmark2跑完会给出一个总分。这个分数不用跟网上的数据比因为差异太大它的价值在于你自己机器的前后对比改参数前跑一次改完再跑一次看有没有提升。2.4 实测表现与能力边界我在一台配备中端独显的机器上做过一组对比宿主机是 WindowsWorkstation 版本较新Ubuntu 22.04 客户机配置 4 核 8G 内存。同一套glmark2结果大致如下配置状态glmark2 总分glxinfo 渲染器CPU 占用未开 3D 加速约 300llvmpipe极高跑分时占满两核开 3D 加速显存 256MB约 1500SVGA3D中等开 3D 加速显存 512MB4K 上限约 1800SVGA3D中等同硬件实体机原生约 8000独显型号低这组数据里最值得注意的是最后一行的对比。即便配置调到最优虚拟机的图形性能也只有实体机的两成出头。这个差距不是配置问题是转发架构本身的代价——每一条 OpenGL 命令都要序列化、跨虚拟机边界传输、在宿主机上重放链路越长损耗越大。所以方案一的适用边界很清晰够用的场景Ubuntu 桌面日常操作、浏览器多标签、看高清视频、跑轻量级的 Qt 或 GTK 应用、做界面预览、跑一些对帧率不敏感的可视化脚本、教学演示。不够用的场景三维建模的实时预览拖个模型就掉到个位数帧、游戏、视频剪辑的时间线预览、任何需要 CUDA 或 OpenCL 的任务、任何需要 GPU 硬件编解码的任务。实操心得有个细节很多人不知道虚拟机窗口的尺寸会直接影响渲染性能。客户机分辨率和虚拟机窗口尺寸不匹配时MKS 需要做一次额外的缩放这一层缩放是纯 CPU 干的帧率会掉得很明显。把客户机分辨率设成和窗口大小一致或者反过来让窗口自动适应能省下不少性能。另外提一句开启 3D 加速之后如果发现客户机启动变慢或者宿主机 CPU 占用异常可以先把svga.vramSize往回调小一档试试显存分配过大在某些宿主机上会触发内存压缩反而拖慢整体。3. 方案二PCIe 直通把整块显卡交给 Ubuntu如果你读到这一章说明你的需求是第三层——要 CUDA、要真显存、要原厂驱动。那么第一句话必须说清楚VMware Workstation 做不到这件事。它的产品定位是桌面级虚拟化图形部分只提供命令转发的虚拟显卡没有实现 PCIe 设备的直接分配。网上有些文章会提到“VMDirectPath”这个词那是 ESXi 的功能而且需要在 BIOS 里开启 VT-d、在 ESXi 的“管理 硬件 PCI 设备”里勾选直通跟 Workstation 是两个产品线。Workstation 的虚拟机设置里翻遍也找不到直通选项不是版本问题是没这个功能。所以要实现真正的直通路线是换平台。工程上用得多的是 KVM/QEMU 配合 VFIO 框架成熟、文档多、可控性强如果偏好图形化界面基于同一套内核能力的虚拟化管理平台也可以本质一样。下面按 KVM 这条线讲因为它最能说明每一层发生了什么。3.1 更换平台前的硬件与固件检查清单这一步跳过了后面一定会在某个莫名其妙的地方卡住。我把检查项整理成清单一条条过。CPU 虚拟化与 IOMMU 支持。Intel 平台需要 VT-x 加 VT-dAMD 平台需要 AMD-V 加 AMD-Vi。查一下lscpu | grep -i -E virtualization|vt-d|iommu输出里有VT-x或AMD-V说明基础虚拟化有但 VT-d/IOMMU 不一定会在这里显示更可靠的是查主板手册或者看 BIOS 里有没有对应开关。BIOS/UEFI 设置。需要打开三个东西虚拟化技术Intel VT-x / SVM Mode、I/O 虚拟化Intel VT-d / IOMMU、Above 4G Decoding。第三项很多人漏掉它决定了系统能不能给 PCIe 设备分配 64 位地址空间不打开的话大显存的卡16G 以上直通时容易出问题。显卡数量。这是最硬的门槛。直通之后这块卡就归虚拟机独占了宿主机完全用不了它。所以宿主机必须还有另一块显卡负责输出画面——可以是 CPU 核显也可以是一块便宜的亮机卡。如果只有一块独显那就变成“单卡直通”需要在启动时决定把卡给谁配置复杂度和翻车率都高一个档次。IOMMU 分组。这个后面单独讲但先说结论理想情况下目标显卡和它的音频功能单独成组组的边界干净。如果不干净就得考虑 ACS 覆盖补丁而那个补丁有安全代价。电源和散热。直通状态下 GPU 长时间高负载机箱风道和电源余量要留够。听起来像废话但我确实见过因为电源功率不足导致直通后跑满载就重启的情况。3.2 IOMMU 分组直通成败的关键IOMMU 分组是直通里最容易出问题的一环。简单说IOMMU 把 PCIe 设备按“能不能被独立隔离”分成若干组直通的最小单位是组不是设备。也就是说你要直通的那块显卡所在的组里所有设备必须一起交给虚拟机否则内核会拒绝。查看分组的脚本#!/bin/bash shopt -s nullglob for g in /sys/kernel/iommu_groups/*; do echo IOMMU Group ${g##*/}: for d in $g/devices/*; do echo -e \t$(lspci -nns ${d##*/}) done done把输出保存下来慢慢看。理想的结果是这样的IOMMU Group 14: 01:00.0 VGA compatible controller [0300]: ... 01:00.1 Audio device [0403]: ...显卡和它的 HDMI 音频功能在一个组里组里没有别的东西。这是最干净的形态。不理想的情况是显卡和一堆 PCIe 桥、网卡、SATA 控制器挤在一个组里原因通常是主板 PCIe 插槽的 ACS访问控制服务能力不足或者芯片组的拓扑结构限制了隔离粒度。这时候有几个应对思路第一换插槽。不同插槽挂在不同 PCIe 根端口下分组结果可能完全不同。把显卡从 CPU 直连的插槽换到芯片组提供的插槽或者反过来都值得试一次。这是成本最低的办法。第二BIOS 里找 ACS 相关选项。部分主板有“PCIe ACS Override”之类的开关打开能改善分组但这属于厂商自行实现的功能效果因板而异。第三ACS 覆盖补丁。内核提供pcie_acs_override参数可以强行把设备拆成独立组。代价是破坏了设备间的隔离性理论上存在 DMA 攻击面扩大的风险家庭实验室自己用问题不大生产环境慎用。第四接受现实换硬件。如果主板的分组实在很难看换一块支持更好的板子往往比折腾一周更省事。注意判断分组好坏有个经验法则——如果显卡所在组里的设备数量超过 3 个就要警惕了。组里每多一个设备直通时需要一起绑定的东西就多一份而其中任何一个设备比如你的系统盘控制器都不太可能被交出去。3.3 内核参数与 vfio-pci 绑定分组干净之后进入配置阶段。整体思路是让内核启动时就开启 IOMMU然后在显卡驱动加载之前把目标设备抢过来绑定到vfio-pci这样宿主机就再也不会去碰它。第一步改 GRUB 内核参数sudo nano /etc/default/grub找到GRUB_CMDLINE_LINUX_DEFAULTIntel 平台改成GRUB_CMDLINE_LINUX_DEFAULTquiet splash intel_iommuon iommuptAMD 平台改成GRUB_CMDLINE_LINUX_DEFAULTquiet splash amd_iommuon iommuptiommupt的意思是“只对需要直通的设备启用 IOMMU 转换”对没有直通的设备走直通模式能减少一点性能开销。改完更新 GRUBsudo update-grub重启后验证 IOMMU 是否真的开了dmesg | grep -i -E DMAR|IOMMU看到DMAR: IOMMU enabled或AMD-Vi: Interrupt remapping enabled之类的输出就对了。如果什么都没看到说明 BIOS 里那个开关没打开回去检查。第二步获取设备的 PCI IDlspci -nn | grep -i vga lspci -nn | grep -i audio输出形如01:00.0 VGA compatible controller [0300]: ... [10de:2489] (rev a1)方括号里的10de:2489就是厂商 ID 加设备 ID。第三步创建绑定配置sudo nano /etc/modprobe.d/vfio.conf内容options vfio-pci ids10de:2489,10de:228b softdep nvidia pre: vfio-pci softdep nouveau pre: vfio-pciids那里填上一步拿到的两个 ID用逗号分隔显卡本体和它的音频功能都要写上不写音频的话虚拟机会出现“有画面但没声音”的诡异状态。softdep两行是关键。它告诉内核在加载nvidia或nouveau驱动之前先加载vfio-pci这样 vfio 会先一步抢到设备原厂驱动再去枚举时就看不到这张卡了自然不会来抢。少了这两行大概率出现设备已经被 nvidia 驱动接管、vfio 绑不上的情况。第四步把 vfio 模块写进 initramfs让它在启动早期就可用echo vfio | sudo tee -a /etc/initramfs-tools/modules echo vfio_iommu_type1 | sudo tee -a /etc/initramfs-tools/modules echo vfio_pci | sudo tee -a /etc/initramfs-tools/modules echo vfio_virqfd | sudo tee -a /etc/initramfs-tools/modules sudo update-initramfs -u -k all第五步重启然后验证绑定结果lspci -nnk -d 10de:看目标设备那一行的Kernel driver in use如果是vfio-pci恭喜绑定成功。如果显示nvidia或nouveau说明softdep没起作用或者 initramfs 没更新干净重新走一遍第四步。3.4 虚拟机侧配置与客户机验证在虚拟化管理工具里给虚拟机添加 PCI 主机设备时本质上是往虚拟机配置里写一段hostdev。手写的话长这样hostdev modesubsystem typepci managedyes source address domain0x0000 bus0x01 slot0x00 function0x0/ /source rom baron/ address typepci domain0x0000 bus0x06 slot0x00 function0x0/ /hostdevsource里填的是宿主机上那张卡的真实总线地址从lspci里读出来的 01:00.0address里填的是它在虚拟机内部被映射到的位置这个可以随便指定一个空闲位置但要在虚拟机的 PCI 拓扑里合法。rom baron/这一行是给显卡暴露 vBIOS ROM 的。有些消费级显卡在直通时因为 vBIOS 不能被正确读取而初始化失败加上这一行通常能解决。如果还是不行可能需要从显卡里 dump 出 vBIOS 文件然后在配置里指定file路径那是另一个层级的操作了。虚拟机配置里还有一个必须注意的点芯片组和固件类型。用 UEFIOVMF固件比传统 BIOS 更容易让现代显卡正常初始化而且在 UEFI 下显卡的 GOP 驱动能正常跑开机画面能出来。如果用传统 BIOS 固件很多新卡直通后会黑屏但系统实际在跑只能靠 SSH 操作。客户机启动后先在lspci里确认真实显卡出现了lspci -nn | grep -i nvidia然后装原厂驱动。Ubuntu 上最省事的是ubuntu-drivers工具sudo ubuntu-drivers devices sudo ubuntu-drivers autoinstall sudo reboot重启后验证nvidia-smi正常输出会列出显卡型号、显存大小、驱动版本、当前温度功耗。这一行输出出现的那一刻说明整条链路彻底打通了。之后装 CUDA Toolkit、装 PyTorch、跑torch.cuda.is_available()都是一路顺风。3.5 性能损耗实测与几个必须知道的代价直通的性能表现是我最常被问到的第二个问题。我在几套配置上跑过对比结论是计算几乎无损图形有轻微损耗延迟略有增加。测试项实体机原生直通虚拟机损耗CUDA 带宽测试100%96%~98%2%~4%矩阵乘法算力100%95%~97%3%~5%图形渲染帧率100%90%~95%5%~10%显存访问延迟100%略高可感知但不明显视频硬编码速度100%接近原生很低计算损耗主要来自 IOMMU 地址转换和中断重映射这部分开销是固定的跟负载大小关系不大所以跑大任务时占比可以忽略。图形损耗除了地址转换还多了一层帧缓冲的搬运所以比计算略高。代价方面有几个必须提前接受宿主机失去这块卡。直通期间宿主机完全用不了它包括跑 CUDA、跑推理、玩游戏。如果宿主机平时也需要用显卡就得在“给虚拟机”和“给宿主”之间做取舍或者配置动态绑定启动虚拟机时解绑、关闭时归还但那又是另一套复杂度。功耗和发热。直通状态下 GPU 无法被宿主机的电源管理降频空闲时也可能保持较高功耗。笔记本上尤其明显风扇会一直转。快照和迁移受限。带直通设备的虚拟机通常不能做内存快照也不能在线迁移到别的宿主机。做实验时要养成关机前保存状态的习惯。内核升级后可能失效。这是最容易被忽略的一条。内核大版本升级后模块加载顺序、initramfs 内容都可能变化出现过重启后vfio-pci没绑上的情况。建议每次内核升级后跑一遍lspci -nnk -d 10de:确认绑定状态。4. 折中路线把宿主机当成 GPU 服务端前两章是两个极端一个是完全虚拟化、性能打折但简单一个是完全直通、性能接近原生但代价大。实际工作中还有第三条路很多人没想到但在我做的项目里用得最多——不把 GPU 交给虚拟机而是把计算任务送到宿主机执行。这个思路的核心是Ubuntu 虚拟机里跑的往往不是“需要 GPU 的完整桌面”而是“需要 GPU 的某个任务”。既然是任务就可以通过网络或进程间通信把它扔出去算完了把结果拿回来。虚拟机只负责编辑代码、跑前端、做数据分析重活全在宿主机上干。4.1 三种落地方式与各自适用场景第一种远程执行命令。最土但最可靠。虚拟机里通过 SSH 连到宿主机把训练脚本、渲染任务提交过去输出文件通过共享目录或者scp拿回来。ssh userhost-ip cd /work/project CUDA_VISIBLE_DEVICES0 python train.py --config cfg.yaml这种方式的好处是零额外组件宿主机上装好驱动和运行环境就行虚拟机里连 CUDA 都不用装。缺点是交互性差调试不方便适合“提交-等待-取结果”的批处理型任务。第二种网络化服务。在宿主机上起一个常驻服务虚拟机作为客户端调用。常见形态有几种Jupyter Notebook 服务端跑在宿主机虚拟机里用浏览器连过去写代码推理服务用 HTTP 或 gRPC 暴露接口虚拟机里当普通 API 调渲染集群用任务队列分发虚拟机只提交任务描述。import requests resp requests.post( http://host-ip:8000/infer, json{prompt: a cat sitting on a keyboard, steps: 30}, timeout120, ) print(resp.json()[image_base64][:64])这种方式的优势是把 GPU 资源变成了“服务”多个虚拟机、多个项目可以共享同一块卡按需排队。代价是要额外维护服务端接口设计要考虑并发和超时。第三种共享内存加本地套接字。如果虚拟机和宿主机之间有共享文件夹或者 VirtIO 的高速通道可以用本地套接字传递数据省掉网络协议栈的开销。这种方式配置最麻烦收益在数据量特别大比如视频帧流的时候才明显一般项目用不上。4.2 三条路线的选择依据判断维度方案一内置 3D 加速方案二PCIe 直通折中GPU 服务端主要用途图形界面、轻量渲染完整 GPU 能力批处理、推理、训练交互体验好好一般调试便利性好好较差多虚拟机共享天然支持不支持天然支持配置成本低高中适合人群办公、教学、演示单机深度学习、图形工作站团队共享、多项目并行我的实际选择逻辑是这样的如果只是想在虚拟机里舒服地用 Ubuntu 桌面走方案一顺手把 3D 加速开了就行如果这台机器就是给某个深度学习项目专用的走方案二一次性投入换长期收益如果是团队环境好几个人要用同一块卡那折中路线才是正解直通反而是浪费。实操心得折中路线上有个细节值得注意——宿主机和虚拟机的文件系统要打通。最省事的做法是虚拟机里挂载宿主机的共享目录代码在宿主机上虚拟机里直接编辑跑的时候在宿主机执行。这样避免了“改了代码忘了同步”这类低级错误。数据量大就用 NFS 或者干脆把数据集放宿主机上虚拟机只读路径。5. 常见问题与排查实录这一章是我这些年被问到最多的问题的汇总按现象归类方便对照排查。5.1 现象速查表现象最可能的原因处理方向glxinfo显示 llvmpipe3D 加速没生效检查 .vmx 的mks.enable3d检查宿主机驱动虚拟机里分辨率上不去svga.maxWidth/Height太小调到目标分辨率以上挂起恢复后黑屏vmotion.checkpointFBSize与显存不一致两项设成相同值开了加速反而更卡虚拟显存分配过大触发内存压缩把svga.vramSize降一档直通后虚拟机启动黑屏vBIOS 未正确暴露配置里加rom baron/或用 UEFI 固件lspci看不到直通卡vfio 绑定失败检查softdep和 initramfsnvidia-smi报驱动未加载客户机没装驱动或装错版本用ubuntu-drivers重装直通后宿主机重启进不去系统显卡被 vfio 抢走后宿主无输出用核显输出或临时移除绑定参数内核升级后直通失效模块顺序变化重新update-initramfs并验证绑定5.2 五个我实际踩过的坑坑一只改了.vmx没关虚拟机。Workstation 在虚拟机运行时会锁定.vmx文件你的修改要么被忽略要么在关机时被覆盖回去。改之前一定完整关机不是挂起。坑二宿主机驱动在黑名单里。这个最隐蔽因为宿主机自己跑得好好的glxinfo也正常就是虚拟机里不加速。加mks.gl.allowBlacklistedDrivers TRUE之后立刻好了。原因是 Workstation 对某些驱动版本有兼容性判断判断失准时会保守地退回软件渲染。坑三直通时只绑了显卡没绑音频。表现是虚拟机里画面正常但aplay -l找不到 HDMI 输出设备。查lspci会发现音频功能还挂在宿主机上。解决办法是把同一组的音频设备 ID 也加进vfio.conf的ids里。坑四Secure Boot 拦住了第三方模块。开启 Secure Boot 的系统上vfio-pci这类模块如果没签名会被拒绝加载dmesg里能看到module verification failed之类的信息。要么在 BIOS 里关掉 Secure Boot要么给模块签名前者简单得多。坑五直通后宿主机功耗飙升。这张卡在宿主机上时会被电源管理降频直通给虚拟机后客户机驱动接管空闲时也保持在较高功耗状态。解决办法是在客户机里配置持久模式或者在不用的时候关掉虚拟机。笔记本用户对这一条体会最深风扇声会明显变大。5.3 一套通用的排查顺序遇到问题别乱试按这个顺序走一遍八成能定位第一步确认需求层次。先搞清楚是图形问题还是计算问题这决定了往哪个方向查。图形问题查 MKS 和 Mesa计算问题查 vfio 和驱动。第二步逐层验证。方案一从宿主机驱动开始到.vmx参数到客户机模块每一层都用命令验证一遍不要凭感觉。方案二从 BIOS 开关开始到内核参数到 IOMMU 分组到 vfio 绑定每一层都有对应的验证命令。第三步看日志而不是猜。dmesg、journalctl -xe、/var/log/vmware/下面的日志信息量比任何猜测都大。我见过太多人凭“应该是驱动问题”这个判断折腾半天结果日志里明明白白写着绑定失败的原因。第四步最小化复现。如果配置改了很多版都失败就退回到最简配置只开mks.enable3d别的参数全删看能不能跑通再一项项加回来。直通也一样先只绑显卡不绑音频跑通了再加。我个人在这些年的操作里最深的体会是虚拟机用 GPU 这件事方向选对比参数调优重要一百倍。想清楚自己要的是哪一层能力再决定花十分钟还是花两天比闷头改配置高效得多。手上这台机器我刚配好直通那阵子为了一个分组问题换了三次插槽最后还是靠换主板解决的——但那是因为我明确知道必须要 CUDA如果你的需求只是桌面流畅一点真没必要走到这一步。