读My VM is Lighter and safer than your container博客分析

一： 背景

由于容器因与虚拟机相比具备轻量、高效性而广受欢迎。但因容器技术提供的隔离性不强，相比虚拟机技术面临着更多的安全性问题，而目前通过在虚拟机上运行容器来达到合适的隔离性。作者对是否一定需要在高效与安全之间做出取舍做出了探究，最终发现只要虚拟机足够小且其工具栈足够快，那么虚拟机也能像容器一样灵活部署。论文中提出LightVM，一种基于Xen的新虚拟化解决方案，无论有多少活动的VM，其都能做到快速启动。相比Linux下fork/exec启动一个程序的1ms时间，LightVM需要2.3ms，这两种的启动时间都比Docker更少。LightVM可以在modest硬件上打包成上千的LightVM客户机，并且其内存和CPU使用率与进程相当。

二：作者要实现的目标

1. .快速启动：
容器通常可达到秒级甚至毫秒级的启动时间，而虚拟机往往需要数十秒甚至数分钟才能启动
2. .高实例密度：
在一台机器上面可以部署超过1000台的虚拟机。
3 .暂停/恢复：
容器实例拥有快速暂停/恢复的能力，这使得其对系统资源的利用更加出色

三：关于Lightweight VMS的讨论

作者认为，完成目标第一步就是，要缩小虚拟机的镜像和运行时内存占用大小。
同时作者在论文中讨论了两种类型的虚拟机：Unikernels和Tinyx。

1.：Unikernels
Unikernel是近年来出现的一种新的内核的架构，其基本的特点就是简单，一般都是为了运行单个的进程设计的。相当于是一个小型虚拟机，其中的简约操作系统（例如MiniOS ）直接链接目标应用程序。在论文中，使用的一个Unikernel的镜像的大小只有480KB，而且只需要3.6MB的内存就能正常运行，很好的体现了Unikernels低内存占用的特点。

2. Tinyx
(1):本质上，Tinyx工具构建的虚拟机由基于优化的Linux内核组成。
(2):它提供了一个介于需要移植应用的特定unikernel和可以支持大量现有应用程序但性能开销过高的的虚拟机的中间点。Tinyx接收两个入：需要在VM上运行的应用和VM image运行的平台。该系统分别构建了一个文件系统和内核本身。
(3)Tinyx不直接根据软件包创建其映像，因为软件包中包含安装脚本，这些安装脚本依赖的程序可能在Tinyx发行版本中不可用。相反，Tinyx首先在Debian Minimum Debootstrap[2]系统上挂载一个空的OverlayFS[3]目录。在挂载的目录下，首先安装之前使用工具找出的软件依赖包以及App。由于这是在overlay挂载系统上完成的，因此这整个overlay将为我们提供所有正确配置的文件。在去掉一些不必要的文件（例如与dpkg/apt有关文件）之后，再将此目录作为underlay放置在BusyBox image的顶部并且取出合并目录中的内容。通过上述这些操作，就可确保实现针对特定应用的简约Tinyx发行版本。最后后，在BusyBox的init过程中添加运行app的代码。
(4):在上层应用与依赖问题解决之后，还需要得到一个最小化的Linux内核。为了构建内核，Tinyx将 Linux内核构建目标“ tinyconfig”作为基准，并根据目标系统（例如，Xen或KVM支持）添加了一组内置选项。这样就可以生成一个有效的内核映像。

四:Xen的介绍以及思路

作者通过实验测试发现：随着虚拟机数量的增多，启动创建虚拟机的时间会显著增加。这种结果按逻辑分析是不应该出现的，因为所有的虚拟机启动后都是空闲状态的，所以应该无论有多少虚拟机，整个系统的使用率应该是很低的。同时作者根据数据提出：随着虚拟机体积的减小，虚拟机的创建时间所占的比例越来越大，对于轻量级虚拟机，实例化新虚拟机成为主要瓶颈。而后作者就虚拟机的创建过程时间做了间接分析，得到实验发现在虚拟机数量增长的时候,在XenStore的操作上面消耗了大量的时间,因此，作者提出的部分就是去除Xen里面的XenStore。

五:LightVM设计

1. 作者的实验结果分析
作者的目标是实现与进程启动时间相当的VM启动时间。但是由以上的分析，作者发现，Xen性能问题主要来源于XenStore。XenStore最根本的问题在于它集中式、类文件系统的API，其需要数十次中断和特权域切换，对于在VM创建和启动过程中使用而言太慢了。要实现毫秒级的启动时间，需要对现有Xen代码库进行优化。

2. LightVM体系的提出
LightVM的体系结构如下图所示:

LightVM不再使用XenStore来创建或启动VM，而是使用称为noxs的精简驱动程序，该驱动程序通过共享内存启用前端驱动程序和后端驱动程序之间的直接通信，而不是通过XenStore中继消息。LightVM提供了一个Split toolstack，可将VM创建功能分为准备和执行阶段，从而减少了VM创建所需的工作量。 还实现了chaos/libchaos，这是一个比标准xl/libxl精简得多的新虚拟化toolstack，另外还有一个名为xendevd的小型守护程序，该守护程序可以快速向Software Switch添加虚拟接口或处理块设备映像的设置。

3:划分Toolstack
在之前的分析中，我们发现VM创建和其他操作大部分开销都来自于toolstack本身。虚拟机创建阶段分为9个步骤。实际上，仅仅在创建指令并不需要走一个完整的流程，因为有一些代码是在虚拟机开始运行时需要执行的。那么可以把VM的创建阶段分为预创建（准备）阶段和运行阶段，因为准备阶段对大部分VM的创建来说是通用的。当VM创建指令被发出时，只需要走6-9步骤即可。具体执行步骤如下图所示;

4:替换热插拔脚本：xendevd
由驱动程序域创建虚拟设备通常需要某种机制来在用户空间中设置设备。 使用标准Xen，此过程可以通过xl（调用初始化bash脚本）或通过udevd（在后端触发udev事件时调用相同的脚本）来完成。 执行脚本通常是用户配置的，为实现不同场景提供了极大的灵活性。 但是，启动和执行bash脚本是一个耗时数十毫秒的缓慢过程，从而极大地减慢了启动过程。 为了解决此问题，作者将这种机制实现为名为xendevd的二进制守护程序，该守护程序侦听来自后端的udev事件并执行预定义的安装程序而无需使用forking或bash脚本，从而减少了安装时间。

五:评估以及实例

在以上设计的基础上，LightVM在实例化时间、Checkpointing与迁移、内存和CPU利用率上都取得了十分可观的性能提升。并且在实际应用如个人防火墙、即时服务实例化、高密度TLS Termination和轻量级计算服务中也取得了较好的性能。但是同时LightVM还存在着不足点。比如在可用性与可移植性方面，尽管LightVM相对传统虚拟机已经达到了出色的性能，并且可以与容器相媲美，但它还是不如容器那样容易使用。