说实话,我在写这篇博客前,先看了一眼自己近期的搜索记录——“WSL 2 怎么开”、“wsl --install 太慢怎么办”、“Windows 上的 Ubuntu 怎么装 Docker”。这个清单非常诚实:大多数开发者关心的是“在 Windows 里用 Linux”,而很少有人会刻意搜索“在 Linux 里装 Windows”。
但你有没有想过一个问题:WSL 这个缩写之所以成立,是因为微软把 Linux 子系统做进了 Windows。那反过来呢?如果有一天,你的主力机器跑的是 Linux,却又不得不打开一个 Windows 虚拟机来处理某个只有 Windows 才能干的事情,你会怎么办?
这篇文章聊的,就是另一种“反过来”的玩法。我把它戏称为“LSW”——一个不存在的缩写,概念上可以理解为Linux Subsystem for Windows,即在 Linux 系统里跑 Windows 虚拟机。虽然这个说法不够严谨,但它能帮我们快速建立一个镜像概念:WSL 解决了“Windows 用户想用 Linux 工具链”的痛点,而本文要解决的是“Linux 用户偶尔必须用 Windows 应用”的痛点。
从实际体验来看,现在的 Linux 桌面已经足够好用,但生态缺口依然存在:某些单位的网银 UKey、老旧的工业控制软件、只有 Windows 版的教学客户端、偶尔要测试的 IE 兼容页面。这些问题不会因为你热爱 Linux 就自动消失。
那么,在 Linux 上搞一个 Windows 虚拟机,到底是自找麻烦,还是值得一试?这篇文章会从技术路线选型、环境准备、virtio 驱动的坑、完整部署流程、日常使用优化、常见问题排查这几个角度展开。如果你正打算在自己的 Linux 机器上部署一台 Windows 虚拟机,或者只是在犹豫“要不要试一下”,这篇文章应该能给你一个完整的判断依据。
1. 为什么会在 Linux 里装 Windows 虚拟机?
在聊技术细节之前,先冷静问一句:你真的需要在 Linux 里跑 Windows 吗?
我总结了比较典型的几类需求:
第一类是刚需型。很多工具、软件、网页系统只支持 Windows 环境。比如部分银行的网银控件、税控盘驱动、某些学校或企业的老旧教学软件、医院或工业现场的专用上位机软件。这种情况不是“想不想用 Windows”的问题,而是“没有 Windows 就没法干活”的问题。
第二类是开发测试型。你在 Linux 上写 Web 页面、桌面应用,但老板或客户可能用 Windows 来访问,你需要在真实 Windows 环境里跑一遍验证兼容性。这种需求在测试工程师和前端工程师里非常常见。偶尔还要在干净的 Windows 环境里测一下自动化脚本,这时候一台能被随时创建、快照、重置的 Windows 虚拟机就是标准答案。
第三类是“过度型”,比如想在 Linux 里玩 Windows 游戏。这类需求通常需要 GPU 直通(PCIe Passthrough),配置复杂、硬件门槛高,不建议入门用户一上来就尝试。这篇文章后面不会把 GPU 直通作为主线,因为它的成本和风险比普通虚拟化高出不少,单独写一篇都未必讲得完。
如果只看表面,很多人会误以为“在 Linux 上装 Windows 虚拟机”就是把 VMware 或 VirtualBox 装好,然后一路下一步。但真正进入实操后你会发现,性能和体感的差距,主要来自虚拟化方案的选择,以及驱动是否到位。
2. 技术路线盘点:不是所有“Windows 虚拟机”都一样
想在 Linux 上跑 Windows,大致有四条路线。每条路线的隔离级别、性能损耗和配置难度差别非常大,选错了会让你在后面的使用中非常难受。
| 技术方案 | 隔离级别 | 性能损耗 | 配置难度 | 典型场景 |
|---|---|---|---|---|
| 裸机双系统 | 无,非虚拟化 | 接近零 | 中等,但无法同时使用 | 长期重度使用 Windows |
| VMware Workstation / VirtualBox | Type 2 虚拟机 | 中等 | 低,适合新手 | 临时用、不想折腾内核 |
| KVM / QEMU + libvirt | Type 1 虚拟化(内核级) | 低,接近裸机 | 中高,熟悉后更顺手 | 长期主力方案、性能敏感场景 |
| Wine / Proton | 兼容层,非虚拟机 | 低,但兼容性不完整 | 视软件而定 | 只想跑特定 Windows 应用 |
先解释两个术语:Type 1 虚拟化也叫裸机型虚拟化,虚拟机监控器直接跑在硬件之上,性能最好;Type 2 虚拟化跑在操作系统之上,多了一层开销。VMware Workstation 和 VirtualBox 属于 Type 2,而KVM 是 Linux 内核自带的 Type 1 虚拟化模块,配合 QEMU 负责设备模拟,这是目前 Linux 上真正接近裸机性能的路线。
我的判断是:如果你只想“装个 Windows 偶尔用一下”,VirtualBox 没问题,它能满足最低频的需求;但如果你希望这台 Windows 虚拟机长期存在,日常要开办公软件、跑测试、处理文件,甚至偶尔承担比较重的编译任务,那么 KVM + QEMU + virt-manager 才是更值得花时间掌握的方案。
这里还有个容易混淆的点:WSL2 本身其实也是虚拟机。微软用 Hyper-V 平台创建了一个轻量级虚拟机来跑 Linux 内核,只不过这个虚拟机对用户几乎透明,文件系统互通、命令行直接访问,让人感觉不到“虚拟机”。所以你在 Windows 里用 WSL 时,本质上已经是在和一个虚拟机打交道了。反过来,在 Linux 里跑 Windows,更常规的做法就是老老实实开一个完整的 Windows 虚拟机。
3. KVM 方案的环境准备与核心概念
选择 KVM/QEMU 之后,第一步不是急着下载 Windows ISO,而是先确认你的硬件和 Linux 发行版是否满足条件。
3.1 检查 CPU 虚拟化扩展
KVM 依赖 CPU 的虚拟化扩展。如果你的 CPU 太老,或者在 BIOS 里没开启虚拟化功能,KVM 是无法工作的。
grep -Eoc '(vmx|svm)' /proc/cpuinfo如果你看到输出是0,说明当前环境没有检测到 AMD-V 或 Intel VT-x。先别急着怪机器,多半是 BIOS 里没有开启虚拟化。重启进入 BIOS,找到 Intel Virtualization Technology 或 SVM Mode,把它设为 Enabled,然后再进系统检查一次。
另外还要确认 KVM 模块是否已经加载:
lsmod | grep kvm正常输出应该包含kvm和kvm_intel(Intel CPU)或kvm_amd(AMD CPU)。如果模块没有加载,可能是内核缺少相关支持或模块被禁用。
3.2 安装虚拟化组件
以 Ubuntu/Debian 系为例,安装命令如下:
sudo apt update sudo apt install -y qemu-system-x86 qemu-utils libvirt-daemon-system libvirt-clients virtinst virt-manager启动 libvirtd 服务并设置开机自启:
sudo systemctl enable --now libvirtd sudo systemctl status libvirtd如果看到active (running),说明虚拟化守护进程已经正常工作。
在 RHEL/CentOS/Fedora 系发行版上,命令略有不同,但关键词一样,安装qemu-kvm、libvirt、virt-manager、virt-install即可。
从材料中看到的“wsl --install 太慢”“wsl 安装 cuda”这类问题在 WSL 社区很常见,而 KVM 方案遇到的第一个问题通常是“为什么 virt-manager 连不上 libvirtd”,多数情况下是当前用户不在libvirt用户组里。把用户加入组后需要重新登录:
sudo usermod -aG libvirt $USER sudo usermod -aG kvm $USER4. virtio 驱动:整个部署过程中最容易翻车的地方
如果说 KVM 方案和 VirtualBox 方案有什么关键区别,那一定绕不开 virtio。
先解释一下:KVM/QEMU 默认可以模拟多种虚拟硬件,比如 Intel e1000 网卡、ide 硬盘、标准 VGA 显卡。这些模拟硬件兼容性很好,但每一次 I/O 操作都要经过 QEMU 的设备模拟层,性能有损耗。
virtio 是一套半虚拟化设备标准。它让虚拟机里的操作系统知道自己是虚拟机,并直接和宿主机 KVM 模块协同工作,而不是模拟一圈硬件再通信。使用 virtio 的虚拟磁盘和虚拟网卡,性能要比纯模拟高得多,特别是在磁盘读写和网络小包传输上。
但 virtio 的代价是:Windows 系统不自带 virtio 驱动。你第一次从安装 ISO 启动 Windows 安装程序时,如果给虚拟机配置了 virtio 硬盘,系统会显示“找不到任何驱动器”。这个问题几乎每个第一次用 KVM 装 Windows 的人都会遇到,也是新手觉得 KVM 难用、不如 VMware 的一个重要原因。
解决方案是提前下载 virtio-win 驱动镜像。这个镜像由 Fedora 项目维护,包含了 Windows 下的 virtio 驱动、QEMU Guest Agent、SPICE 驱动等。通常在搜索框输入virtio-win iso就能找到官方发布地址。
下载后用 virt-manager 把 virtio-win ISO 挂载到虚拟机的 CD-ROM 上,然后在 Windows 安装程序选择磁盘的界面点击“加载驱动程序”,浏览到 CD-ROM 里对应系统版本的目录,就能识别到虚拟磁盘了。
从工程实践角度看,我强烈建议你把这个驱动镜像单独保存好,因为它相当于 Linux 宿主机上 Windows 虚拟机的“驱动光盘”。没有它,你在安装时会卡死、装完系统后网络可能不可用、鼠标切换不流畅、剪贴板不能共享。等到虚拟机已经装好才发现问题,再补救虽然可行,但远不如安装阶段就处理干净。
5. 从零部署一台 Windows 虚拟机的完整流程
为了避免写太多抽象理论,这里直接给出一套能跑通的最小流程。环境假定是 Ubuntu 22.04/24.04 或类似发行版,已经完成第 3 章的环境准备。
5.1 准备 Windows 安装镜像与 virtio-win 驱动
第一个文件是 Windows 的安装 ISO。如果你只是想要一个稳定、流畅的 Windows 环境,Windows 10 的 ISO 目前仍然是兼容性最好、安装门槛最低的选择。Windows 11 也不是不能用,只是它对虚拟化平台有额外要求,比如 TPM 2.0 和安全启动,在 KVM 里需要额外配置虚拟 TPM,步骤又多了一层,首次上手不建议选它。
文件准备好后,推荐把它们放到一个固定目录,比如~/vm/iso/下,方便后续管理。
5.2 使用 virt-install 创建虚拟机
这里给一个命令行创建示例。之所以推荐命令行而不是直接教图形界面,是因为命令行参数一目了然,出问题时也更方便排查。
sudo virt-install \ --name win10 \ --memory 8192 \ --vcpus 4 \ --cpu host-passthrough \ --disk path=/var/lib/libvirt/images/win10.qcow2,size=60,format=qcow2,bus=virtio \ --cdrom=/home/yourname/vm/iso/win10.iso \ --disk path=/home/yourname/vm/iso/virtio-win.iso,device=cdrom \ --os-variant=win10 \ --network network=default,model=virtio \ --graphics spice \ --video qxl各个参数的含义:
--name win10:虚拟机名称,后续 virsh 命令都用这个名称来操作。--memory 8192:分配给虚拟机的内存,单位是 MiB,这里代表 8GB。--vcpus 4:分配 4 个 vCPU。--cpu host-passthrough:让虚拟机直接使用宿主机的 CPU 特性,能获得更好的性能。如果你的宿主机 CPU 不是特别老,这个参数基本不会出问题。--disk path=...size=60,format=qcow2,bus=virtio:创建一个 60GB 的 qcow2 虚拟磁盘文件,使用 virtio 总线。--cdrom=...win10.iso:挂载 Windows 安装镜像。--disk path=...virtio-win.iso,device=cdrom:第二块 CD-ROM,挂载 virtio 驱动镜像。--os-variant=win10:让 libvirt 按 Windows 10 的优化项来配置虚拟机。--network network=default,model=virtio:使用默认 NAT 网络,网卡模型是 virtio。--graphics spice --video qxl:使用 SPICE 协议提供显示,QXL 显卡更适合虚拟桌面场景。
执行后 virt-install 会自动启动虚拟机,并且弹出一个窗口来连接显示界面。如果没有弹出窗口,不必慌张,后面用 virt-manager 也可以打开。
5.3 在 Windows 安装过程中加载 virtio 驱动
这一步是整个安装流程的关键点。
Windows 安装程序启动后,正常走到“你想将 Windows 安装在哪里”这一步时,你会发现磁盘列表是空的。这不是镜像问题,也不是磁盘没创建成功,而是 Windows 不认识 virtio 虚拟硬盘。
此时点击“加载驱动程序”按钮,然后浏览到 virtio-win 的 CD-ROM。在打开的目录中,你会看到多个文件夹,比如amd64、2k19、w10等。不同版本的 virtio-win 镜像目录结构会变,但通常选择带有对应系统版本号或amd64的目录即可。系统会自动搜索子目录里的驱动,识别出 VirtIO SCSI 控制器之类的设备后,磁盘就会出现在安装列表里。
之后的操作就跟在实体机上安装 Windows 没有本质区别:选择磁盘、等待复制文件、设置用户名密码、进入桌面。
5.4 安装 virtio-win guest tools
Windows 进入桌面后,第一件事不是上网冲浪,而是安装 virtio-win 的完整驱动包。打开 CD-ROM 里的virtio-win-guest-tools.exe,一直下一步即可。
这个工具包会完成几件重要的事情:
- 安装完整的 virtio 驱动(网卡、磁盘、气球内存等)。
- 安装 QEMU Guest Agent,让宿主机能安全地执行关机、冻结文件系统等操作。
- 安装 SPICE Guest Tools,让 virt-manager 窗口里的鼠标切换更自然,剪贴板共享和文件拖拽也能正常工作。
没有安装这一步,你可能会遇到图形界面鼠标异常、virt-manager 无法安全关机、宿主机和虚拟机之间无法复制粘贴等问题。这些问题的解决方案只有一个:把 guest tools 装好。
6. 虚拟机日常使用:文件传输、网络访问、剪贴板
虚拟机创建并安装完系统后,不少人的第一反应是“我该怎么把 Linux 里的文件传进 Windows”?这里给出几种从易到难的方案,你可以按自己的场景选择。
6.1 最常见方式:通过内置驱动镜像传文件
如果你平常只是偶尔传一两个小文件,最“无脑”的方法是直接把 virtio-win ISO 或另一个 ISO 文件挂载成虚拟机的 CD-ROM。在 virt-manager 里打开虚拟机的“详情”窗口,进入“虚拟硬件”页面,点击“添加硬件”,选择“存储设备”,然后把设备类型设为“CDROM 设备”,浏览宿主机上的 ISO 文件。Windows 资源管理器里就会出现一个光驱,文件复制进去就完了。
这个方法不需要额外配置 Samba 或 SCP,也不需要知道虚拟机的 IP 地址,适合小文件和一次性文件传输。
6.2 适合大批量文件:使用 SMB / Samba 共享
当你需要频繁在 Linux 和 Windows 之间拷文件时,ISO 方法就显得笨重了。更优雅的方式是在 Linux 宿主机上开启一个 SMB 共享,Windows 虚拟机通过资源管理器直接访问。
在 Ubuntu 上安装并启动 Samba 服务:
sudo apt update sudo apt install -y samba sudo systemctl enable --now smbd然后为你的用户设置一个 Samba 密码:
sudo smbpasswd -a yourname接着在浏览器里进入 Windows 虚拟机,打开文件资源管理器,在地址栏输入:
\\192.168.122.1\share其中192.168.122.1是 libvirt 默认 NAT 网络里宿主机的 IP 地址,如果你的网络配置不同,可以在 Linux 终端用ip addr show virbr0来查看。这种方式比反复挂载 ISO 高效得多,可以像访问局域网共享文件夹一样直接读写。
6.3 剪贴板与拖拽:依托 QEMU Guest Agent
很多人装完 Windows 虚拟机,第一反应是鼠标在窗口里被“锁住”了,按 Ctrl+Alt 才能释放。这是因为你还没有安装 SPICE Guest Tools。安装完后,鼠标移动会像普通窗口应用一样平滑,文本和图片的复制粘贴也能双向工作。
此时 virt-manager 窗口顶部会有菜单栏,在“虚拟机”菜单里可以看到“重启”“强制关机”等选项。这些操作并不依赖 Windows 里的软件,而是通过 QEMU Guest Agent 通知 Windows 系统优雅关机,比直接按电源按钮安全得多,也能避免虚拟机里的文件系统损坏。
7. 性能调优:把 Windows 虚拟机从“能用”调到“好用”
虚拟机装好只是第一步,如果你希望在 Linux 里的 Windows 虚拟机长期使用,性能上还有几个非常值得动手的地方。
7.1 CPU 模式选择
前面 virt-install 创建示例用了--cpu host-passthrough。这意味着 Windows 看到的 CPU 特性与宿主机完全一致。好处是性能最好,某些依赖于特定指令集的应用不会出问题;坏处是如果你后续把虚拟机迁移到另一台 CPU 不同的宿主机上,可能无法启动,因为 Windows 会发现 CPU 变化。
如果你的虚拟机不需要频繁迁移,host-passthrough是性能优先的合理选择。
7.2 磁盘 I/O 优化
磁盘性能是影响虚拟机“流畅感”最重要的因素之一。在 virt-manager 中,可以检查虚拟机的磁盘总线是否为 virtio,如果不是,建议在安装阶段就使用 virtio。
另一个容易被忽略的选项是iothread。为磁盘设备启用独立的 IO 线程,可以让虚拟机的磁盘读写不再占用主 vCPU 线程,在多核宿主机上能明显改善高负载场景下的延迟。如果你的虚拟机不是跑数据库这类超高 IO 负载的服务,这个优化可能感知不强,但打开也没有坏处。
7.3 内存分配原则
给虚拟机多少内存,取决于宿主机还剩多少内存。我的经验值是这样的:一台 16GB 内存的 Linux 宿主机,如果日常只开浏览器、编辑器这些轻量应用,可以给 Windows 虚拟机分配 6GB 到 8GB,办公体验会比较流畅;如果宿主机只有 8GB 内存,那分给 Windows 4GB 是底线,再低就会很明显地卡顿。
Windows 10/11 的默认内存管理比较“贪心”,你给它 16GB 它就能用掉 12GB,这很正常。实际业务卡不卡,主要看你跑的应用是否吃内存,没必要盯着资源管理器里的占用百分比焦虑。
7.4 保持宿主机的 I/O 调度合理
还有一个容易被忽略的点:qcow2 作为一种动态增长、支持快照的磁盘格式,写性能天然略逊于 raw 裸镜像。如果你对性能有较高要求,并且不需要硬件快照特性,可以在创建磁盘时选择 raw 格式:
sudo qemu-img create -f raw /var/lib/libvirt/images/win10.raw 80Graw 格式不支持原生的增量快照,但读写性能更好,磁盘文件占用的空间也是实际大小。如果你更看重快照和回滚能力,qcow2 依然稳妥。
从实际使用体验来说,普通办公场景下两种格式的性能差异并不明显,但在持续的磁盘写入场景下,raw 会有一定优势。
7.5 让 Windows 虚拟机也能“按需关机”
vm 使用完以后,不要直接在 virt-manager 里点“强制关机”。最安全的方式是进入 Windows 系统,像实体机一样点“开始 - 电源 - 关机”。如果自动化场景需要远程关闭虚拟机,可以使用:
sudo virsh shutdown win10如果 Guest Agent 正常工作,这个命令会像用户点击关机一样,让 Windows 优雅退出。如果 wait 一段时间后还没关闭,再考虑用virsh destroy,但那是最后的手段,不建议一开始就当作常规操作。
8. 常见问题与排查思路
从真实使用来看,KVM 方案出问题最多的环节往往集中在安装阶段和驱动层面。这里整理了一张排查表,可以帮你快速定位问题。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| virt-manager 提示无法连接 libvirtd | 当前用户不在 libvirt 用户组 | 执行id查看用户组;确认是否重新登录 | 将用户加入 libvirt 组后重新登录 |
| Windows 安装程序找不到磁盘 | 没有加载 virtio 驱动 | 进入安装界面看磁盘列表是否为空 | 挂载 virtio-win ISO,在安装界面点击“加载驱动程序” |
| 虚拟机窗口鼠标被锁定,无法流畅切换 | 缺少 SPICE Guest Tools | 查看系统托盘是否有 spice-vdagent | 安装 virtio-win-guest-tools.exe |
| 虚拟机启动后黑屏 | 显卡类型或 SPICE 协议配置异常 | 查看 virsh 图形配置 | 改用 QXL 显卡或切换显示协议为 Spice |
| Windows 系统能启动但网络不通 | 网卡模型不是 virtio 或驱动未装 | 在设备管理器中查看网卡状态 | 安装 virtio 驱动,或把网卡模型改为 e1000e 作为临时方案 |
| 开虚拟机后宿主机响应变慢 | 内存或 CPU 分配过高 | 查看宿主机free -h和top负载 | 降低虚拟机内存分配,或限制 vCPU 数量 |
| 宿主机重启后虚拟机无法自启 | libvirt 默认不会自动启动虚拟机 | 使用virsh list --all查看状态 | 执行virsh autostart win10 |
| 虚拟机磁盘文件越来越大 | qcow2 不会自动回收已删除的空间 | 在 Windows 里查看磁盘是否可回收 | 在虚拟机内执行 Trim/优化驱动器,然后在宿主机执行 qemu-img 压缩操作 |
很多问题的根源可以归结为一句大白话:Windows 虚拟机其实也是一台真实的“电脑”,它同样需要驱动、需要安全关机、需要空闲空间回收。你用实体 Windows 时的维护习惯,在虚拟机里基本都适用,只是多了一个宿主机层面的管理入口。
9. 与 WSL 的对照:Windows 和 Linux 之间的距离到底有多远?
文章写到这里,值得把话题拉回到开头那个“LSW”的概念上。
为了更直观地展示两份“反向”需求之间的差异,我把 WSL 和 Linux 上的 Windows 虚拟机放到一张表里对比:
| 对比维度 | WSL(Windows 里的 Linux) | Linux 里的 Windows 虚拟机 |
|---|---|---|
| 最开始解决什么问题 | Windows 开发者需要 Linux 命令行和工具链 | Linux 用户偶发需要 Windows 软件或测试环境 |
| 完整度 | 没有完整图形桌面的 Linux 环境 | 完整 Windows 桌面环境 |
| 性能开销 | 轻量级虚拟机,性能好,资源占用低 | 完整虚拟化,性能较好,资源占用较高 |
| 文件互通 | 跨文件系统访问非常方便 | 依赖网络共享或 SPICE 通道 |
| 安装难度 | 微软官方支持,一条命令即可 | 需要下载多个 ISO、处理驱动,步骤多 |
| 底层技术 | Hyper-V / 轻量虚拟机 | KVM / QEMU / libvirt |
WSL 之所以流行,很大程度上是因为微软把它做成了 Windows 的原生功能,安装命令简单、文件互通顺畅、开发者工具链适配度高。而在 Linux 上跑 Windows,你面对的则是一个“标准虚拟机”,它没有任何厂商为你做整合优化,一切都得自己配置。
但这并不意味着在 Linux 上跑 Windows 虚拟机是一件低价值的事。恰恰相反,当你需要一台完整、独立、可快照的 Windows 环境时,KVM/QEMU 这套组合的稳定性和性能远超普通的 Type 2 虚拟机方案。VirtIO 驱动一旦装好,你会发现这台虚拟机的磁盘吞吐和网络吞吐都很接近真机,Windows 的日常使用体验完全可以接受。
还有一点需要特别提醒:不要用这篇文章介绍的技术去做任何涉及非授权软件或破解激活的事情。Windows 系统的授权问题请遵守微软的相关规定。虚拟化技术本身是中性的,文章的落脚点是帮助你合法、高效地完成跨系统工作流。
10. 对你的实际建议
如果你看完这篇文章,决定在自己的 Linux 机器上动手试试,我的建议是:
- 不要一开始就追求复杂配置。先用 virt-manager 图形界面创建一台 Win10 虚拟机,安装完成后把 virtio 驱动和 guest tools 一次性装全,先感受一下“Windows 跑在 Linux 里”到底是什么体验。
- 创建虚拟机时优先使用 qcow2 磁盘格式并开启快照功能。装好 Windows 后、安装任何非必要软件之前,先做一个干净快照。后续如果系统被折腾坏,直接恢复快照,比重新安装省太多时间。
- 文件传输尽量选 SMB 或 SPICE 的通道。这是最接近“Windows 里访问网络磁盘”的体验,能避免反复挂载 ISO 的笨拙操作。
- 如果只是为了运行某一个 Windows 小软件,先试试 Wine 或 Bottles。如果能跑通,就不必为它维护一台完整虚拟机;如果跑不通,再回头考虑 KVM。
- Windows 虚拟机也要定期更新系统补丁和 virtio 驱动。相比物理机,虚拟机更容易被忽略维护,但安全更新同样重要。
从 Linux 到 Windows,再从 Windows 到 Linux,这种来回切换的工作流在今天的开发环境里越来越常见。WSL 代表的是微软迎合开发者的姿态,而 KVM/QEMU 则证明了 Linux 在虚拟化领域的技术纵深。对普通开发者来说,理解“Linux 内核本身就能当虚拟机监控器”这件事,比记忆一堆安装命令更值得。它能帮助你判断:哪些“系统切换”问题是配置问题,哪些是方案选型问题。
希望这篇文章能帮你少踩几个坑。如果你按照文章流程成功跑起来了一台 Windows 虚拟机,建议顺手做一个快照,再把本文收藏一下,遇到问题时方便回来对照排查。