企业官网建设流程全解析

引子

前面几篇博客中，我已经在 Proxmox VE（PVE）上安装了 Windows XP SP3 和 Windows 98 SE，并陆续配置了 SPICE、显示驱动、AC97 音频以及 USB Tablet。

经过这些折腾，两台老 Windows 都已经可以正常使用。

特别是通过 Ubuntu 上的 Remote Viewer 远程访问后，无论是显示效果、声音，还是鼠标操作，都比最初通过 PVE Console 使用时舒服了不少。

原本以为，这轮老 Windows 实验可以告一段落了。

不过，真正使用起来，还是发现了一些不太满意的地方。

例如，Remote Viewer 每次打开都要手动调整缩放比例；Windows XP 中按一下Print Screen，竟然会导致 SPICE Agent 崩溃。

另外，之前安装 XP 时，为了避免设备管理器中的未知设备，以及减少不必要的兼容性问题，我还关闭了 VirtIO Balloon 和 QEMU VM Generation ID。

当时这么处理没有什么问题，毕竟主要目标是让系统先稳定运行。

但现在 XP 的 SPICE、显示、声音都已经正常，我又有些好奇：

如果重新启用这些虚拟硬件，能不能找到合适的驱动，让 XP 真正支持它们？

于是，又有了这一轮优化。

这次主要完成了三件事：

1. 让 Remote Viewer 从“能用”变得更方便，不再反复调整缩放比例。

2. 升级 XP 的 SPICE Guest Tools，解决Print Screen导致 Agent 崩溃的问题。

3. 重新启用此前关闭的 VirtIO Balloon 和 VM Generation ID，并成功安装相应驱动。

此外，还顺便解决了 QEMU Guest Agent 无法让 PVE 正确显示 XP IP 地址的问题。

下面按实际折腾过程记录一下。

一、先说明：之前的做法并没有错

本次实验仍然使用此前的环境。

前面安装 XP 时，我们遇到过两个额外的虚拟硬件设备：

• VirtIO Balloon，内存气球设备。

• QEMU Virtual Machine Generation ID，虚拟机代际标识设备。

由于 XP 默认没有对应的驱动，当时设备管理器里会出现黄色感叹号。

最简单的解决方案，就是在 PVE 中关闭这两个不必要的设备。

这样做既避免了未知设备，也减少了老系统的兼容性变量。

而且，对于一台主要用来体验经典软件的 Windows XP 虚拟机来说，这两个功能并不是必需的。

因此，之前关闭它们是一个合理的稳定性选择，并不是遗留了两个没有解决的问题。

只是随着实验继续，我想进一步了解 XP 究竟能支持多少现代虚拟化功能。

所以这次重新从较干净的 XP 环境开始测试，保留 Balloon 和 Generation ID 设备，再逐步安装驱动。

也就是说，这一轮不是在修复此前做错的配置，而是在已经验证稳定的基础上，探索更完整的虚拟硬件支持。

二、改进一：Remote Viewer，从能用到好用

1. 每次打开都要手动放大，实在有些麻烦

此前配置 SPICE 后，我习惯在 Ubuntu 上通过 Remote Viewer 访问 XP 和 Win98。

基本使用体验已经不错。

但 XP、98 的屏幕分辨率通常比较低，例如 1024×768。

在现代高分辨率显示器上，Remote Viewer 默认打开后的画面就显得有点小。

虽然菜单里有 Zoom In，但每次都需要打开菜单，再点击放大。

如果要放大两级，就得重复操作。

偶尔用用还好，经常打开就有点烦人了。

后来发现，Remote Viewer 本身支持直接指定缩放比例：

remote-viewer --zoom=200 connection.vv

其中200表示 200% 缩放。

但是我的日常使用方式并不是通过终端运行命令，而是从 PVE 下载 SPICE 连接文件，然后在 Firefox 里直接点击打开。

所以问题变成了：

能不能让所有 SPICE 连接默认就使用 200% 缩放？

2. 修改 Remote Viewer 的默认启动配置

Ubuntu 的应用启动器通常放在：

/usr/share/applications/

Remote Viewer 对应：

remote-viewer.desktop

