如何才能让你的 Windows 上的 VMWare 和 WSL 2 等共存

在 WSL 1 内，内核功能其实是不完整的，这也直接导致了很多东西并不能够在 WSL 1 上顺利地跑起来，而同样的问题在 WSL 2 上就不会再出现了。
很多朋友虽然有打算转到 WSL 2，但是考虑到在实际开发的过程中，有的东西可能还是需要放到虚拟机这种完全独立、隔离，而且能够基于快照很容易进行还原的环境里跑，所以开发者还是需要用到 VMWare、VirtualBox 之类的工具。

而众所周知，VMWare、VirtualBox 在虚拟化上和 Hyper-V 存在冲突，以至于如果你想使用 Docker、WSL 2 等工具，那么你必须要卸载掉机器上的 VMWare，或者在使用 Docker、WSL 2 的时候启用 Hyper-V，在使用 VMWare 的时候再禁用 Hyper-V。
这种冲突给开发者带来了不小的麻烦，因为系统配置总是需要更改，而更改就需要重启。很多原先使用 WSL 1 的开发者因为这个冲突没有选择升级到 WSL 2，毕竟他们真的对虚拟机和 WSL 都有很强的依赖，他们并不希望做这种「二选一」的选择，他们的选择是「我全都要」。

为了解决这个兼容问题，微软也是做了不少的努力。他们称会在 WSL 2 正式推出（也就是 Windows 10 2004 正式推出）之后解决这个兼容性的问题，然而这个问题并没有能够在 Windows 10 2004 早就进入正式阶段的时候解决，直到最近，事情才有了转机。
VMWare 宣布他们实现了和 Hyper-V 的兼容，你可以在使用 VMWare 的时候运行 WSL 2，同样，QEMU、VirtualBox 也实现了对 Hyper-V 的兼容。
想要让你的虚拟机和用到了 Hyper-V 的功能、工具不冲突，首先你需要确保你的系统是 Windows 10 2004（版本号不低于 19041.264），其次你使用的虚拟机软件版本至少要是下面列出的版本：

VMWare WorkStation Pro 15.5.5
VirtualBox 6.1.4
QEMU 2.12
这个兼容的方式虽然大家都没有提到，但是根据各种资料，其实是可以猜到各家是怎么是先兼容的。不得不说的是微软的能量还是相当大，实际上 Hyper-V 本质上还是和这些虚拟机软件本身实现虚拟化的方式冲突，这个冲突本身并没有解决。

大家采用的兼容方案实际上是一种「曲线救国」的方式。微软在去年释出了一个名为 Windows Hypervisor Platform 的东西，它在系统内添加了一套 API，这一套 API 可以允许其他应用使用 Hyper-V 的功能，基于 Hyper-V 实现虚拟化。
这个东西本身是率先暴露给 Xamarin 这样的开发工具使用的，让他们可以很轻松地基于 Hyper-V 打造一个能够运行 Android 的模拟器，使这一套开发工具能够更好地和 Visual Studio 集成，给开发者带来更好的开发体验。
可没想到的是，这一套 API 的开放成为了微软如今解决虚拟机软件共存问题的「关键」。实际上各家实现的兼容更多是让自己的程序和微软的这一套 API 对接，通过这一套 API 调用 Hyper-V 实现虚拟化，而不再是采用自己的那一套虚拟化的方式。
简单来说就是，你看到的东西没换，运行虚拟机的核心已经悄悄地换掉了，大家其实都在用 Hyper-V，所以当然就能够兼容了。
那么问题来了，在这种兼容模式下，虚拟机的运行会不会受到影响呢？WSL 2 等工具的运行是否稳定呢？

经过笔者的实测，虚拟机和 WSL 2、Docker 等共存是没有问题的，虚拟机本身和 WSL 2、Docker 的运行都没有什么问题。
哪怕你在这种兼容模式下运行一个 macOS 虚拟机，它的运行也不会遇到什么问题，兼容确实是实现了的，你可以很放心地在使用 WSL 2 的同时使用 VMWare 等。
但是，虚拟机本身并不是和 Hyper-V 完全兼容的，以 VMWare 为例，你需要去掉虚拟机设置中虚拟化引擎的前两项。

道理也很简单，因为虚拟化这个东西实质上已经不是 VMWare 自己在管理了，它只是在调用系统的 API 去做虚拟化，所以自然而然在引擎方面它也不能实现对 CPU 性能计数器的虚拟等。

实现兼容和不实现兼容对于虚拟机的实际运行还是会产生一定影响的，如果这个设置会干扰到虚拟机的正常使用，那么你还是需要靠关闭 Hyper-V 来规避兼容问题。
如果你有遇到「Moniter Mode」不能正常启动的错误，那么与一定是虚拟机设置内的这两个设置项存在问题。之前已经创建的虚拟机是不需要重新创建的，调整设置之后就可以直接开机，没有任何问题。
另一点需要注意的是，这个兼容并不包括 Windows 沙盒。Windows 沙盒本身又是一个很特殊的存在，它之所以可以很快地启动一个纯净的、全新的 Windows，是因为它也用到了虚拟化的技术，直接通过 Hyper-V 再运行一个 Windows 内核。

然而，这会造成一些问题。Windows 沙盒的技术来源于企业级的容器技术。系统内核的绝大多数文件其实是和可以和沙盒共享的，所以 Windows 实际上只需要运行一个很小型的镜像就可以启动沙盒，沙盒所用的很多系统文件其实是直接关联到了系统本身的文件上。
配合微软打造的一套内存管理、内核调度、GPU 虚拟化等机制，Windows 沙盒不但性能高、启动快，而且可以做得非常轻量。
由于沙盒和系统本身共用了文件来创造虚拟机，根据一些说法，这会使得系统本身并不是运行在一个完全原生化的状态上，系统本身其实已经被放到了 Hyper-V 之中，由一套两个系统内核外部的环境进行各种调度。
在本文提到的兼容问题上，Windows 沙盒的启用会引起不少奇怪的兼容问题，比如网络，启动了 Windows 沙盒可能会导致你的程序无法正常绑定端口或者正常释放端口，只有重启系统问题才能能够解决，这可能是一些内核级别的 Bug 导致的。端口其实并没有占用，但是程序就是没有办法正常绑定。
就笔者个人的实践来说，只有关闭 Windows 沙盒能够有效地解决网络端口不正常的问题。

目前笔者没有测试过的是类似于 360 核晶防护这一类同样基于 VM 技术实现的是否也会引起一些兼容性的问题，如果你遇到了其他奇怪的兼容问题，那么你可能要考虑一下是不是安全软件的这类功能造成的。
总体来说至少 VMWare 能够和 Hyper-V 一系的东西实现兼容，这一点还是很让人开心的，毕竟 VMWare 确实是很好用的虚拟机软件，而 WSL 2、Docker 等也确实是很好用的工具，没有什么能够比兼得还要更美好的了，哪怕存在一些小不足，但是这都是可以接受的。