一次关于 WSL、虚拟化、直通设备和架构边界 的真实踩坑记录。
一、起因：我只是想装个 Ubuntu
事情的起点非常简单。
在一台 ESXi 上，我有一个 Windows 10 虚拟机，
平时做一些开发、测试、网络相关的事情。
想着：
“Windows 上用 Linux 最方便的不就是 WSL 吗？”
于是我下载了：
ubuntu-24.04.3-wsl-amd64准备直接来一个 WSL2 + Ubuntu 24.04，
系统新、体验好、还省一个虚拟机。
二、第一脚坑：WSL2 装不上
安装过程中，报错很直接：
当前计算机配置不支持 WSL2
HCS_E_HYPERV_NOT_INSTALLED提示内容包括：
未启用虚拟机平台
未启用虚拟化
Hyper-V 不可用
第一反应是：
“是不是 Windows 功能没开？”
于是按流程：
启用 WSL
启用 Virtual Machine Platform
重启
结果：
依然失败。
三、第二脚坑：ESXi 的嵌套虚拟化
这时候才意识到一个事实：
WSL2 本质上是一个 Hyper-V 虚拟机
而我现在的环境是：
物理机
└─ ESXi
└─ Windows VM
└─ 想再跑一个 Linux VM（WSL2）这意味着：
嵌套虚拟化（Nested Virtualization）
于是我尝试在 ESXi 中开启：
Expose hardware assisted virtualization
vhv.enable = "TRUE"
四、致命一击：PCI Passthrough 冲突
就在我准备“胜利在望”的时候，
ESXi 给了我一个非常冷静、也非常残酷的错误：
具有 PCI 直通设备的虚拟机不支持嵌套硬件辅助虚拟化这句话翻译成人话就是：
这台虚拟机已经用了 PCI 直通，
就别想再当 Hypervisor 了。
ESXi 的规则是硬性的：
✅ PCI Passthrough（网卡 / 显卡 / SR-IOV）
❌ Nested Virtualization（Hyper-V / WSL2）
二选一，没有妥协。
五、这时我才真正问了一个对的问题
折腾到这里，问题已经不是：
“这个报错怎么解决？”
而是变成了：
“WSL 到底是什么玩意？”
六、WSL 的真实定位（很多人误解了）
WSL1
不是 Linux
是系统调用翻译层
本质是：能跑 bash 的 Windows
WSL2
是 真·Linux 虚拟机
运行在 Hyper-V 上
目标是：
给本地 Windows 开发者一个丝滑的 Linux 开发环境
关键点在于：
WSL 从来就不是为服务器、不是为 ESXi、不是为复杂网络设计的。
七、为什么在“对的地方”WSL2 非常丝滑？
如果你是在：
本地物理 Windows
没有 PCI 直通
不做嵌套虚拟化
用来写代码、跑 Docker、做开发
那 WSL2 的体验是：
启动快
资源自动伸缩
VS Code 深度集成
Docker Desktop 极其顺
👉 这是 WSL2 的主战场。
八、为什么在我这里，它只剩下“坑”？
因为我的真实需求是：
ESXi 环境
已经用了 PCI 直通
做网络 / WireGuard / OMR
systemd、iptables、路由、MTU
甚至长期跑服务
而这些，全部踩在 WSL2 的反面用例上。
WSL2 的网络结构是：
Linux (WSL2)
↕
Hyper-V vSwitch
↕
Windows NAT你几乎无法：
精准控制网络
理解数据包路径
做复杂调试
九、最终结论：不是技术问题，是方向错了
这次踩坑最大的收获不是：
“我终于把 WSL 装上了”
而是这个结论：
WSL 是桌面开发工具
Linux VM 才是服务器与基础设施工具
在 ESXi 里继续折腾 WSL，
本身就是一种方向性错误。
十、现在我怎么做（正确解）
最终的结构非常朴素，也非常稳定：
ESXi
├─ Ubuntu 24.04 VM ← 干活（Docker / 网络 / 服务）
│ ├─ WireGuard
│ ├─ systemd
│ ├─ iptables
│ └─ OMR / K8s
│
└─ Windows VM（直通保留） ← 管理 / GUI / 工具
从那一刻开始：
不再纠结 WSL 报错
不再和 Hyper-V 打架
网络问题一眼就能定位
世界突然清净了
十一、一句送给后来人的话
WSL 很好，但它有边界
虚拟化也很强，但层级不能乱叠
如果你在：
ESXi
云服务器
直通设备
网络实验
长期服务
别再问“WSL 能不能装”，
直接装 Linux VM。
那不是退而求其次，
那是走在正确的路上。