缘起：一个下拉框，十四个选项
第一次在 PVE 里新建虚拟机，走到「硬件」这一步，会看到一个叫 Display 的下拉框。
点开一看：std、cirrus、vmware、qxl、qxl2、qxl3、qxl4、virtio、virtio-gl、none、serial0……一共十四个。
大部分人的第一反应是：这不就是个"显卡"吗？为什么要给我十四个选择？
于是一个很常见的场景出现了：
- 有人随手选了个
qxl，装完系统发现黑屏，开始怀疑人生；
- 有人选了
virtio，心想"都说 virtio 性能好"，结果 Windows 里找不到显卡驱动；
- 有人听了"GPU 直通要用
none"，设完之后虚拟机怎么都起不来（这个坑我踩过不止一次）；
- 而更多的老手，眼皮都不抬，永远选
std。
这十四个选项背后，其实是 虚拟化发展三十年攒下来的一堆历史包袱与设计取舍。这篇文章就把它们一个一个拆开讲清楚。
先给一句结论：如果你只想记住一件事——给 Windows 虚拟机配显示设备，std 几乎永远是安全答案；而 none 是最危险的那个。
下面说为什么。
一、先看全局：十四个选项，四组来路
PVE 的 vga 参数（也就是 Web UI 里的 Display）完整枚举是这样的：
std | cirrus | vmware
qxl | qxl2 | qxl3 | qxl4
virtio | virtio-gl
none
serial0 | serial1 | serial2 | serial3
默认值：std
按技术路线分四组，来路完全不同：
| 组别 |
成员 |
本质 |
要装驱动吗 |
| ① 传统模拟 |
std、cirrus、vmware |
假装自己是一块真实显卡 |
基本免驱 |
| ② 半虚拟化 |
qxl 系列、virtio、virtio-gl |
按约定的虚拟化协议通信 |
要装 |
| ③ 无显示 |
none |
干脆不创建显示设备 |
— |
| ④ 串口终端 |
serial0-3 |
用文本终端代替图形界面 |
— |
记住这个分组，后面所有选择困难都能归结成一句话：
① 组是为了"能亮"，② 组是为了"更快"，③ 组是为了"让路"，④ 组是为了"不要图形"。
二、第一组：传统模拟（假装是真实显卡）
这一组的思路很朴素：虚拟机里的系统不是不认识硬件吗？那我就造一个它认识的出来。
std —— 十四分之一，但你九成时间都在用它
模拟对象：Bochs / Basic VGA（一块最普通的 VGA 显示卡）
加速能力：无（纯帧缓冲，画面靠 CPU 一个像素一个像素写）
驱动需求：所有操作系统自带，零配执
分辨率：最高 1920x1080+（取决于分配的显存）
多显示器：不支持
std 是 PVE 的默认值，也是绝大多数场景的正确答案。原因有三个：
第一，它免驱。
std 模拟的是一块"标准到不能再标准"的 VGA 设备。Windows 从安装盘阶段就认识它，Linux 内核更是把它当亲儿子。你不需要装任何驱动，装完系统画面就在那里。
第二，它稳。
因为没有加速功能，也就没有复杂的驱动交互——它几乎不会因为驱动版本、系统更新而出问题。这种"笨但可靠"的特性，在服务器场景里比性能更重要。
第三，它兼容一切。
不管你的客户机是 Windows 11、Ubuntu 24.04，还是二十年前的 Windows XP，std 都能亮。
代价呢？
std 没有 3D 加速能力，2D 性能也不算好。所有绘制工作都压在 CPU 上。对服务器、命令行、轻量桌面来说完全够用；但如果你想在虚拟机里跑图形密集型应用，它就成了瓶颈。
一个容易被忽略的连锁效应：因为没有 3D 能力，当虚拟机里同时存在一块真显卡（比如直通的独立显卡）时，Windows 会自动把 3D 渲染任务交给有加速能力的那块卡——这其实是好事。但画面最终要"呈现"到 std 这个主显示设备上，中间多了一次 跨适配器拷贝。
这个机制在串流场景里会变成一个性能陷阱（后文详述）。
补充：std 是哪来的，为什么它是默认
std 模拟的是 Bochs 的 VGA 实现（一块最基础的 VGA 兼容设备）。
Bochs 是 1994 年就开始的 x86 模拟器项目，
它的 VGA 实现后来被 QEMU 采用，成了今天的"标准 VGA"。
为什么它被定为默认值？
① 它是 QEMU 最古老的显示实现 —— 代码最成熟、最稳定
② 免驱 —— 所有操作系统都自带驱动
③ QEMU 2.9 之后，PVE 把默认值从 cirrus 改成了 std
官方原文：除了一些 Windows 版本（XP 及更早）仍用 cirrus
所以"默认 std"不是随手定的，是一次明确的权衡：
兼容性 + 稳定性 > 性能
这也解释了它为什么"平平无奇却处处能用"——
它就是那条最不容易出错的路。
cirrus —— 一块 1996 年的显卡，官方劝你别用
模拟对象：Cirrus Logic GD5446
显存：4 MiB
分辨率上限：约 1280x1024
cirrus 模拟的是 1996 年一块真实存在的显卡。它唯一的优势是"足够老"——老到 Windows 98、Windows XP 的安装盘里自带它的驱动。
但 PVE 官方文档里写得很不客气：
"Using type cirrus is not recommended."（不推荐使用 cirrus）
原因也很直白：4 MiB 显存，分辨率上不去，性能几乎是垫底的。它的存在意义仅仅是"给那些只能用它的老系统留个后路"。
除非你在跑 Windows 98/XP 这类古董系统，否则别碰它。
vmware —— 隔壁家的虚拟显卡，效果还不错
模拟对象：VMware SVGA II
加速能力：有 2D 加速 + 部分 3D
驱动需求：Linux 有开源驱动；Windows 需要装 VMware Tools
这个选项有点意思：PVE 居然内置了"竞争对手家的虚拟显卡"。
它的定位是"比 std 好，但不如 virtio"。有 2D 加速，能在 Linux 桌面上跑得比较舒服。但前提是 你得把驱动装上——Linux 下是 xf86-video-vmware，Windows 下得装 VMware Tools（在 KVM 上装 VMware Tools，听起来就别扭）。
典型用途：从 VMware 迁移过来的虚拟机，或者想给 Linux 桌面加点 2D 加速的场景。日常用不到。
三、第二组：半虚拟化（性能好，但要装驱动）
这一组是另一条技术路线，思路完全不同：
既然双方都知道对面是虚拟机，那就别演了，按我们约定好的协议通信吧。
这就是 半虚拟化（para-virtualization）。它不做硬件模拟，效率高得多，代价是——客户机必须认识这套协议，也就是得装驱动。
qxl / qxl2 / qxl3 / qxl4 —— 为 SPICE 而生的四兄弟
来源：Red Hat 开发，专为 SPICE 显示协议设计
加速能力：有 2D 加速
驱动需求：Linux 自带；Windows 在 virtio-win 驱动包里
多显示器：qxl=1 屏，qxl2=2 屏，qxl3=3 屏，qxl4=4 屏
必须配合：SPICE 显示协议
先说最容易搞混的一点：后面那个数字就是显示器数量。
qxl = 单屏qxl2 = 双屏qxl3 = 三屏qxl4 = 四屏
不需要额外配置，选几就是几屏。PVE 文档里也提到：对 Windows 客户机，可以直接在这里选想要的独立显示器数量。
为什么有四个选项，而不是一个带参数的选项？ 这是历史遗留（QEMU 的参数设计如此），不用纠结。
关键限制：qxl 必须配合 SPICE 使用。
SPICE 是 Red Hat 开发的一套远程桌面协议（相比 VNC 支持音频、剪贴板、多屏、外设重定向）。QXL 显卡就是为它设计的搭档。
如果你用 SPICE 协议连接虚拟机，qxl 系列是正确的选择；如果你用的是普通的 noVNC（PVE 网页里那个默认控制台），选 qxl 可能会遇到画面问题。
典型用途：SPICE 远程桌面的多屏办公场景。
virtio —— 和 virtio 网卡、virtio 磁盘一个家族的
原理：遵循 virtio 规范（半虚拟化设备标准）
加速能力：基础 2D；配合 virgl 可支持 3D
驱动需求：Linux 内核内置 ✅ / Windows 支持有限 ⚠️
多显示器：支持（Linux 客户机可自行添加）
熟悉 PVE 的人对 "virtio" 这个词一定不陌生：
- virtio-net —— 虚拟网卡
- virtio-blk / virtio-scsi —— 虚拟磁盘
- virtio-gpu —— 就是这里的显示设备
它们属于同一个家族，共享同一套设计哲学：不做硬件模拟，用共享内存 + 环形队列高效传输数据。
所以看到 virtio-gpu，你应该立刻想到它的特点：
- ✅ 性能好、CPU 开销低
- ✅ Linux 内核原生支持，装上就有
- ❌ Windows 下驱动不成熟
这条是关键。网卡和磁盘的 virtio 驱动在 Windows 上已经很完善（virtio-win 驱动包），但 virtio-gpu 的 Windows 驱动基本处于不可用状态。所以给 Windows 虚拟机选 virtio 显卡，大概率是一场空。
典型用途：Linux 虚拟机的现代图形方案。
补充：virtio 家族的谱系
提到 virtio，多数人只想到网卡和磁盘。
其实它是一个完整的半虚拟化设备规范家族：
| 设备类型 | virtio 名称 | PVE 里的对应字段 |
| 网卡 | virtio-net | net0: model=virtio |
| SCSI 控制器 | virtio-scsi | scsihw: virtio-scsi-single |
| 块设备 | virtio-blk | （QEMU 层）|
| 显示 | virtio-gpu | vga: virtio |
| 内存气球 | virtio-balloon | balloon |
| 串口 | virtio-serial | （自动）|
| 输入设备 | virtio-input | （自动）|
它们共享同一套实现方式（也是性能好的原因）：
客户机驱动 ←→ 共享内存环形队列（virtqueue）←→ 宿主后端
不做硬件模拟，只传"描述符"（指向数据位置的指针）
→ 少了模拟开销，吞吐高、延迟低
那为什么同样是 virtio，网卡能用、显卡不能用？
· 网卡/磁盘的 Windows 驱动，Red Hat 有专门项目持续维护（virtio-win）
· 显示这块，Windows 生态被微软和三家 GPU 厂商牢牢把持
· 虚拟 GPU 的 Windows 驱动，至今没有成熟方案
→ 所以 virtio-gpu 在 Windows 上基本等于摆设
virtio-gl —— 给 virtio 加上 OpenGL 的翅膀
能力：在 virtio 基础上启用 OpenGL 3D 加速（通过 virglrenderer）
前提：宿主机装好了 virglrenderer，且有可用的 GPU 支持
virtio-gl 是 virtio 的增强版：启用 virgl（virglrenderer）之后，客户机的 3D 指令可以被翻译给宿主机的 GPU 执行。
一句话：不用直通显卡，也能让 Linux 虚拟机跑起 3D 应用。
典型用途：Linux 虚拟机的 3D 场景（轻量游戏、CAD、Blender 预览）。
⚠️ 注意：virtio-gl 与 GPU 直通是互斥的。既然你已经把显卡整块给虚拟机了，就不需要 virgl 再翻译一遍。
四、第三组：none —— 什么都不给（最危险的选项）
none 的含义很干脆：不创建任何虚拟显示设备。
两种正当用法
用法一：GPU 直通场景
当你把一块物理显卡直通给虚拟机，希望它成为虚拟机的主显示设备时，虚拟的显示设备就成了累赘，这时用 none 关掉它。
但这里有个 必须满足的前提——后文详说。
用法二：完全无头服务器
配合串口控制台（serial0 等），让虚拟机完全不产生图形输出，走纯文本通道。
⚠️ 一个会让你抓狂的陷阱
这个坑我在自己的集群里踩过不止一次，值得单独讲。
场景是这样的：你给虚拟机直通了一块显卡，为了让"显卡成为唯一显示设备"，你把 Display 改成了 none。
虚拟机启动。然后——
现象：
· PVE 网页控制台一片漆黑（没有画面）
· 虚拟机内部似乎没启动（网络不通、SSH 连不上）
· 在宿主机上看 QEMU 进程，CPU 占用 100%，一直不降
· 半小时过去了，还是这个状态
这不是"启动慢"，这是真的卡死了。
为什么会这样？
这里涉及一个很多人没有意识到的分层概念——虚拟机里的"显示设备"其实分两个层次：
【第一层：硬件级显示设备】
QEMU 虚拟出来的、或者直通进来的
特点：虚拟机一上电就存在
职责：BIOS 输出 → 引导过程 → 操作系统内核早期的显示初始化
【第二层：软件级显示设备】
操作系统里的驱动创建的（如各类虚拟显示器驱动）
特点：操作系统启动【之后】才加载
职责：给系统额外提供显示输出
none 关掉的是 第一层。
于是启动流程变成这样：
t=0.0s QEMU 启动，固件扫描显示设备
→ 虚拟显卡没了，直通卡又不是"主显示"
→ 可用的显示设备数 = 0 ⚠️
t=1s+ 操作系统开始引导
→ 内核初始化图形子系统
→ 枚举显示适配器 → 找不到可用的
→ 卡死在这里（CPU 满载空转）
永远走不到 ↓
t=?s 加载驱动 —— 这时"软件级虚拟显示器"才会出现
→ 但系统根本走不到这一步
打个比方：
这就像你想用手机导航开车，但车打不着火。
· 硬件级显示设备 = 让车能打火
· 软件级虚拟显示器 = 手机导航（车动起来才有用）
你拆了打火系统 → 导航再准也白搭。
所以结论是：
用了 none，就必须确保直通的显卡能独立完成显示输出。
而显卡要能输出，通常需要一个"显示器"——哪怕是假的。
具体的解决手段（比如 HDMI 欺骗器）后文再说。
五、第四组：serial0 ～ serial3 —— 用文本看世界
含义：不创建显示设备，把控制台输出重定向到串口
显示形式：纯文本（通过 PVE 网页终端或 SSH 查看）
前提：客户机内要配置串口控制台（如 Linux 加 console=ttyS0）
这一组专门服务一类需求：无头 Linux 服务器。
服务器不需要图形界面，但有时候需要看引导日志、进单用户模式排障。这时候把控制台重定向到串口，通过文本通道就能完成所有操作。
为什么有 4 个（serial0-3）？ 因为一个虚拟机可以配置多个串口设备，PVE 允许你指定把控制台放在哪一个上。日常只用 serial0。
对 Windows 基本无用：Windows 对串口控制台的支持很有限，不用考虑。
六、两个容易被忽略的参数
选完类型，其实还有两个参数可以调：
vga: [type=]<类型>, memory=<4-512>, clipboard=<vnc>
memory=4..512（MiB）
→ 显存大小
→ 官方提示：要用 ≥1280x1024x16 的高分辨率，可能需要加大显存
→ 跑 4K 或多屏时，建议加到 32-64 MiB
→ 设太小会导致高分辨率选项不可用（画面糊、上不去）
clipboard=<vnc>
→ 剪贴板方向（仅 VNC 显示协议）
→ SPICE 的剪贴板是自动添加的，不需要手动设
→ 注意：带 VNC 剪贴板的虚拟机【不支持迁移】（官方明确说明）
memory 这一项经常被忽略，但它是"选对类型却没画面/画面糊"这类问题的常见原因——显卡类型对了，显存不够，高分辨率模式就用不了。
补充：切换类型时的四个注意事项
知道选什么之后，还要知道 怎么换。这里有四个容易翻车的点：
① 必须【停机】，不是重启
vga 属于硬件配置，改了之后 QEMU 需要重建命令行参数
虚拟机运行中改是不生效的（PVE 会提示"需要重启才生效"）
→ 正确做法：qm shutdown/stop → qm set → qm start
② 类型换了，客户机眼里就是"换了块显卡"
Windows 按"设备实例"管理驱动记录
换类型 = 旧设备拔掉、新设备插上
→ 设备管理器里会残留旧设备的记录（带黄色感叹号的那种）
→ 保留着无碍，想清理就在"显示隐藏的设备"里卸载
③ 分辨率和显示设置会重置
Windows 按"适配器实例"保存显示配置
换类型 = 新实例 → 分辨率回到默认值
→ 静态 IP 之类的不受影响，但显示配置要重设
④ 远程连接方式可能失效 ⚠️（最容易踩的）
如果你从 std 换到 qxl：
· 原来用 noVNC（PVE 网页控制台）能看画面
· qxl 是为 SPICE 协议设计的 → noVNC 可能看不到画面
→ 换类型前，先确认你的连接方式支持新类型
→ 保命做法：始终留着宿主机 SSH 通道
（图形界面看不到时，能命令行改回来）
七、为什么 Windows 虚拟机基本上只能选 std
看完十四种类型，你可能会想：那给 Windows 虚拟机选 virtio 或 qxl，性能不是更好吗？
理论上对，现实中很难。原因是一句话：驱动生态。
逐个分析：
· qxl 系列
→ 需要装驱动（在 virtio-win 包里）
→ 还必须用 SPICE 协议连接
→ 装完能跑，但配置链条长，容易翻车
· virtio / virtio-gl
→ Linux 内核原生支持 ✅
→ Windows：virtio-gpu 驱动不成熟，基本不可用 ❌
· vmware
→ 需要装 VMware Tools（在 KVM 上装 VMware Tools 本身就别扭）
· cirrus
→ 免驱，但分辨率低、性能差（官方不推荐）
· std
→ 免驱、稳、兼容一切 ✅
于是形成了一个现实格局：
| 客户机 |
能选的 |
原因 |
| Linux |
几乎随便选 |
内核里各种驱动都有，虚拟化厂商还是 Linux 阵营 |
| Windows |
基本就是 std |
免驱、可靠；其他要么没驱动，要么要装一堆东西 |
这不是 PVE 的缺陷，而是生态差异。 换个角度看：Linux 是自带虚拟化驱动长大的，Windows 不是。
八、选型决策树
理论讲完，给一张能直接用的对照表：
| 场景 |
推荐 |
理由 |
| Windows 通用 |
std |
免驱、稳、兼容性最好 |
| Windows + GPU 直通 |
none + x-vga + EDID |
用直通卡做主显示（前提见下） |
| Windows + 串流 |
std + 虚拟显示器软件 |
保底显示 + 串流捕获源 |
| Windows 98/XP 等老系统 |
cirrus |
老驱动只认它 |
| Linux 桌面（SPICE） |
qxl / qxl2 及以上 |
2D 加速 + 多屏 |
| Linux 桌面（普通 VNC） |
virtio |
性能好、内核自带驱动 |
| Linux 3D（不直通） |
virtio-gl |
OpenGL 加速 |
| Linux 无头服务器 |
serial0 |
串口看日志，零图形开销 |
| Windows 完全无头 |
none + EDID 方案 |
需虚拟显示器或欺骗器兜底 |
如果你只想记三条：
1. Windows → std（除非你做直通）
2. Linux 桌面 → qxl（SPICE）或 virtio（VNC）
3. 无头服务器 → serial0（Linux）/ none + EDID（Windows）
九、一条保命规律
这是全文最该记住的一条，也是我用真金白银（和无数个卡死的虚拟机）换来的：
【规律】
虚拟机里必须始终存在至少一个"系统能识别的主显示设备"：
虚拟显卡(std) ←→ 或 ←→ 直通显卡 + x-vga + EDID
二选一，不能两个都没有
【推论】
删除虚拟显卡（改成 none）的唯一合法前提：
直通显卡已经能独立完成显示输出
（即：接了显示器，或用 HDMI 欺骗器提供 EDID，且已配执 x-vga）
没有这个前提就删 → 必然卡死（CPU 满载、无网络、无画面）
而"软件级虚拟显示器"（各种虚拟显示驱动）救不了这个问题——因为它是操作系统层的，加载时机太晚。这一点非常容易误解，我见过不少人以为"装了虚拟显示器就可以删掉虚拟显卡了"，结果就是一遍遍地踩同一个坑。
动手前的三道检查
改显示配置之前，花 30 秒做完这三项，能避免绝大多数翻车：
① 确认直通显卡有没有 EDID 来源
· 接了物理显示器？ → 有 ✅
· 插了 HDMI 欺骗器？ → 有 ✅
· 都没有？ → 不能删虚拟显卡 ❌
② 确认改崩了还能救回来
· 保留宿主机 SSH 通道
（图形界面看不到时，能命令行改回来）
· 或者先记下当前配置：
qm config <VMID> | grep vga
③ 做个快照（ZFS 存储上是秒级操作）
PVE → VM → 快照 → 拍摄快照
→ 崩了直接回滚，配置和磁盘一起恢复
第 ③ 项特别值得养成习惯：虚拟机折腾本来就该"随便试、随时退"，而快照是虚拟化里最便宜的保险。有快照在手，你就不用每次改配置都提心吊胆。
验证卡死的命令（在宿主机上执行）：
# 看 QEMU 进程的 CPU 占用（99%+ 且持续不降 = 卡死）
ps -o etime,time,%cpu -p $(pgrep -f 'kvm.*<VMID>')
# 看虚拟网线的流量（RX 恒为 0 = 客户机一个包都没发出来）
ip -s link show tap<VMID>i0
这两条命令一发，卡没卡死一目了然，不用进虚拟机也能量出来。
三个常见误解
在结束这一节之前，澄清三个很容易踩的认知误区：
【误解一】"virtio 性能最好，所以给 Windows 选 virtio"
❌ 错：virtio-gpu 的 Windows 驱动不成熟，基本不可用
✅ 正解：Windows 老实用 std；virtio 是给 Linux 准备的
根源：很多人把 virtio 网卡/磁盘的经验（确实好）
直接套到显示设备上，但显示这块的驱动生态完全不同
【误解二】"装了虚拟显示器软件，就可以删掉虚拟显卡了"
❌ 错：虚拟显示器是操作系统层的东西，加载时机在启动之后
✅ 正解：虚拟显卡必须保留（除非直通卡自己有 EDID）
这个误解最危险 —— 它会让你反复卡死，还找不到原因
（我在这上面栽过好几次才想明白）
【误解三】"qxl4 比 qxl 好，数字越大性能越强"
❌ 错：数字是【显示器数量】，不是性能等级
✅ 正解：需要几块屏就选几，单屏用 qxl 就够了
顺带提醒：qxl 系列必须配合 SPICE 协议，
用 noVNC 连接时可能看不到画面
这三个误解有共同点：都是把"另一个场景的正确经验"错位套用过来。虚拟化的坑，十有八九是这个来源。
十、一个真实案例：Windows 虚拟机的串流优化
用我自己的环境举个例子，把上面的知识串起来。
背景：我在 PVE 里跑一台 Windows 虚拟机做游戏串流，显卡直通，用 Sunshine + Moonlight 方案。跑起来之后，帧率只有 20 帧左右，同样的硬件换成另一套配置却能到 60 帧。
排查过程：
① 查配置差异
跑得好的那套：vga: none + hostpci0: x-vga=1（显卡独占显示）
跑得差的这套：vga: std + hostpci0: pcie=1（虚拟显卡做主显示）
② 想照搬配置（改成 none + x-vga）
→ 虚拟机卡死（CPU 100%、网络不通）
③ 为什么？
直通的那块显卡没有接物理显示器 → 拿不到 EDID
→ 显卡无法独立完成显示输出
→ 去掉虚拟显卡后，虚拟机里一个显示设备都没有 → 卡死在引导阶段
④ 结论
要让这套配置也能工作，必须先给显卡提供 EDID（HDMI 欺骗器）
这个案例里的三个知识点，正好对应本文的三节：
· std 没有 3D 加速 → 渲染会走独显，但画面要"拷贝"回 std
→ 跨适配器拷贝带来性能损失（这是 20 帧的部分原因）
· none 的危险性 → 主显示设备不能缺（第 4 节的陷阱）
· 驱动生态 → Windows 只能 std，所以必须在"保底显示"的前提下找优化方案
最终的优化方向有两条：
路线 A（软件方案）：
保留 std 做保底显示
+ 用虚拟显示器软件创建一个"显示输出"
+ 把它设为主显示，让虚拟显卡"闲置"
→ 零成本，但效果取决于软件实现
路线 B（硬件方案）：
给直通显卡插一个 HDMI 欺骗器（十几块钱的小东西）
→ 显卡拿到 EDID，能独立输出
→ 然后配置 none + x-vga
→ 显示路径全程走独显，没有跨适配器拷贝
→ 这是跑 60 帧那套配置的做法
十一、总结
十四种类型，一句话各自的定位
std → 万能牌：免驱、稳、兼容一切（默认推荐）
cirrus → 博物馆展品：只有古董系统需要
vmware → 隔壁家的卡：性能尚可但要点名装驱动
qxl 系列 → SPICE 搭档：数字就是屏数，必须配合 SPICE
virtio → Linux 亲儿子：性能好，Windows 用不了
virtio-gl → 加 OpenGL 的 virtio：Linux 3D 场景
none → 让路选项：直通场景用，但前提必须满足
serial0-3 → 文本世界：无头服务器的日志通道
三句话决策
① Windows 虚拟机 → 默认选 std，别折腾
② Linux 虚拟机 → 桌面用 qxl/virtio，无头用 serial0
③ 直通显卡场景 → 用 none 可以，但必须保证显卡有 EDID
一条保命规矩
虚拟机里必须有"主显示设备"：
虚拟显卡 或 直通显卡（+ x-vga + EDID）
两者都没有 = 卡死
附：命令速查卡
# 查看某虚拟机的显示配置
qm config <VMID> | grep vga
# 修改显示类型
qm set <VMID> -vga std
qm set <VMID> -vga none
# 带显存参数（32 MiB）
qm set <VMID> -vga std,memory=32
# 查看虚拟机内的 PCI 显示设备
echo'info pci' | qm monitor <VMID> | grep -i vga
# 判断是否卡死
ps -o etime,time,%cpu -p $(pgrep -f 'kvm.*<VMID>') # CPU 持续 99% = 卡死
ip -s link show tap<VMID>i0 # RX 恒为 0 = 客户机没发包
附二：各类型对应的 QEMU 底层参数
PVE 的 vga 参数最终会被翻译成 QEMU 命令行参数。知道这个，排查时会方便很多：
| PVE 类型 | QEMU 参数 |
| std | -vga std |
| cirrus | -vga cirrus |
| vmware | -vga vmware |
| qxl / qxl2-4 | -vga qxl（多屏时额外挂 qxl 设备） |
| virtio | -device virtio-vga |
| virtio-gl | -device virtio-vga-gl |
| none | -vga none |
| serial0-3 | -vga none + -serial 重定向 |
三个实际用处：
① 排查：确认配置真的生效了
ps aux | grep 'kvm.*<VMID>'
→ 直接看 QEMU 的完整命令行
② 直通场景：确认 x-vga 有没有生效
命令行里会出现 x-vga=on
③ 进阶玩法：多显卡、自定义 vBIOS 等必须走 QEMU 参数
一段真实命令行的片段：
-device vfio-pci,host=0000:01:00.0,id=hostpci0.0,
bus=ich9-pcie-port-1,addr=0x0.0,x-vga=on,multifunction=on
↑
这块直通卡被设为主显示
比"在界面上点了个勾"直白得多——尤其在你排查"配置到底生效没有"的时候。
📌 本文的选项列表与参数说明基于 PVE 8.x 官方文档（man qm.conf）。
不同版本可能略有差异，以你手上的版本为准。
如果你想和更多 PVE 用户交流显示设备踩坑心得，欢迎来 云栈社区 逛一圈。
发表于 19 小时前
|
查看: 1|
回复: 0