为了避免修改系统级文件，可以复制一份到用户目录：

mkdir -p ~/.local/share/applications cp /usr/share/applications/remote-viewer.desktop \ ~/.local/share/applications/

编辑：

gnome-text-editor \ ~/.local/share/applications/remote-viewer.desktop

找到其中的Exec=，把启动命令改成：

Exec=remote-viewer --zoom=200 %u

保存后更新应用数据库：

update-desktop-database ~/.local/share/applications

这里还遇到了一个比较奇怪的情况。

刚复制用户级.desktop文件时，Firefox 再次打开 SPICE 连接文件，竟然变成用文本编辑器打开。

但只要把复制出来的文件移走，原来的行为又恢复正常。

后来执行update-desktop-database，问题才解决。

所以，如果你也修改了用户级启动器，建议记得执行这一步。

可以通过下面的命令检查默认关联：

xdg-mime query default application/x-virt-viewer

正常情况下应返回：

remote-viewer.desktop

到这里，默认缩放已经解决。

以后通过 Firefox 点击 SPICE 文件，就能直接以 200% 缩放打开。

3. 快捷键为什么始终没有反应？

既然缩放参数可以通过启动器配置，我又想进一步设置快捷键。

例如：

Ctrl + Alt + U Zoom In Ctrl + Alt + J Zoom Out Ctrl + Alt + 0 Zoom Reset

Remote Viewer 提供--hotkeys参数，看起来很简单。

我先尝试：

remote-viewer \ --hotkeys=zoom-in=ctrl+alt+u,zoom-out=ctrl+alt+j,zoom-reset=ctrl+alt+0 \ connection.vv

但实际运行时，快捷键完全没有反应。

开始怀疑是不是 Ubuntu GNOME Wayland 的问题。

于是又尝试通过 XWayland 启动：

GDK_BACKEND=x11 remote-viewer ...

结果仍然一样。

检查进程：

pgrep -a remote-viewer

可以看到所有参数确实已经传入。

所以启动器没有问题，参数也没有丢失。

后来检查 PVE 下载的 SPICE 连接文件，发现里面本身就带着快捷键配置：

toggle-fullscreen=Shift+F11 release-cursor=Ctrl+Alt+R

继续研究后发现，Remote Viewer 在读取.vv连接文件时，会重新加载文件中指定的快捷键，覆盖前面通过命令行设置的热键。

这就解释了为什么：

• --zoom=200正常生效；

• --hotkeys参数能够看到；

• 但自定义快捷键始终不工作。

问题不是 Wayland，也不是键盘，而是 Remote Viewer 的配置加载顺序。

4. 最终方案：自动补充 .vv 快捷键

解决思路并不复杂。

既然.vv文件中的快捷键会生效，那就在 Remote Viewer 读取连接文件前，把需要的快捷键加进去。

不过，PVE 的 SPICE 连接文件包含短时有效的认证票据。

如果下载后手动打开编辑器修改，很容易因为操作时间过长导致票据过期。

我就遇到过 Remote Viewer 弹出：

Authentication required

实际上，并不是需要输入 XP 的账户密码，而是 SPICE 连接票据已经失效。

所以最终选择用一个启动脚本自动处理。

先创建：

mkdir -p ~/.local/bin

然后：

cat > ~/.local/bin/pve-spice-open <<'EOF' #!/usr/bin/env bash set -euo pipefail vv="${1:?缺少 SPICE 连接文件}" awk ' /^\[virt-viewer\]$/ { print print "zoom-in=Ctrl+Alt+U" print "zoom-out=Ctrl+Alt+J" print "zoom-reset=Ctrl+Alt+0" next } /^zoom-(in|out|reset)=/ { next } { print } ' "$vv" | /usr/bin/remote-viewer --zoom=200 - EOF chmod +x ~/.local/bin/pve-spice-open

这个脚本的工作很简单：

读取 PVE 下载的.vv文件，在原有配置基础上加入 Zoom 快捷键，然后立即启动 Remote Viewer。

原始连接文件不会被修改。

接着编辑：

~/.local/share/applications/remote-viewer.desktop

将Exec=改成：

