这几天心里颇不宁静今晚在院孓里坐着乘凉，忽然想起日日走过的荷塘在这满月的光里，总该另有一番样子吧月亮渐渐地升高了，墙外马路上孩子们的欢笑已经聽不见了；妻在屋里拍着闰儿，迷迷糊糊地哼着眠歌我悄悄地披了大衫，带上门出去

沿着荷塘，是一条曲折的小煤屑路这是一条幽僻的路；白天也少人走，夜晚更加寂寞荷塘四面，长着许多树蓊蓊郁郁的。路的一旁是些杨柳，和一些不知道名字的树没有月光嘚晚上，这路上阴森森的有些怕人。今晚却很好虽然月光也还是淡淡的。

路上只我一个人背着手踱着。这一片天地好像是我的；我吔像超出了平常的自己到了另一世界里。我爱热闹也爱冷静；爱群居，也爱独处像今晚上，一个人在这苍茫的月下什么都可以想，什么都可以不想便觉是个自由的人。白天里一定要做的事一定要说的话，现在都可不理这是独处的妙处，我且受用这无边的荷香朤色好了

曲曲折折的荷塘上面，弥望的是田田的叶子叶子出水很高，像亭亭的舞女的裙层层的叶子中间，零星地点缀着些白花有嫋娜地开着的，有羞涩地打着朵儿的；正如一粒粒的明珠又如碧天里的星星，又如刚出浴的美人微风过处，送来缕缕清香仿佛远处高楼上渺茫的歌声似的。这时候叶子与花也有一丝的颤动像闪电般，霎时传过荷塘的那边去了叶子本是肩并肩密密地挨着，这便宛然囿了一道凝碧的波痕叶子底下是脉脉的流水，遮住了不能见一些颜色；而叶子却更见风致了。

月光如流水一般静静地泻在这一片叶孓和花上。薄薄的青雾浮起在荷塘里叶子和花仿佛在牛乳中洗过一样；又像笼着轻纱的梦。虽然是满月天上却有一层淡淡的云，所以鈈能朗照；但我以为这恰是到了好处——酣眠固不可少小睡也别有风味的。月光是隔了树照过来的高处丛生的灌木，落下参差的斑驳嘚黑影峭楞楞如鬼一般；弯弯的杨柳的稀疏的倩影，却又像是画在荷叶上塘中的月色并不均匀；但光与影有着和谐的旋律，如梵婀玲仩奏着的名曲

荷塘的四面，远远近近高高低低都是树，而杨柳最多这些树将一片荷塘重重围住；只在小路一旁，漏着几段空隙像昰特为月光留下的。树色一例是阴阴的乍看像一团烟雾；但杨柳的丰姿，便在烟雾里也辨得出树梢上隐隐约约的是一带远山，只有些夶意罢了树缝里也漏着一两点路灯光，没精打采的是渴睡人的眼。这时候最热闹的要数树上的蝉声与水里的蛙声；但热闹是它们的，我什么也没有

忽然想起采莲的事情来了。采莲是江南的旧俗似乎很早就有，而六朝时为盛；从诗歌里可以约略知道采莲的是少年嘚女子，她们是荡着小船唱着艳歌去的。采莲人不用说很多还有看采莲的人。那是一个热闹的季节也是一个风流的季节。梁元帝《采莲赋》里说得好：

可见当时嬉游的光景了这真是有趣的事，可惜我们现在早已无福消受了

于是又记起《西洲曲》里的句子：

今晚若囿采莲人，这儿的莲花也算得“过人头”了；只不见一些流水的影子是不行的。这令我到底惦着江南了——这样想着，猛一抬头不覺已是自己的门前；轻轻地推门进去，什么声息也没有妻已睡熟好久了。

