企业官网建设流程全解析

在 Windows 上跑 WSL，大家已经很熟悉：打开终端，安装 WSL2，就能直接在 Windows 里拉起一个 Ubuntu、Debian 或者 Kali，把它当成原生 Linux 环境来用。WSL 是 Windows Subsystem for Linux，那如果把方向反过来——在 Linux 系统里跑一个完整的 Windows 虚拟机——很多人就没认真试过。标题里的“LSW”是一个戏称，意思是 Linux 下的 Windows 虚拟机，它不是一个真正叫 LSW 的开源软件，而是一类我们经常忽略的虚拟化需求。

为什么这个反向需求值得认真聊？因为开发、测试、运维里确实有大量场景必须用完整 Windows 环境：比如验证某个软件在 Windows 10/11 上的行为、跑只提供 Windows 安装包的客户端、在 CI/CD 里构建 Windows 测试用例，或者在 Linux 主机上给团队提供一个远程 Windows 桌面。Wine 能跑一部分 Windows 程序，但兼容性永远做不到完整系统级别。更合理的选择是在 Linux 上通过虚拟化方案安装 Windows，其中最常见、性能最接近原生的就是 QEMU/KVM + libvirt 这套栈。

这篇文章就以“Linux 中创建 Windows 虚拟机”为主线，按“硬件检查 -> 虚拟化环境安装 -> Windows 虚拟机创建 -> 系统安装与驱动加载 -> 网络/文件互通 -> 命令行与批量管理”的顺序展开。KVM 环境下 Windows 虚拟机更接近一套完整的“可管理基础设施”，你可以快照、克隆、批量复制、通过 API 管理，而不是像普通桌面虚拟机那样只能开一个窗口来用。先看它能做什么，再一步步操作，最后给出常见问题的排查思路。

1. 核心能力速览

在开始之前，先把“WSL 跑 Linux”和“Linux 里跑 Windows 虚拟机”两套方案放在一起看，这样能帮你快速判断哪个方向适合自己。

从表中能看出，WSL 和“LSW”并不是竞争关系，而是互为补充。WSL 适合你习惯 Linux 工具链但不方便切换整机系统的场景；而 KVM/QEMU 里的 Windows 虚拟机，适合 Linux 主机需要运行完整 Windows 系统，或者需要把 Windows 作为可管控的“计算单元”来使用的场景。

这套方案的核心能力可以归纳为：

• 原生虚拟化：基于 KVM 硬件加速，Windows 客户机可以拿到近乎物理机的 CPU 和内存性能。
• 完整系统支持：不是模拟 Windows API，而是完整安装 Windows 系统，驱动、注册表、服务全都可用。
• 灵活的管理方式：既能用 virt-manager 图形界面操作，也能用 virsh 命令行、libvirt XML、Python API 做批量管理。
• 快照和克隆：虚拟机整体快照、离线/在线克隆都很成熟，很适合制作 Windows 基座镜像后批量复制。
• 远程访问：安装完成后，可通过 SPICE、VNC 或 Windows 远程桌面从 Linux 主机访问 Windows 桌面。

下面进入实操部分。这台“LSW”跑起来的条件并不高，但前置环境如果没查清楚，后面大概率会出现启动失败或系统安装到一半找不到磁盘的问题。

2. 适用场景与使用边界

“在 Linux 里跑 Windows 虚拟机”听起来很酷，但不是所有需求都应该这样解决。先把适用场景和边界画清楚，后面踩坑会少很多。

适合用 KVM/QEMU 跑 Windows 虚拟机的场景包括这几类：

• 软件兼容性测试：你维护的 Linux 服务器或 Linux 桌面环境，需要验证业务系统在 Windows 客户端上的表现。
• Windows 专属软件运行：某些网银控件、企业办公套件、工业软件只提供 Windows 版，而且必须跑完整系统。
• 研发测试平台：需要在 Windows 环境调试脚本、跑自动化测试、验证 Windows 补丁和组策略。
• 远程桌面给团队用：Linux 服务器上跑一个 Windows 虚拟机，团队成员通过远程桌面接入，复用公司已有的 Windows 授权。
• 虚拟化环境演练：想学 KVM、libvirt 和批量虚拟机管理，但手头没有多台服务器，可以先在本机跑一台 Windows 客户机练手。