Exec=/home/你的用户名/.local/bin/pve-spice-open %f

注意替换为实际的用户目录。

最后执行：

update-desktop-database ~/.local/share/applications

再次从 PVE 下载 SPICE 文件，在 Firefox 中点击打开。

这次终于成功了。

现在 Remote Viewer 可以：

而且不需要每次手动配置。

这算是本轮优化中最实用的一项。

毕竟它不只适用于 XP 和 Win98，我通过 SPICE 访问的其他虚拟机也可以一起受益。

如果只需要默认缩放、不关心快捷键，其实修改.desktop中的--zoom就足够了，不需要额外脚本。

三、改进二：升级 SPICE Guest Tools，解决 XP 截图崩溃

Remote Viewer 的问题解决后，Windows XP 内部又出现了一个 Bug。

此前为了兼容 XP，我安装的是：

spice-guest-tools-0.74.exe

当时主要验证显示、声音、剪贴板和基本操作，没有发现明显问题。

但后来按下 XP 的Print Screen键时，竟然弹出了：

Microsoft Visual C++ Runtime Library Runtime Error! Program: C:\Program Files\SPICE Guest Tools\32\vdagent.exe

也就是说，按一下截图键，SPICE Agent 就崩溃了。

1. 先确认问题出在哪里

XP 中运行：

services.msc

找到：

RHEV Spice Agent

暂时停止服务。

然后再次按Print Screen。

结果：没有报错。

这基本可以确定，崩溃与旧版 SPICE Agent 有关。

由于Print Screen会将屏幕截图写入 Windows 剪贴板，而 SPICE Agent 又负责与 Remote Viewer 同步剪贴板，我怀疑这是旧版 Agent 处理位图剪贴板时触发的兼容性问题。

不过，这里只能确认崩溃与 Agent 有关，还不能断言具体是哪一段剪贴板代码存在 Bug。

一开始也考虑过禁用共享剪贴板来绕过。

但我觉得，既然使用 SPICE，就是希望它的功能尽可能正常，没有必要为了避免一个 Bug 而放弃剪贴板。

不如直接换个版本测试。

2. 从 0.74 升级到 0.141

查找历史版本后，我决定尝试：

spice-guest-tools-0.141.exe

官方下载归档：SPICE Guest Tools 历史版本

为了方便传入 XP，我在 Ubuntu 中制作 ISO：

sudo apt install genisoimage

然后执行：

genisoimage -o spice-xp-0.141.iso \ -J -R spice-guest-tools-0.141.exe

将生成的 ISO 上传到 PVE，挂载到 XP 虚拟机。

在 XP 中运行安装程序。

安装过程中，Windows XP 可能提示驱动未通过 Windows 徽标测试。由于这里使用的是专门选择的历史驱动，需要根据实际来源和系统环境判断是否继续。

安装完成后重启。

3. 再次测试 Print Screen

重启 XP，确认 SPICE Agent 正常运行。

再次按下：

Print Screen

这次没有出现 Runtime Error。

反复测试也没有复现之前的崩溃。

同时，QXL 显示、AC97 音频、剪贴板等原有功能保持正常。

所以至少在我这台 Windows XP SP3 32 位虚拟机中，SPICE Guest Tools 0.141 确实解决了 0.74 的 Print Screen 崩溃问题。

这也是为什么我后来决定继续使用 0.141。

不过，老系统驱动并不是越新就一定越好。

新版可能修复旧问题，也可能因为停止支持 XP 而引入新的兼容性问题。

对于 XP 这样的老系统，我觉得最合适的版本，不一定是最新版本，而是实际测试稳定的版本。

4. 顺便处理 QEMU Guest Agent 无法显示 IP

SPICE Guest Tools 0.141 还包含 QEMU Guest Agent。

但我发现，它附带的 Agent 虽然可以运行，PVE 却不能正确获取 XP 的网络接口信息。

比如：

qm agent 152 ping

能够成功。

但 PVE Summary 页面仍然没有正确显示 IP。

这说明 Agent 的基本通信已经建立，却不代表所有管理功能都可用。

后来我重新安装了一个历史版本的 32 位 QEMU Guest Agent：