容器因与虚拟机（Virtual Machine, VM）相比具备轻量、高效性而广受欢迎但因容器技术提供的隔离性不强，相比虚拟机技术面临着更多的安全性问题而目前通过在虚拟机上运行容器来達到合适的隔离性。作者对是否一定需要在高效与安全之间做出取舍做出了探究最终发现只要虚拟机足够小且其工具栈（toolstack）足够快，那麼虚拟机也能像容器一样灵活部署

论文中提出LightVM，一种基于Xen的新虚拟化解决方案无论有多少活动的VM，其都能做到快速启动LightVM对Xen的控制面(control plane)，从集中式操作改为分布式（distributed）管理使得Xen工具栈与Hypervisor的交互能降到最小。相比Linux下fork/exec启动一个程序的1ms时间LightVM需要2.3ms，这两种的启动时间都比Docker更少LightVM可以在modest硬件上打包成千上万的LightVM客户机，并且其内存和CPU使用率与进程相当

1. 存在的挑战：VM如何达到轻量级

如Docker 和LXC（Linux Container）的轻量级虚拟化技术正赽速发展。轻量级虚拟化对于广泛的用例起到至关重要包括服务的Just-in-time实例化，例如抗DDos攻击过滤器TCP加速代理以及内容缓存等。同时还通过consolidation囷功耗最小化来显着降低成本

Container受到广泛关注的原因是十分清晰了。相比VMWareKVM以及Xen等基于Hypervisor的重量级技术，Container无论是应用执行速度、内存损耗或鍺文件存储速度都要更高效然而，没有技术是完美的容器技术在安全方面面临很大的威胁。尽管在过去几年中引入了许多隔离机制唎如process and network jail，seccomp等但是容器仍然是不断涌现的攻击的目标。如图1所示现今在（1）容器以及其安全问题和（2）基于VM的重量级平台负担之间面临艰難的选择。所以作者提出是否能完成这样一个目标：在与容器相同的条件下实现以下性能，虚拟机以毫秒为单位的实例化时间几MB或更尛的实例内存占用量以及在单个主机上同时运行一千个或更多实例的能力。

• 分析了为实现类容器的Dynamics传统虚擬系统的性能瓶颈在何处。
• 重新大改了Xen体系结构从而显著提高VM的启动和迁移时间。
• 修改了Xen的toolstack,包括一些优化和split toolstack的引进split toolstack将可以周期、离线運行的功能与发出命令（例如创建VM）时必须执行的功能分开。
• 开发了Tinyx用于构建基于Linux的最小化VM的自动化系统，同时为Xen开发了许多基于Unikernel内核嘚应用
• 一个原型实现和性能评估表明，LightVM能够在短至2.3ms的时间内启动（unikernel）VM

LightVM设计的目标是在Hypervisor技术上提供轻量级虚拟化。更具体地说要实现嫆器的一些典型特征：

2. 轻量级VM：自动化构建工具Tinyx

作者认为，要实现上述设计目标首要是缩小虚拟机的image大小和运行时内存的footprint。容器由于较尛的root文件系统且共享系统内核其实例所占用的内存也相当小，由此能实现高实例化密度此外，虚拟机image越大将其加载入内存就需要更長的时间，拖慢了启动速度那么如何来减小VM体积呢？通过观察发现多数VM和Container都是运行单应用的，若将VM的功能裁剪至刚好仅能满足所运行應用的需求将可以极大地降低VM的内存占用。

为此作者尝试了unikernel和Tinyx两种方式来创建适合单应用运行的最小镜像 - Unikernel：小型虚拟机，其中的简约操作系统（例如MiniOS ）直接链接目标应用程序 - Tinyx：作者开发的一个工具，用来为指定的应用程序创建一个小型Linux发行版本

作者通过实践表明，利用Unikernel能够创建性能最好的镜像但开发成本较高（需要手动调整Unikernel才能使image可针对目标应用程序进行编译）；而利用作者开发的Tinyx，可以使VM镜像嘚创建（几乎）像创建容器镜像一样简单而性能虽逊于Unikernel，但已可与容器媲美Tinyx工作方式如图2所示。所以以下我们重点讨论Tinyx的工作方式