尽量别用这种方式解决的场景：

• 只想跑一个 Windows 小工具，Linux 有对应替代方案，优先用原生 Linux 应用。
• 只需要命令行工具，可以优先评估 Wine 或者 Windows 容器方案，避免维护完整 Windows 系统的成本。
• 没有任何 Windows 授权，且只是短暂使用，不建议长期跑一个未授权的系统。
• 硬件不支持虚拟化，勉强跑虚拟机会非常慢，体验很差。

使用边界这一块要特别强调授权问题。在 Linux 上创建 Windows 虚拟机，Windows 系统本身仍然受微软授权协议约束。测试开发建议使用微软官方提供的评估版镜像或你所在组织已购买授权的 Windows 安装介质，不要使用来路不明的精简镜像或激活注入镜像。生产环境使用完整 Windows 桌面或服务器系统时，请先确认授权合规。数据安全方面，Windows 虚拟机内的文件默认存放在 qcow2 磁盘镜像里，如果虚拟机被克隆或导入到其它主机，镜像内数据也应纳入同等的数据分级管理。涉及人脸、声音、业务数据等敏感素材时，必须遵守隐私保护法规和使用边界。

另外，虽然标题里用了“LSW”这个说法，但“在 Linux 中运行 Windows”并不是一个新工具，而是虚拟化技术栈的常规用法。下面安装过程中出现任何问题，优先检查 CPU 虚拟化开关和内核模块，这两点占了启动失败原因的一大半。

3. 环境准备与前置条件

KVM 虚拟化对硬件要求不算高，但前提是 CPU 必须支持虚拟化扩展。绝大多数近十年的 x86 CPU 都支持 Intel VT-x 或 AMD-V，但在部分品牌机、笔记本和 BIOS 默认配置里，虚拟化开关可能处于关闭状态。所以第一步不是急着安装软件，而是先确认 CPU 虚拟化是否开启。

在 Linux 宿主机终端执行：

grep -E --color=auto '(vmx|svm)' /proc/cpuinfo

如果输出中包含vmx，说明 Intel CPU 的虚拟化扩展已开启；如果包含svm，说明 AMD CPU 的虚拟化扩展已开启；如果没有任何输出，大概率需要在 BIOS/UEFI 中开启 VT-x 或 SVM 选项。要注意，grep能看到标志位不代表 KVM 内核模块一定可用，还需要确认/dev/kvm设备节点是否存在：

ls -l /dev/kvm

如果提示 No such file or directory，先检查内核模块是否加载：

lsmod | grep kvm modprobe kvm_intel # Intel CPU modprobe kvm_amd # AMD CPU

在 Debian/Ubuntu 系的 Linux 发行版上，安装 KVM、libvirt 和 virt-manager 的典型命令是：

sudo apt update sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients virtinst virt-manager

安装完成后启动并设置 libvirtd 服务开机自启：

sudo systemctl enable --now libvirtd sudo systemctl status libvirtd --no-pager

把当前用户加入 libvirt 和 kvm 用户组，避免每次操作都要 sudo：

sudo usermod -aG libvirt,kvm $USER

建议先退出重新登录一次，然后执行id命令确认用户组是否生效。不重新登录的话，你可能仍然没有权限连接 libvirt，之后打开 virt-manager 或执行 virsh 时会出现连接失败。

安装完成后还要看一下 osinfo 数据库里能不能识别 Windows 系统的 --os-variant 参数：

osinfo-query os | grep -i windows

这一步能帮你稍后正确指定操作系统版本。

磁盘和资源方面，Windows 11 建议预留 60GB 以上磁盘空间，Windows 10 建议 40GB 起步。如果使用 qcow2 格式，磁盘是“按需增长”的，不是创建后立即占用全部空间。内存方面，宿主机至少要有 8GB 可用内存，给 Windows 虚拟机分配 4GB 以上体验才比较流畅。CPU 核心数按宿主机实际线程数分配，不要把所有核心都塞给一台虚拟机。

