虚拟化技术和模拟技术等

大致分类图 (svg)

第一类和第二类虚拟化

Hypervisor 虚拟机监视器，用于创建和管理虚拟机

Type-1（裸金属型）： Hyper-V、ESXI、KVM。所有的操作系统都要虚拟化，包括当前的操作系统。Hyper-V 一般损失 1%，最大 5%。

Type-2（寄居型）：Vistual Box、WMWare，即向宿主操作系统申请资源

第一、二类虚拟化同时使用？

以前好像确实是不可以的，即安装了 Docker，因为会依赖 WSL2，所以打开了 Hyper-V，导致 VMWare 不能用了

但现在好像可以了，即 VMWare 不需要直接请求占据 CPU 的虚拟化接口，而是微软又搞了个兼容层接口，转调 Hyper-V

即 Docker 和 VMWare 可共存

基本上你最多套两层，虚拟机 Linux 里再装 Docker 也不是虚拟化了

做 GPU 计算，基本上就是 Docker(WSL2)

Docker

Docker Desktop 默认会创建一个名为 docker-desktop 的 WSL 发行版，用于运行 Docker 守护进程和容器。这时候，即使启动多个容器，它们其实都是在同一个 Linux 内核下运行的，通过 Docker 的守护进程管理，而不是每个容器单独一个 WSL 实例。因此，所有容器共享同一个 Linux 内核，但彼此隔离，就像在普通的 Linux Docker 环境中一样

翻译层

这种实际上不算是虚拟机，因为它并不需要虚拟出整个操作系统

只是把目标软件执行的语句，在用户空间做替换

WSL1

WSL1 是 微软把 linux 的命令翻译为了 windows 命令，因此没有真正的 Linux 内核，而且维护起来比较麻烦，所以放弃了

WSL2

开启 WSL2 的前置条件是开启 Hyper-V

WSL2 是基于 Hyper-V，在这上面运行 真正的 Linux

你再在 Hyper-V 里安装其它 Linux，它不是 WSL

WSL 是一个特殊的，由 Windows 代为管理的虚拟机，它借助了 Hyper-V，但是你在 Hyper-V 的管理器面板上是无法看到的

同时，WSL 里，不是只能安装 Docker，也可以安装别的 Linux，即多个实例

C:\Users\your-name>wsl --list -v
  NAME              STATE           VERSION
* docker-desktop    Running         2

这里带 * 的是默认的

即：

底层是 1 个 WSL2 的轻量 VM（不在管理面板里）

上面挂着多个发行版实例，其中 docker 运行在叫做 docker-desktop 的实例里

如果你想，你也可以再继续安装实例，但不是像你在 Hyper-V 面板里部署的完全独立的 VM

Docker

Docker Desktop 默认会创建一个名为 docker-desktop 的 WSL 发行版，用于运行 Docker 守护进程和容器。

这时候，即使启动多个容器，它们其实都是在同一个 Linux 内核下运行的，通过 Docker 的守护进程管理，而不是每个容器单独一个 WSL 实例。

因此，所有容器共享同一个 Linux 内核，但彼此隔离，就像在普通的 Linux 环境中一样。

Hyper-V

家庭版无法使用

GPU 默认是不共享的，所以虚拟机实际上没有 GPU，只有核显，能跑 OpenGL 的程序

两个 Windows 之间，不支持拖拽复制文件，但是支持 右键/Ctrl-CV 复制粘贴

网络拓扑更改请看网络拓扑那篇文章

PVE Proxmox Virtual Environment

开源，这是一个完整的操作系统（基于 Debian），它自带了 KVM 并且集成了 QEMU 以及 LXC（容器），而且有一个界面。

它直接装在物理机上，上面再装各种系统，所以称之为 type-1。有点类似 hyper-v 的管理主机的意思，一般自己折腾就用这个

KVM Kernel Based Virtual Machine

Linux 内核的一部分。

可以让 Linux 内核做虚拟化层，让虚拟机直接提交到物理 cpu 上。一般搭配 QEMU 使用，属于大型服务器可能考虑的东西。

之所以在图里，没有给 KVM 归类，是因为它的界限比较模糊

qemu

读法：Q 鸸鹋 ？

QEMU 有两种工作模式

第一种是，纯软件级别模拟，可以模拟任何东西，但是慢，使用 TCG 软件翻译。在这种情况下，它不属于第一或者第二类虚拟化技术

第二种是，搭配一个加速的后端，比如 KVM。这样就是说，QEMU 泡在用户进程里，模拟一些虚拟的设备（比如磁盘、网卡），然后指令则转交给 KVM 的接口，进行加速

Rosetta

Rosetta 2（2026 年的版本）

它是转译，老 Mac 上，x86_64 的代码。即方便应用从 Intel Mac 迁移到 M 系列 Mac。Windows 上对标的技术叫做 Prism

它不属于第一类/第二类虚拟化技术，因为它只是做指令集的转换，即它不需要模拟另一个操作系统，因为软件本来就是为 x86_64 的老 Mac 开发的。所以它的效率很高

那种虚拟化技术，都是模拟另一个完整的操作系统的

备注：直接下载 steam，要求安装 Rosetta2，steam beta 版才是原生 arm，不然是 x86。

CrossOver、Wine

Wine 是 Valve 公司最著名的开源项目，用于在 Unix 上模拟 Windows 的 API。（根据 Oracle 和 Google 关于 Java 的官司，模拟 API 并不构成侵权）

CrossOver 它是 codeweavers 公司的一个项目，而且它是收费的（它的 GUI 壳子闭源收费，内核开源），所以你要么买，要么盗版

它也是转译，但是转译的是，Windows 上的 x86_64 代码。即它也不是一个完全虚拟一整套操作系统的东西，它是基于 Wine 来模拟 Windows 的 API。

