Why do I need to do this

公司提供VDI作为办公环境，远程办公时，需要通过VPN先连接到公司内网，再从内网连接到办公VDI。
公司提供了Mac和Windows的VPN客户端用于连接到内网，按理说安装并使用公司提供的客户端连接内网即可，但是之所以没有这么做有两个主要原因：

• 公司提供的VPN配套的软件太过臃肿；
• 公司提供的VDI内置了访问控制软件，会记录IM的聊天记录等信息。担心VPN“附赠”的软件或者VPN本身会做类似的操作🙄。

这篇博文主要记录下折腾虚拟桌面环境的一些经历。

What attempts did I try

由于上面说的原因，需要在个人PC环境之外，提供一个桌面环境用于远程连接到VDI。
再去配置一套物理桌面环境显然是不现实的，所以主要向虚拟桌面环境考虑：

• Windows Sandbox
• Cloud Virtual Mechine
• Reverse Proxy (frp)
• MacOS Container

Windows Sandbox

Windows Sandbox是一个非常好的选择，它是Windows内置的虚拟化技术，在Windows 10的专业/企业版中打开选项后可以直接启动。
该技术和通用的虚拟化技术一样，对CPU的虚拟化特性也有一定要求，不过不是太老的CPU应该都能够满足要求。在我个人的移动端4代i7、8G内存的PC上，Windows 10和Windows 11中，Windows Sandbox都有足够好的表现。因为它只是虚拟了一套运行环境（runtime environment），应该是WIndows自己的容器化技术。相比于直接运行一个虚拟机而言，轻量的多，同时它还支持GPU虚拟化，从实际使用体验上来看，Sandbox的启停都足够快，同时图形性能对于基本办公足够使用了。
但它有个明显的弊端：所有在Sandbox中所做修改都不会被保存，将会随Sandbox进程的退出一并被销毁（类似于加了--rm参数的docker容器🤨）。这个特性提供了绝对的Sandbox环境，但和我个人的使用场景上并不是完全契合，每次需要连接VDI时都要全新安装一整套的VPN软件，不过总体来说从使用难度和使用体验上来说，还是相对不错的。
没有最终使用这个方案的原因主要是因为我的Windows PC坏了😅。

Cloud Virtual Mechine

Windows PC坏了以后，开始转战MacOS。虚拟机是一个常见的能够提供虚拟桌面环境的方式，由于MacOS的软件生态（主要是💰的问题），没有选择直接在MacOS上运行虚拟机，转而考虑公有云提供的虚拟机服务，正好看到腾讯云有轻量应用服务器的优惠，且支持Windows系统，遂马上下单。
但当真正使用这个虚拟机时发现，公司提供的VPN客户端不支持在Windows Server安装（垃圾🙃），同时这个轻量应用服务器不支持自行上传镜像安装系统，所以没法直接重装成个人版的Windows。
但，买都买了，还是折腾下吧。

Nested Virtualization

第一个尝试是虚拟机，没错，是在1核2G的虚拟机上再跑一个Windows虚拟机。
基于如此拉胯的硬件配置，Host必不可能选Windows了，所以重装成了CentOS。然后就是supervisor的选择，工作中用的比较多的是QEMU-KVM，相对比较熟悉了，所以尝试换用Virutal Box。
虽然Virutal Box是Oracle主导的开源项目，但官网就给人一种贫穷的感觉。它主要运行在桌面环境上，虽然提供了命令行工具VBoxManage，但在命令行环境下仍然需要安装一些如QT相关的依赖库。不幸的是在解决了依赖问题，配置好虚拟机后，仍然无法启动，报错是无法启用硬件加速特性（腾讯云的这个虚拟机不支持嵌套虚拟化），在配置里取消了所有硬件加速的选项后，还是无法解决该问题（MacOS上的Virtual Box也是一堆BUG），无奈只能放弃Virtual Box。
于是换用QEMU，直接使用yum安装，使用libvirt进行虚拟机配置，由于不支持嵌套虚拟化，同样没法使用QEMU-KVM，只能通过纯模拟的CPU运行GuestOS，虽然能够运行，但是几乎完全无法正常使用，开机需要15min，开机之后所有的操作都是分钟级别的，就是折腾来玩玩罢了。

Dual Operation System

这个配置下的嵌套虚拟化也就图一乐，既然官方给的镜像不包含个人版的Windows，同时也不支持自定义上传镜像，那就采用安装双系统的曲线救国的方式。
先使用原有分区的空闲空间创建一个新的分区，再将操作系统镜像下载到硬盘上，直接从硬盘运行安装程序，将操作系统安装到新的分区上。
为了在1核2G的拉胯配置上尽可能流畅地运行Windows，使用Tiny7（精简版的Windows 7）作为使用的操作系统，但镜像内不包含Virtio驱动，无法继续安装。下载了几乎所有版本的Virtio驱动在安装时使用，但全都无法奏效，最后无奈换用了Tiny10（精简版的Windows 10）。使用Tiny10后，在安装时选择硬盘上已有的Virtio驱动，即可完成正常安装。
流畅度上来说和自带的Windows Server相比没有明显差距，在远程连接上VDI后，由于自身配置拉胯，流畅度一般。且由于没有显卡，在需要图形渲染的场景下（如窗口切换），卡顿明显。总的来说属于勉强可用的程度，但好处是无需在自己的PC上运行虚拟机。

Windows Container

Windows Container是考虑过的另一个折腾方向，Windows官方提供了镜像，但在Windows Server安装Docker时，始终有问题无法解决，同时Windows容器只能使用和Host相同的kernel，并且无法提供一个基于容器的桌面环境，遂放弃。

Reverse Proxy (frp)

使用反向代理（如frp）将Windows远程控制服务暴露到公网也是一个可行方案，但细节上没有那么简单。
由于办公VDI是和公网隔离的，所以无法直接使用反向代理直接连接到办公VDI。但公司提供了外网VDI用于在办公时访问公网，可以使用反向代理连接到外网VDI，再在外网VDI中安装运行VPN客户端后反向连接到办公VDI内。
这种方案下的外网VDI代替了自购的公有云虚拟机，拥有更高的配置，但同样不支持虚拟显卡，图形性能仍然拉胯。按理说可以替代自购的公有云虚拟机了，但由于安全部门审计到frp流量，告知不允许使用此类反向代理，遂放弃。

MacOS Container

在考虑虚拟化方案时，觉得虚拟机消耗过大后，很容易想到的就是容器技术。如果使用容器技术能够满足需求，那就能够使用一个轻量化的隔离环境。在我只有MacOS的前提下，开始查找是否有MacOS的容器化方案。
幸运的是，还真有个项目Docker-OSX，不幸的是，这个项目基于QEMU-KVM，说白了还是虚拟机那一套，所以也就是看了看而已。

What did I chose finally

由于上述种种原因，最终的使用方案是在公有云自购的虚拟机上安装的双系统中，连接到远程VDI。
如果有Windows环境的话，还是推荐使用WIndows Sandbox；MacOS环境下，如果能够容忍虚拟机的性能消耗的话，虚拟机应该是一个比较好的选择。
相比之下，在公有云上的拉胯虚拟机中连接到远程VDI的方案并不是什么理想方案了。