你还需要准备两个 ISO 文件：

• Windows 安装镜像：请从微软官方渠道或你所在组织的合法授权渠道下载。
• virtio-win 驱动镜像：用于在 Windows 安装过程中识别 virtio 磁盘和网卡。可以从 virtio-win 项目官方发布渠道获取，请下载与你使用的 QEMU/KVM 版本兼容的新版驱动镜像。

把这两个 ISO 放到宿主机的固定目录，例如/opt/iso/，后面创建虚拟机时引用。

4. 安装部署与启动方式

环境准备完成后，就可以创建第一台 Windows 虚拟机了。这里推荐使用 virt-install 命令行方式，相比 virt-manager 图形界面，命令行更便于复用和批量化管理。

先创建磁盘镜像目录并规划虚拟机磁盘文件：

sudo mkdir -p /var/lib/libvirt/images

如果下载的 Windows ISO 和 virtio-win 驱动镜像不在同一个目录，可以先统一放到/opt/iso/下。接下来以 Windows 11 为例，执行 virt-install 创建虚拟机：

sudo virt-install \ --name win11-test-vm \ --memory 4096 \ --vcpus 4 \ --disk path=/var/lib/libvirt/images/win11-test-vm.qcow2,size=60,format=qcow2,bus=virtio \ --cdrom /opt/iso/Win11_23H2_Chinese_Simplified_x64.iso \ --disk path=/opt/iso/virtio-win-0.1.240.iso,device=cdrom \ --os-variant win11 \ --network network=default,model=virtio \ --graphics spice \ --video virtio \ --boot uefi

说明一下这里参数的含义：

• --memory 4096：给客户机分配 4096MB 内存。这是示例配置，实际按宿主机内存调整。
• --vcpus 4：分配 4 个 vCPU。
• --disk第一个参数是 Windows 系统磁盘，格式 qcow2，总线类型 virtio。
• --cdrom是 Windows 安装镜像。
• --disk第二个参数用device=cdrom把 virtio-win 驱动镜像挂载成另一个光驱，这个驱动在 Windows 安装阶段非常关键。
• --os-variant win11：告诉 libvirt 按 Windows 11 的默认配置优化虚拟机。
• --network network=default,model=virtio：使用 libvirt 默认 NAT 网络，网卡类型 virtio。
• --graphics spice：通过 SPICE 协议提供图形访问。
• --video virtio：使用 virtio 显卡。
• --boot uefi：Windows 11 强制要求 UEFI 和安全启动，建议显式指定。

如果 Windows 版本是 Windows 10，且你的测试环境不需要 UEFI，也可以把--boot uefi去掉并调整--os-variant win10。要注意的是，实例名称win11-test-vm不要包含特殊字符，后面 virsh 管理时会频繁用到这个名字。

在你的 Linux 发行版上，NAT 网络 default 可能默认没有启动。执行下面命令启动并设置自动启动：

sudo virsh net-start default sudo virsh net-autostart default

创建完成后，打开 virt-manager 可以看到这台虚拟机正在运行。如果当前环境没有图形桌面，也可以使用 virt-viewer 连接：

sudo virt-viewer --connect qemu:///system win11-test-vm

virt-install 执行后会自动打开一个图形安装窗口，里面会开始 Windows 安装流程。这里不要直接开始安装，因为 virtio 磁盘在 Windows 安装程序里可能显示为未识别设备。接下来重点处理驱动加载。

5. 功能测试与效果验证

5.1 Windows 安装阶段加载 virtio 驱动

Windows 安装程序如果看不到你的虚拟机磁盘，常见表现是“选择安装位置”页面的磁盘列表为空，或者提示找不到任何驱动器。这是因为磁盘类型是 virtio，Windows 安装包默认没有内置该驱动。