proton

proton 是一个继承了 wine 在内的多种工具的兼容层，本质也是基于 wine

类似 wine + dxvk + Fsync（支持同步原语）

你不需要折腾，你只需要在 Steam 里开始游戏，一切就会自动跑起来

唯一的问题是反作弊

GPTK Game Porting Toolkit

之前提到的 Rosetta 它只能转换 CPU 指令，但是无法转换 GPU 指令，所以苹果又做了一个 DirectX 的转换层，转换成 Metal

苹果现在强推 Metal，是因为 Metal 能更好的调用它的 A/M 系列芯片性能。至于 OpenGL，停在古早版本就不再升级了。

parallels desktop

它是一个付费软件，但是据说和苹果关系密切，性能要比目前免费的 VMWare Fusion 好。

然后在 macOS 上，你也可以再虚拟一个 macOS，动画依然流畅

因为 macOS 做了一个显卡直通的功能，虚拟机可以直接提交指令给真实的 GPU。类似俩系统共用 GPU。

mac 上虚拟 Windows，一般主流虚拟出的 Windows 都是 ARM 的。这也和你在 x86 Windows 上弄 hyper-v 跑 x86 的 Linux 一样，同架构很好虚拟，性能损失很小。

一般不建议虚拟 x86 的 Windows，这很卡。如果你要跑 x86 的程序，考虑用 CrossOver。

UTM

UTM 是在 macOS 上包装了 QEMU 的一个 GUI 程序，避免你命令行配置复杂参数

手机游戏模拟器

我们考虑在 Amd64 的 Windows 上跑 Arm 的 Android 游戏 或者 Switch 的游戏

1、我认为它会虚拟出一些设备，比如 wifi、gps、系统通知（有点模拟器可以打开消息栏）

这块问 AI 感觉容易开始胡编，我自己通过以前的经验，以及 b 站评论区的现状。

看起来很多模拟器是和 Hyper-V 冲突的

2、它应该需要做 GPU 直通，这里是什么技术？

3、跨架构模拟，应该会很损失性能。比如 Rosetta2，Prism 都是 risc 去模拟 cisc，但是现在是反过来。

x86 是强内存模型 (TSO): 它对指令执行的顺序约束非常严，CPU 不太敢乱动读写顺序。

ARM 是弱内存模型 (WMO): 为了省电和效率，ARM 允许 CPU 在不影响逻辑的前提下大幅度重排指令顺序。

一般来说，从 x86 模拟 arm 是更简单的。

当 ARM 去模拟 x86 时，必须保证 ARM 表现得像 x86 一样“死板”。Apple 为了解决这个问题，在芯片里直接加了一个硬件开关，开启后 ARM 核心会强行切换到 x86 的内存排序规则。这是 Rosetta 2 性能封神的关键。

Switch 模拟器

【施工中】

Switch 的系统被称为 Horizon OS，并不是 Linux 或者 Android

Switch 使用的是标准的 ARMv8 架构

一个 Dynarmic 的 JIT 引擎，用于解释 CPU，然后还需要有一套东西翻译 GPU

但是它不需要跑起 Horizon OS，它是用 C++ 重写了一套和 Horizon 一样的系统服务。

HLE（High-Level Emulation）：高阶模拟

Cygwin 与 MSYS 与 mingw

从历史角度一步步谈起：

Cygwin 是一个巨大的 DLL，它将一切的 POSIX 指令翻译到 Win32API（与 Wine 有点相反的感觉），此时 bash make 等工具就可以运行在 Windows 上了。这是最开始的工具，也就是直接让 Linux 软件迁移到 Windows，先跑起来

然后，人们觉得，这样做兼容层是不是不太好？我们直接写一个编译器，让 gcc 直接跑在 windows 上。这称之为 MinGW，Minimalist GNU for Windows。它是可以用 windows.h，但是只支持一部分 posix 的头（后来它自己做了一些模拟）

你可以认为 MinGW 是做了类似于 MSVC 里 cl.exe 的功能，但是其它工具链，都要换成 GCC 相关的，比如 make，而不是 msbuild

然后 MSYS 就出现了，MSYS 就是打包了 Cygwin（做了一些简化） 和 一套编译器，这样在 MSYS 里编译出一个 exe，它直接调用 win32API。在这里，你可以直接 make，直接写 posix 头文件，但是出一个原生的 exe

MSYS 它不是交叉编译，因为它就在 Windows 上编译 exe，只有目标和主机不同才是，比如 Linux 编出 exe（用 MinGW-w64）

用 MinGW、MSYS，大概率只是说明想用 GCC 这套工具链，而不是为了跨平台移植。你不能指望你只写 posix 程序，而某个工具给你一下子编出来原生 exe

附录

图片代码：

tech: 技术
BMS: 裸金属服务器（租用）
VMM: 虚拟机 HyperVisor VMM
type1: 第一类虚拟机
type2: 第二类虚拟机
trans: 翻译
syscal_trans: API、系统调用翻译
arch_trans: 架构翻译
container: 容器化
emu: 硬件级模拟

tech -> BMS
tech -> VMM
tech -> trans
tech -> container
tech -> emu

VMM -> type1
VMM -> type2

trans -> syscal_trans
trans -> arch_trans

type1 -> Hyper-V
type1 -> VMWare ESXi
type1 -> PVE

type1 -> "KVM + QEMU"
type2 -> "KVM + QEMU"

type2 -> VMWare WorkStation
type2 -> UTM
type2 -> Parallels Desktop for Mac

syscal_trans -> Wine
syscal_trans -> CrossOver
syscal_trans -> GPTK
syscal_trans -> WSL1

arch_trans -> Rosetta(Mac)
arch_trans -> Prism(Win)

container -> Docker

emu -> 纯 QEMU