qemu-ga-x86.msi

同样可以通过 ISO 传入 XP：

genisoimage -o qemu-ga-x86.iso \ -J -R qemu-ga-x86.msi

挂载后执行 MSI，安装程序可以对原有 Agent 进行升级。

同时确保 PVE 中启用了：

VM 152 → Options → QEMU Guest Agent

再次检查：

qm agent 152 ping

以及：

qm agent 152 network-get-interfaces

这次网络接口信息能够正常返回，PVE Summary 也终于正确显示 XP 的 IP 地址。

这里还有一个容易混淆的地方。

虽然名称相似，但：

• SPICE vdagent主要负责剪贴板等桌面集成功能。

• QEMU Guest Agent负责 PVE 与客户机之间的管理通信。

它们不是同一个程序。

因此，SPICE Guest Tools 0.141 解决了 Print Screen 崩溃，而单独升级 QEMU Guest Agent 解决了 PVE 无法正确获取 IP 的问题。

这两项改进需要分开看。

四、改进三：重新启用 XP 的 Balloon 和 VM Generation ID

接下来是这轮实验中另一个比较有意思的部分。

前面安装 XP 时，为了消除未知设备、减少兼容性问题，我在 PVE 中关闭了：

• VirtIO Balloon。

• QEMU VM Generation ID。

关闭以后，XP 已经可以稳定运行。

所以这次的目标并不是修复一个此前没有解决的故障，而是：

重新启用这两个原本被我们主动关闭的虚拟硬件，并看看 XP 能不能找到合适的驱动。

为了避免之前多轮安装留下的影响，我重新回到较干净的 XP 系统状态，保留这两个硬件设备，再按照已经验证过的步骤逐步配置。

结果还不错。

1. VirtIO Balloon：原来 0.141 已经包含驱动

VirtIO Balloon 是虚拟化环境中的内存气球设备。

它的主要用途，是让宿主机和 Guest OS 协作，动态调整或回收部分内存资源。

在 PVE 同时运行多台虚拟机时，这项功能可能有助于提高内存利用率。

此前 XP 中对应的未知硬件 ID 是：

PCI\VEN_1AF4&DEV_1002

我原本准备通过历史版 VirtIO ISO 安装它：

virtio-win-0.1.141.iso

但进一步检查发现：

SPICE Guest Tools 0.141 本身已经包含 VirtIO Balloon 驱动。

因此，这次没有必要再单独安装整套 VirtIO ISO。

在 PVE 中保留 Balloon 设备，安装 SPICE Guest Tools 0.141 后，XP 就能识别它。

设备管理器中出现：

VirtIO Balloon Driver

没有黄色感叹号。

这说明 Balloon 驱动已经成功加载。

不过，这次我主要验证的是驱动识别和设备状态，没有进一步测试动态内存回收时的实际表现。

对于这台主要用来运行经典软件的 XP 虚拟机，暂时也没有必要刻意压缩它的内存。

但至少说明：

此前关闭 Balloon 只是为了兼容和简化配置，并不代表 XP 无法支持 VirtIO Balloon。

2. VM Generation ID：另一个原本关闭的设备

剩下的是：

ACPI\QEMUVGID

它对应 QEMU VM Generation ID。

简单来说，这是一种用于让 Guest OS 识别虚拟机代际变化的机制。

例如，当虚拟机发生克隆、恢复到较早状态等操作时，支持该机制的客户机软件可以利用 Generation ID 判断状态是否发生变化。

这类功能对于某些需要维护状态一致性的服务器应用比较重要。

对于普通桌面 XP 来说，实际价值并不大。

但既然这次想验证 XP 的虚拟硬件支持，就顺便研究了一下。

3. 找到社区驱动，实际安装成功

后来在 Proxmox 官方论坛中找到相关讨论：

Win2003 / Win2k8 R2：ACPI QEMU VGID driver missing

其中有用户分享了一个老 Windows 可用的 Generation ID 驱动 ISO。

我下载并检查后，决定在 XP 中试试。

这里需要提醒一下：这是社区分享的安装介质，不是我能够独立确认来源和完整性的微软官方发行包。