解决办法是在安装界面点击“加载驱动程序”，然后浏览到 virtio-win 光驱，选择对应 Windows 版本的驱动目录。virtio-win ISO 里通常有vioscsi或viostor驱动目录，选择后系统会识别出 60GB 的 virtio 磁盘，之后才能正常分区安装。

这个环节是最容易卡住新手的一步。如果加载驱动后还是找不到磁盘，检查 virtio-win 驱动光驱是否已经挂载：

sudo virsh domblklist win11-test-vm

输出中应该能看到两个光驱设备，一个是 Windows 安装 ISO，一个是 virtio-win ISO。如果少一个，用--disk path=... device=cdrom参数补上后重启虚拟机。

5.2 系统安装完成后的基础验证

Windows 安装完成后，第一件事是确认设备管理器里没有大面积感叹号。正常情况下 virtio 驱动的网卡、磁盘、显存设备都应该被正确识别。如果之前安装阶段只加载了磁盘驱动，进入系统后可以再执行 virtio-win ISO 里的virtio-win-guest-tools.exe，补装网卡、显卡和内存气球驱动。

在虚拟机内部打开命令提示符，执行：

ipconfig /all

如果能拿到一个 192.168.122.x 地址（libvirt 默认 NAT 网段），说明 virtio 网卡工作正常。Windows 虚拟机默认可以通过 NAT 访问外网，但外部网络默认不能主动连入虚拟机内部。

在 Windows 虚拟机内部验证网络连通性：

ping 192.168.122.1 ping 10.0.2.2 # 如果使用 QEMU 用户模式网络则可能是这个地址

不同网络模型的网关地址可能不同。更直接的办法是从宿主机方向验证，在 Linux 宿主机上执行：

sudo virsh domifaddr win11-test-vm

这条命令会显示虚拟机的 IP 地址。如果输出为空，可能需要使用 DHCP 租约查询：

sudo virsh net-dhcp-leases default

获得 IP 后，Linux 宿主机可以尝试 ping 这个 IP，确认虚拟网络双向连通。

5.3 文件共享与远程桌面

WSL 场景下，Windows 可以直接访问 Linux 文件，但在反向 Windows 虚拟机里，宿主机和客户机的文件互通方式不同。

推荐两种方式：

方式一：在 Windows 虚拟机里开启 OpenSSH Server，从 Linux 宿主机直接复制文件到 Windows。在 Windows 虚拟机中用管理员身份打开 PowerShell，执行：

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 Start-Service sshd Set-Service -Name sshd -StartupType 'Automatic'

如果命令参数在你的 Windows 版本上不适用，可以打开“设置 -> 系统 -> 可选功能”，添加 OpenSSH 服务器功能。启动后，Linux 宿主机执行：

ssh administrator@192.168.122.x

稳定后可继续测试 scp 命令：

scp ./test-file.zip administrator@192.168.122.x:C:/Users/admin/Desktop/

方式二：使用 virt-manager 的 SPICE 文件共享功能或 Windows 远程桌面。SPICE 支持宿主机与客户机之间拖放文件和剪贴板共享，前提是 Windows 虚拟机内安装了 SPICE guest tools。如果 Windows 虚拟机需要长期远程连接，开启 Windows 自带的远程桌面服务，再从 Linux 宿主机用 Remmina 或 FreeRDP 客户端连接，比每次打开 virt-manager 更轻量。

5.4 快照测试

虚拟机功能验证的一个重要环节是检查快照是否可以正常创建和恢复。安装完系统、补好驱动、更新完系统之后，先做一个干净快照：

sudo virsh snapshot-create-as win11-test-vm win11-clean --description "Windows 11 clean after install and driver"

查看快照列表：

sudo virsh snapshot-list win11-test-vm

日常测试时如果系统状态被改坏，可以随时回滚到干净快照：

sudo virsh snapshot-revert win11-test-vm win11-clean

这个操作在兼容性测试场景下很实用。你只需要保留一个经过验证的 Windows 基础镜像，之后怎么折腾都不怕。

6. 接口 API 与批量任务