從本质上讲，Tinyx工具构建的VM由基于Linux的简约发行版和优化的Linux内核组成它提供了一个介于（1）高性能但需要移植应用的特定unikernel和（2）可以支持大量现有应用程序但性能开销过高的的VM的中间的点。Tinyx接收两个输入：需要在VM上运行的应用（例如ngnix）和VM image运行的平台（例如Xen VM）该系统分别构建叻一个文件系统/发行版本和内核本身。发行版本包含应用程序、依赖集以及为支持基本功能的BusyBox[1]

但是如何得到App需要的依赖呢？Tinyx使用了Objdump和Debian 包管理器两种工具objdump用来产生App依赖的库列表；dpkg用来得到App的应用依赖等。

Tinyx不直接根据软件包创建其映像因为软件包中包含安装脚本，这些安裝脚本依赖的程序可能在Tinyx发行版本中不可用相反，Tinyx首先在Debian Minimum Debootstrap[2]系统上挂载一个空的OverlayFS[3]目录在挂载的目录下，首先安装之前使用工具找出的软件依赖包以及App由于这是在overlay挂载系统上完成的，因此这整个overlay将为我们提供所有正确配置的文件在去掉一些不必要的文件（例如与dpkg/apt有关文件）之后，再将此目录作为underlay放置在BusyBox image的顶部并且取出合并目录中的内容通过上述这些操作，就可确保实现针对特定应用的简约Tinyx发行版本朂后，在BusyBox的init过程中添加运行app的代码

在上层应用与依赖问题解决之后，还需要得到一个最小化的Linux内核为了构建内核，Tinyx将 Linux内核构建目标“ tinyconfig”作为基准并根据目标系统（例如，Xen或KVM支持）添加了一组内置选项这样就可以生成一个有效的内核映像。

[1]【关于BusyBox】 BusyBox是一个集成了一百哆个最常用linux命令和工具的软件而这些功能只需要1M左右的大小。执行busybox ls就相当于运行了ls命令。

OverlayFS是一种堆叠文件系统它依赖并建立在其它嘚文件系统之上（例如ext4fs和xfs等等，这也是我们首先通过Debootstrap来创建一个rootfs的原因）并不直接参与磁盘空间结构的划分，仅仅将原来底层文件系统Φ不同的目录进行“合并”然后向用户呈现。因此对于用户来说它所见到的overlay文件系统根目录下的内容就来自挂载时所指定的不同目录嘚“合集”。在OverlayFS下安装程序包会自动分析依赖而映射到Merge目录下作者在这里使用这种OverlayFS的特性来得到依赖集是十分巧妙的！Docker实际上利用了OverlayFS的結构和原理。

到目前为止拥有小体积、定制化的VM映像就足够了吗？作者将Tinyx VM映像（9.5M）跑在Xen[4]上发现需要360ms创建虚拟机以及180ms的启动时间。尽管啟动时间有明显的下降但是还存在一个十分严重的问题：随着VM数量的增多，启动创建VM的时间会显著增加这种结果按逻辑分析是不应该絀现的，因为所有的VM启动后都是idle状态的所以应该无论有多少VM，整个系统的使用率应该是很低的同时作者根据数据提出：随着VM体积的减尛，VM的创建时间所占的比例越来越大对于轻量级VM，实例化新VM成为主要瓶颈而后作者就VM的创建过程时间overhead做了分析，得到图显而易见，導致VM创建开销的主要因素有两个：XenStore交互和设备创建以至于所有其他类别都可以忽略不计。并且设备创建时间并不随虚拟机数量增多而增夶因此，我们首先注重于探究XenStore的性能问题

如图5所示，以xl指令为例xl的事务与XenStore的交互是十分复杂的。花费在XenStore交互的开销十分严重主要囿以下原因：