如果读者想尝试，建议先核实文件来源，并在可恢复的测试虚拟机中使用。

在 PVE 中挂载驱动 ISO。

然后进入 XP：

设备管理器 → 未知设备 → 更新驱动程序 → 从指定位置搜索

指向光驱中的驱动文件。

安装完成后，原来的未知设备不见了。

设备管理器的「系统设备」下面，出现：

Microsoft Hyper-V 生成计数器

也就是：

Microsoft Hyper-V Generation Counter

打开驱动属性，可以看到：

而在「常规」页面，设备状态明确显示：

这个设备运转正常。

至此，可以确认：

Windows XP SP3 32 位已经能够识别并加载这个 VM Generation ID 驱动。

这里仍然需要区分驱动安装成功与完整功能验证。

设备管理器报告正常，说明设备与驱动匹配，而且驱动已成功加载。

但我没有进一步验证 PVE 快照恢复时 Generation ID 是否发生预期变化，也没有验证 XP 内部是否有程序实际利用这个机制。

因此，目前只能说驱动成功安装、设备正常工作，不能把它写成所有 Generation ID 功能都已通过测试。

4. 重新启用，和此前关闭，并不矛盾

回过头看，这个过程很有意思。

此前安装 XP 时，我们选择关闭 Balloon 和 Generation ID，是因为当时更关注系统能不能稳定使用。

而这次在已经熟悉 XP、SPICE 和驱动兼容性的基础上，再把它们重新启用。

最终：

这两种处理方式并不存在谁对谁错。

如果只是运行经典软件，关闭非必要的虚拟硬件完全合理。

如果像我一样，希望进一步研究 PVE 和 Windows XP 的虚拟硬件兼容性，那就值得重新启用并验证。

现在至少可以确定，这两项设备在 XP 中并不是完全没有驱动可用。

五、再看 Windows 98：为什么 XP 的可玩性明显更高？

完成这些优化后，再回头看看 Windows 98，我有一个很明显的感受：

XP 虽然也是二十多年前的系统，但在现代虚拟化平台上的集成能力，确实比 Windows 98 高得多。

1. Win98 的基础体验已经不错

此前为 Windows 98 配置过：

• VMDisp9x 虚拟显示驱动；

• AC97 3.62 声卡驱动；

• SPICE 音频后端；

• USB Tablet；

• Remote Viewer 远程访问。

这些配置使 Win98 的显示、声音和鼠标体验都得到了改善。

对于运行经典软件而言，已经比较实用了。

但这里有个容易混淆的地方。

我们虽然让 Windows 98 用上了 SPICE 远程显示和音频，却没有真正实现完整的 SPICE Guest Integration。

比如，AC97 并不是 SPICE 专用声卡驱动，而是 QEMU 模拟的虚拟声卡，通过 SPICE 后端把声音传给远程客户端。

USB Tablet 也不依赖 SPICE Guest Agent，而是利用绝对坐标输入改善鼠标定位。

VMDisp9x 则是社区开发的虚拟显示驱动。

这些功能让 Win98 更容易使用，却不能自动带来完整的共享剪贴板、文件传输或自动分辨率调整等能力。

2. Win98 真正缺少的是 VirtIO Serial 和 SPICE Agent

SPICE 的很多桌面集成功能，需要 Guest OS 内部运行 Agent。

典型的通信链路是：

Ubuntu Remote Viewer │ SPICE Server │ VirtIO Serial │ SPICE vdagent │ Windows 剪贴板

Windows XP 有相应的历史 VirtIO Serial 驱动和 SPICE Agent。

而 Windows 98 目前缺少成熟、可直接使用的组合。

这就是为什么 XP 可以实现共享剪贴板，而 Win98 虽然显示和声音正常，很多 SPICE 增强功能却发挥不出来。

共享文件夹还有额外要求，例如相应的 SPICE WebDAV 客户机组件，并不是单独安装显示驱动就能实现的。

3. 为什么不给 Win98 开发 VirtIO Serial 驱动？

VirtIO 本身是公开标准，相关 Windows 驱动也有开源实现。

但问题在于驱动架构。

Windows 98 属于 Windows 9x 系列。