Windows 虚拟机跑通后，如果只是偶尔开一台虚拟机，virt-manager 已经够用。但如果你在一台 Linux 服务器上维护多台 Windows 虚拟机，或者要为团队批量创建测试环境，就一定要切换到 virsh 命令行和 libvirt API。

6.1 virsh 常用管理命令

查看所有虚拟机状态：

virsh list --all

启动、关闭、强制关机、重启：

virsh start win11-test-vm virsh shutdown win11-test-vm virsh destroy win11-test-vm virsh reboot win11-test-vm

设置虚拟机跟随宿主机开机自启：

virsh autostart win11-test-vm virsh dominfo win11-test-vm

6.2 批量克隆 Windows 虚拟机

Windows 系统自身有 SID 识别机制，多台克隆虚拟机同时加入域时会出现 SID 冲突。要在批量场景里处理好这个问题，建议先在源虚拟机里运行 Windows Sysprep，把系统重置到“开箱体验”状态，然后再关机做模板。

在 Windows 虚拟机内执行：

C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown

等虚拟机自动关机后，确认源虚拟机处于关机状态，然后使用 virt-clone 克隆：

sudo virt-clone \ --original win11-base \ --name win11-test-01 \ --file /var/lib/libvirt/images/win11-test-01.qcow2

如果要批量克隆 3 台，可以用脚本循环：

for i in 01 02 03; do sudo virt-clone \ --original win11-base \ --name win11-test-$i \ --file /var/lib/libvirt/images/win11-test-$i.qcow2 done

克隆完成后启动每台虚拟机，进入系统重新设置计算机名和 IP 地址。如果模板已经正确执行过 Sysprep，克隆出来的系统会重新生成新的安全标识符，适合加入域或测试环境批量创建。

6.3 通过 libvirt API 管理虚拟机

libvirt 提供 Python、Go、Java 等多种语言的 API。以 Python 为例，安装 libvirt-python 后就可以在一个脚本中批量获取虚拟机状态：

import libvirt conn = libvirt.open("qemu:///system") if conn is None: raise SystemExit("无法连接 libvirt，请检查是否在 libvirt 用户组中") doms = conn.listAllDomains(0) for dom in doms: print(dom.name(), dom.info().state)

实际项目中可以通过该 API 把 Windows 虚拟机状态集成到自动化平台，例如实现测试环境巡检、根据消息队列动态启停 Windows VM。要注意，libvirt.open("qemu:///system")连接的是系统级 libvirt，普通用户需要在libvirt用户组中才有权限。

6.4 批量任务设计建议

如果需要定期批量执行 Windows 虚拟机里的任务，建议采用“模板机 + 克隆 + 任务脚本”的方式。把 Windows 模板机做成带有自动化执行环境的基础镜像，任务开始时从模板克隆出临时虚拟机，在客户机里执行测试脚本，结束后关机，再删除临时虚拟机。这样可以避免在同一台长期运行的 Windows 虚拟机上堆叠脏数据和环境冲突。

任务脚本要放在 Windows 虚拟机内，通过计划任务或登录启动方式触发。宿主机侧用 shell 脚本或 Python 脚本控制虚拟机生命周期：

virsh start win11-task-vm sleep 60 # 等待虚拟机内任务执行完成后，再执行 shutdown virsh shutdown win11-task-vm

这个模式非常适合自动化测试需求。单台 Windows 虚拟机测试环境用完即销毁，不会污染模板。

7. 资源占用与性能观察

KVM 下的 Windows 虚拟机性能取决于 CPU 虚拟化是否开启、内存是否充足、磁盘 IO 是否合理，以及是否使用 virtio 驱动。

启动 Windows 虚拟机后，可以在宿主机上执行virsh查看分配的资源：

virsh dominfo win11-test-vm virsh vcpuinfo win11-test-vm

查看虚拟机的实时内存状态：

virsh memstat win11-test-vm

如果要看宿主机侧的整体资源占用趋势，可以使用：

virt-top

该命令会按虚拟机维度显示 CPU 和内存使用量，适合在多虚拟机场景下快速定位“哪台 Windows 虚拟机把宿主机资源吃满了”。