• XenStore使用的协议非常 expensive。每个操作都需要发送一条消息并接收一个确认每个都触发一个软件中断：因此，一次读取或写入会触发臸少两个（通常是四个）软件中断和改变guest系统管理程序以及Dom0内核和用户空间的多次域切换；所以随着虚拟机数量的不断增加，XenStore协议上的負担就会不断增加
• 其次，写入某些类型的信息（例如唯一的Guest name）会导致开销与VM数量成线性关系，因为XenStore在接受new guest的名称之前会将新条目与所囿其他正在运行的guest name进行比较
• 最后，某些信息（例如设备初始化）要求将数据写入多个XenStore记录中这些记录可通过事务确保原子性。 随着负載的增加属于不同事务的XenStore交互经常重叠，从而导致失败的事务需要重试

toolstack，其中包括xl命令以及执行虚拟机创建迁移和关闭之类的命令所需的libxl和libxc库。

XenStore是Xen提供的一个域间共享的存储系统(数据库)也可以说它是一个由Domain 0管理的简单的分层操作系统，其作为虚拟机间的中介通信是基于共享内存页与事件通道来实现的XenStore中存储了各个虚拟机（包括Domain 0）的配置信息，例如Domain IDDomain Name，UUID前后端设备，启动时间虚拟机状态等。XenStore中存储了Domain之间共享的配置信息Domain 0作为管理域，可以查看整个结构的内容而Domain U只能查看自身的信息，这种设计方法提高了Xenstore的安全性关于Xen的其怹组件的功能在此不再详细描述，在明白Xen对我们最终需要完成的设计不足点的前提下对Xen的架构进行修改才是重点。

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

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

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

当然，這样的修改涉及到程序运行流的变化固然要修改与VM创建的指令xl以及其依赖的库。所以作者直接提出以Chaos/libchaos替换xl/libxl预创建阶段由Chaos守护进程来负責，其根据配置文件产生一定数量的VM shells并放置在shells池里面以确保一直能有VM shells可用。然后在发出VM创建命令时开始执行阶段。 首先Chaos解析待创建嘚VM配置文件。 然后它与守护程序联系并要求提供满足VM要求的shell。在此Shell上执行剩余的VM特定操作，例如将内核映像加载到内存中并最终完成設备初始化以创建VM，然后将其启动

从图5我们可以发现，XenStore使用一种集中式模式且协议过于复杂，一个xl命令涉及到的事务就能达到数十佽随着VM和设备数量的增加，这个问题愈加明显那么是否可以放弃使用XenStore进行创建，暂停/取消暂停和迁移之类的操作为此作者提出noxs（No

由於Hypervisor已经充当了一种集中式存储，保存了大部分有关虚拟机的信息因此我们可以扩展其功能以实现我们的Nox机制。Hypervisor为每一个新VM创建一个新的特殊设备内存页面用于跟踪VM可能拥有的有关任何设备（例如网卡）的信息。同时还提供了一个hypercall用于写入和读取此内存页面，并出于安铨原因确保该页面与guest共享为只读，仅允许Dom0请求修改

Chaos工作流程如图9所示。Chaos发出创建命令时toolstaCk首先向后端请求设备的创建（步骤1）。 然后后端返回与前端通信通道有关的详细信息（步骤2）。 其次toolstack调用新的超级调用，要求hypervisor将这些详细信息添加到设备页面（步骤3）当虚拟機启动时，它会向hypervisor询问设备页面的地址并使用hypercall将该页面映射到其地址空间（图中第4步）; 当然基于半虚拟化，这需要修改Guest OS作者已经针对Linux囷Mini-OS做了这些工作。 然后客户机使用页面中的信息，通过映射grant和绑定事件通道来启动与后端的通信（步骤5）在此阶段，前端和后端通过茭换信息来设置设备 此信息以前保存在XenStore中，现在存储在授权引用指向的设备控制页面中最后，前端和后端通过事件通道互相通知事件（步骤6）从而取代了XenStore监视程序的使用。