Windows XP 属于 Windows NT 系列。

早期 VirtIO Windows 驱动主要面向 NT 系统，部分实现还依赖 Win98 并不支持的驱动框架。

如果要支持 Win98，并不是把 XP 的驱动重新编译一下就可以了。

开发者需要处理 PCI 设备、中断、Virtqueue、内存管理以及 Win9x 的驱动接口。

即便 VirtIO Serial 驱动做出来，还需要实现适用于 Win98 的 SPICE Agent。

这是一项投入不小的工程。

而 Windows 98 用户已经很少，其中真正需要完整 SPICE Guest Integration 的用户就更少。

所以到目前为止，我还没有找到成熟、经过验证的 Win98 VirtIO Serial + SPICE Agent 方案。

不过，像 VMDisp9x、SoftGPU 这些开源项目的存在，也说明仍然有人愿意为 Win9x 开发现代虚拟化环境下的新驱动。

未来如果有人实现了 Win98 的 VirtIO Serial 和 SPICE Agent，倒是值得再次尝试。

4. XP 和 Win98 的最终使用状态

经过这一轮实验，两台虚拟机大致可以这样对比：

这也说明了两台系统在 PVE 中适合扮演的不同角色。

Windows 98 更适合体验那个年代的桌面和经典软件，重点是显示、声音、鼠标以及运行稳定性。

Windows XP 则可以在运行经典软件的同时，获得更完整的现代虚拟化集成。

其中一个重要原因，就是 XP 所属的 Windows NT 驱动体系与后来的 Windows 系统有更多延续性。

所以即使官方早已停止支持 XP，我们仍然能利用历史版本的 VirtIO、QXL、SPICE Agent 等组件，让它在现代虚拟化平台上发挥更多功能。

写在最后：从能运行，到用起来舒服

回顾这一轮优化，实际做的事情并不算多。

但每一项都有比较明确的意义。

第一，Remote Viewer 的使用体验得到改善。

以前每次打开 SPICE 文件，都需要手动调整画面缩放。

现在直接从 Firefox 点击连接文件，就能自动使用指定缩放比例和快捷键。

而且这一改进适用于所有通过 Remote Viewer 访问的虚拟机。

第二，解决了 XP 的 SPICE Guest Tools 兼容性 Bug。

原先使用的 0.74 在按下 Print Screen 时会导致vdagent.exe崩溃。

升级到 0.141 后，问题不再复现，原有显示和音频功能也没有受到影响。

与此同时，通过单独升级 QEMU Guest Agent，让 PVE 可以正确获取 XP 的 IP 地址。

第三，重新启用了此前为了稳定性而关闭的虚拟硬件。

VirtIO Balloon 和 VM Generation ID 最初并不是没有处理，而是被我们有意禁用了。

这次通过适当的历史驱动，让它们重新出现在 XP 的设备管理器中，并且正常加载。

从这个角度看，这篇并不是把一个不完整的 XP 系统修修补补，而是在已经稳定运行的基础上，进一步改善使用体验并扩展虚拟化能力。

这也让我对 Windows XP 和 Windows 98 有了更直观的认识。

两者都能够在今天的 PVE 上运行，也都可以通过一些配置获得不错的基本体验。

但“能运行”和“能与现代虚拟化平台深度集成”，终究不是一回事。

XP 的驱动生态让它可以走得更远，而 Win98 则更多依靠硬件模拟和社区开发的专用驱动。

当然，我并不打算为了追求所谓的完美配置，把所有虚拟硬件功能都测试一遍。

对于 XP 和 Win98 这样的老系统，最重要的还是能正常运行当年的软件，用起来足够方便。

到这里，这轮 PVE 老 Windows 的折腾就暂时告一段落了。

从最初能装上系统，到画面、声音、鼠标都正常，再到解决日常使用中的 Bug、改善 Remote Viewer 体验，这几台老系统已经达到了我想要的状态。

以后如果有值得尝试的新驱动或开源项目，也许还会继续折腾。

但现在，它们已经可以安心留在 PVE 里，偶尔打开，体验一下那些陪伴过我们的经典 Windows 和老软件了。