使用 qcow2 磁盘时，虚拟磁盘文件是动态增长的。要查看实际占用的磁盘空间，不能直接看 ISO 文件大小，而要看 qcow2 文件本身：

du -h /var/lib/libvirt/images/win11-test-vm.qcow2

如果虚拟机内部报告磁盘已使用 30GB，但 qcow2 文件只占 15GB，说明释放的空间还未被回收，这是正常现象。如果确认客户机内部删除大量文件，希望宿主机磁盘空间回落，可以执行：

sudo fstrim --fstab --verbose

但 Windows 客户机对 discard 的支持取决于 virtio-scsi 和存储配置，实际效果以测试为准。

Windows 虚拟机的图形性能方面，默认 virtio-video 方案适合普通桌面办公，但不适合高负载 3D 应用。如果确实需要运行 3D 加速软件，需要评估 GPU 直通或 vGPU 方案，这类方案要求宿主机有不只一张可用 GPU，配置复杂度明显更高。普通开发测试不需要追求这一层。

长时间运行的 Windows 虚拟机需要关注的指标包括：

• 宿主机的剩余内存，避免 swap 导致虚拟机卡顿。
• CPU 的 steal 或 wait 值，判断 vCPU 是否过量分配。
• 磁盘 IO 延迟，尤其是多台虚拟机共用同一块机械盘时。
• 虚拟机内的 Windows 更新下载流量，某些测试网络可能因为这个被打满。

内存分配上，Windows 10/11 客户机给 4GB 是最低体验，开发测试机推荐 8GB。从资源效率角度，不要盲目给虚拟机几十核 CPU，通常 2-4 核配合足够内存比“超多核但内存不足”的策略更实际。

8. 常见问题与排查方法

下面这张表覆盖了从创建到运行的大多数问题，你可以对照排查。

针对其中几个高频问题展开说明。

问题一：启动后黑屏或无显示输出。

先别急着重装，确认虚拟机是否处于运行状态：

virsh list --all

再用 domblklist 确认安装介质是否仍然挂载：

virsh domblklist win11-test-vm

如果在安装系统完成后没有自动断开 ISO，Windows 可能会反复从 ISO 启动，看起来就像装完系统后又进入安装引导界面。可以把 CDROM 设备从虚拟机中分离：

virsh detach-disk win11-test-vm vda --live # 如果是系统盘则不要执行这条

系统盘不能随便 detach。正确的做法是从 virt-manager 图形界面的虚拟光驱设置里“断开”Windows 安装 ISO，保留磁盘设备。

问题二：virtio-win ISO 加载了，但安装程序找不到驱动。

有些 virtio-win ISO 会按目录组织驱动，Windows 安装程序不能自动遍历所有目录。你需要在加载驱动对话框中手动指定 virtio-win 光驱的根目录，并勾选“包括子文件夹”。如果某个目录不存在，可以尝试换一个驱动的“amd64/2k19”或“amd64/2k22”目录。

问题三：克隆后的 Windows 虚拟机桌面背景变黑或系统无法进入桌面。

这通常是因为克隆时源虚拟机还在运行，或者没有在克隆前正确执行 Sysprep。务必在关机状态下克隆，并且模板机只应该用于准备模板，不要把它当成日常使用的虚拟机。

问题四：vCPU 分配很多，但 Windows 里跑应用还是很慢。

先查看 virtio 驱动是否安装，尤其是内存气球驱动。没有 virtio 驱动的 Windows 虚拟机会退化为模拟设备，CPU 和磁盘性能都可能打折。进入 Windows 虚拟机，重新运行 virtio-win-guest-tools 安装程序，补全所有 virtio 组件。

9. 最佳实践与合规提醒

把一台 Windows 虚拟机在 Linux 上跑起来不难，但长期稳定使用需要养成几个习惯。

第一，模板机和业务机分开。

创建一台“基础 Windows 模板虚拟机”，安装系统、补丁、virtio 驱动、常用测试工具后封装成模板，之后不要在这台机器上做日常操作。每次需要新环境时从模板克隆。这样能最大程度避免环境漂移，也能让批量创建流程稳定可控。