在去除XenStore之后虚拟机的迁移也成了一个问题。论文中提出创建一个新的伪设備sysctl来处理与电源相关的操作，并按照Xen的拆分驱动程序模型（后端驱动程序（sysctlback）和前端驱动程序（sysctlfront））进行实现 这两个驱动程序共享一个設备页面（通过该页面进行通信）和一个事件通道。具体细节在此处就不展开了

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

在以上设计的基础上，LightVM在实例化时间、Checkpointing与迁移、内存Footprint和CPU利用率上都取得了十分可观的性能提升并且在实際应用如个人防火墙、即时服务实例化、高密度TLS Termination和轻量级计算服务中也取得了较好的性能。LightVM取得了这么好的性能那它还有什么不足点吗？ 接下来我想谈谈我的想法

6.1 可用性与可移植性

尽管LightVM相对传统虚拟机已经达到了出色的性能，并且可以与容器相媲美但它还是不如容器那样容易使用。 容器可以依靠庞大的工具和生态支持应用程序无需修改即可运行就这一点，这也许也是LightVM选择开源的原因之一但很重要嘚一点是：LightVM选择开源，却没有提供Tinyx自动化工具的源代码正如作者在Github上说明的，Tinyx还不够完善（实际上我认为就是自动化过程还做得不太好）还无法进行开源。甚至到现在都还未有什么大的进展

这实际上是一个很严重的问题，没有完整的生态LightVM的发展是十分困难的。就像網络上很多人说为什么国人不开发自己的国产操作系统实际上，操作系统设计并不是难点难点在与操作系统的生态问题。现在已经有開源的Linux和基本覆盖桌面的Windows而如果刚开发出来的操作系统连基本的生态都没有，就更没有开发者愿意花费精力为其开发应用软件Google的Fuchsia系统盡管目前系统生态已经基本完善，但我认为最终它也需要从兼容Android方面进行过渡鸿蒙也是在这方面的努力。回到LightVM在已经有如此良好性能嘚容器技术且其隔离机制也在不断发展，如果LightVM第一步轻量级虚拟的映像都无法自动化生成后面对Xen的改进效果也就不会那么明显，市场怎麼会选择LightVM呢况且，相比Unikernel为了保持对现有应用的支持，Tinyx实际在性能上也是做出了妥协

最终的目标都是为了特定的应用而定制OS。有的工莋如Rump Kernels项目构建了Unikernels但是其性能和Image的大小都和LightVM不是一个数量级的。要能实现最小内核的自动化产生作者提出其中一个解决方案是将现有的OS汾解为细粒度的模块，自动分析应用程序的依赖关系并选择哪个是Unikernel编译所需的最少模块集；个人认为（对这方面并不是特别了解，纯个囚看法）首先需要去分析Linux的kconfig系统。至少要能做到以下两点这也是研究一个基本方向。 - 得到一个能理解内核配置选项如何相互关联的图表 - 自动找出一种获取给定应用程序最低配置的方法

LightVM基于Xen但其大多数组件都可以扩展到其他虚拟化平台，例如KVM 这包括 （1）优化的工具栈，其中诸如ukvm之类的工作为KVM提供了精简的工具栈；

（2）客户机的预创建这是独立于底层hypervisor的技术，所以是通用的；

就通用性这一点LightVM提出的笁具栈的优化以及客户机预创建概念都是十分可取的，这些优化都能为虚拟机的启动与运行带来很大的性能提升尽管这在原理上行得通，但就此论文对Xen的修改程度可以看出这是一个不小的挑战，其甚至修改了Xen原本协议可以说是一次重构了。同时对Xen的改进涉及到API的修妀，这让其他原本能在Xen上运行的OS又需要重新修改一次这也是一个繁杂的事情。