第二，重要虚拟机的 qcow2 磁盘建议开启定期快照。

实验环境可以快照，生产环境建议搭配备份策略。KVM 没有专门解决所有备份问题的内置工具，但可以用 virsh snapshot 制作短期回滚点，并在更底层使用文件系统快照或备份工具保护镜像文件。

第三，按最小权限原则管理 libvirt。

Linux 服务器上如果跑着生产 Windows 虚拟机，不要把开发人员随意加入 libvirt 用户组。libvirt 用户组具备很强的系统控制能力，组内成员可以创建、销毁、修改宿主机上的虚拟机。建议只给专门的运维人员或自动化服务保留 libvirt 管理权限。

第四，磁盘镜像存储要点。

Windows 虚拟机的 qcow2 镜像动辄几十 GB，建议存储在支持厚分配、快照能力强的存储上。如果使用网络存储，先测试 Windows 虚拟机内大文件拷贝的实际 IO 表现，避免把虚拟机跑在延迟极高的网络盘上。

第五，Windows 授权与版本选择。

生产环境使用 Windows 虚拟机必须确认授权范围。开发测试可以从微软官方渠道下载评估版，但评估版有时效限制，到期后系统会自动关机或显示激活提醒。不要把评估版当成永久测试机使用。企业内若有批量测试需求，确认批量授权是否覆盖虚拟机场景。

第六，Windows 虚拟机安全更新不能忽略。

在 Linux 宿主机上创建的 Windows 虚拟机暴露在测试网络或内网后，同样需要及时更新 Windows。不要把“这只是虚拟机”当成不安全也没关系的理由。虚拟机里的系统如果被攻破，攻击者可能利用它访问同一网络中的其它主机。

第七，明确快照保留策略。

快照文件会持续占用宿主机磁盘。每次测试后留下的快照如果不清理，几十个测试虚拟机加快照很快会把磁盘塞满。建议每次克隆完、验证完、快照确认无需回滚后及时删除快照：

virsh snapshot-delete win11-test-vm --snapshotname win11-clean --current

10. 总结与下一步

这次我们把“在 Linux 系统中运行 Windows 虚拟机”这条反向路线完整跑了一遍。从概念上说，“LSW”并不像 WSL 那样是一个官方工具，而是把 KVM/QEMU 虚拟化栈用在 Windows 客户机上的一套实践。整套流程的核心不是能不能装，而是你有没有把 CPU 虚拟化、virtio 驱动、网络模式、批量管理这几样关键环节理解清楚。

如果你之前只玩过 WSL，现在可以按下面的顺序验证一次：

• 先用grep -E '(vmx|svm)' /proc/cpuinfo确认 CPU 虚拟化已开启。
• 安装 qemu-kvm、libvirt-daemon-system、virtinst、virt-manager。
• 准备 Windows 官方安装 ISO 和 virtio-win 驱动 ISO。
• 用 virt-install 创建一台 4GB 内存、2-4 核、60GB qcow2 磁盘的测试虚拟机，重点看 Windows 安装阶段能不能识别 virtio 磁盘。
• 系统装好后，先验证 virtio 驱动、网络、远程访问，再做一次干净快照，把模板固定下来。
• 之后就可以开始尝试 virt-clone 批量克隆，通过 virsh 脚本自动化管理多台 Windows 虚拟机。

最容易踩的坑基本集中在三处：/dev/kvm不存在导致启动失败，Windows 安装阶段没有加载 virtio 磁盘驱动导致找不到硬盘，以及克隆模板机没有先运行 Sysprep 导致 SID 冲突。

下一步建议沿着“模板化 + 脚本管理”方向继续深入。先把一台 Windows 虚拟机做成基础模板，再写脚本从模板批量克隆，同时把 libvirt API 接到你自己的自动化发布或测试平台里。这样一来，一台 Linux 服务器就能像管理普通服务一样管理一组 Windows 虚拟机，反向的“LSW”也能成为你基础设施里的常态工具。建议收藏备用，后面做跨系统测试时直接按这套流程操作。