我們是否可以通過容器的效率來改進vm(虛擬機)的效率?在今天的論述中，具體研究了基于Xen(開放源代碼虛擬機監視器)的虛擬機性能的邊界。發現并消除了在啟動大量輕量級vm(包括單核和最小的Linux VMs)時遇到的瓶頸。由此產生的系統被稱為LightVM，并具有最小的unikernel鏡像，可以以4ms運行VM。相比之下，Linux上的fork和exec大約需要1ms。在同一系統上，Docker容器從大約150毫秒開始運行。

這些結果是在LightVM 客戶虛擬機是unikernel時獲得的。你可能只是在特定的情況下創建了一個unikernel。(本文中一個有趣的例子是基于Micropython的unikernel，可用于支持無服務器功能執行)。此外，還創建了一個稱為TinyX的自動構建系統，用于創建針對運行單個應用程序的簡約Linux VM鏡像。與Docker相比，如果我們查看TinyX VM的啟動時間，則每個內核的性能非常接近約250個虛擬機或容器。

在這一點上，Docker開始將其邊緣化，因為即使是由TinyX創建的空閑最小的Linux發行版也確實會運行一些臨時的后臺任務。

Xen與虛擬機有何關系，瓶頸在哪里?

如下圖所示，限制虛擬化的可擴展性和性能的最大的單一因素是客戶虛擬機的大小。要生成該圖表，從unikernel虛擬機從內存盤啟動，將不同大小的二進制對象注入到未壓縮的鏡像文件中。所有的這些效果影響都是由鏡像的大小決定的。

所以如果想要快速啟動，那么鏡像的大小就會變得十分重要。在本文中，小編使用Mini-OS來創建各種unikernel。480KB未壓縮，并且運行在3.6MB的RAM，這個unikernel是用于測試可能的VM的內存消耗的下限。

基于Mini-OS制作自己的unikernel鏡像可能比許多人準備做的還要更多，因此也創建了Tinyx。

Tinyx是一種自動化的構建系統，可以創建針對運行單個應用程序的最小化的Linux VM鏡像。 該工具本質上是一個VM，它由一個極簡的、基于Linux的分布式系統和一個優化的Linux內核組成。它提供了一個高度專業化的內核，具有最佳性能但需要將應用程序移植到極簡操作系統，以及一個完整的通用OS VM，它支持大量應用程序，但可能會帶來一些性能開銷。

Tinyx創建的內核鏡像大小是典型的Debian內核的一半，運行時內存使用率顯著減少(Tinyx為1.6MB，Debian為8MB)。

使用這樣的小型虛擬機鏡像，我們可以在啟動大量虛擬機時探測Xen本身的行為。在面對1000位客戶時，以下是Debian最小安裝的啟動和創建時間，以及對同一硬件的比較：Docker容器和簡單的進程創建。

當我們不斷創建虛擬機時，創建時間會顯著增加(注意對數刻度)：分別使用42s、10s和700ms創建千分之一的Debian，Tinyx和unikernel 的客戶。

隨著VM的大小的減少，創建時間將占據絕大部分，從而獲得可用性。為了理解所有的時間都花在哪里，團隊儀表化了Xen來揭示這張照片:

XenStore交互和設備創建占主導地位。其中，設備的創建開銷是相當穩定的，但是XenStore的開銷超出線性增長。

我們的目標是實現VM啟動時間與流程啟動時間達到相當。Xen沒有為此目標而設計，正如前面部分的結果所示，這些問題的根源不僅僅在于低效率代碼。例如，XenStore的一個基本問題是其集中式的，類似文件系統的API，在虛擬機創建和啟動過程中使用起來太慢，需要數十個中斷和特權域過渡。

當設計首次創建時，很難設想有人能啟動1000位訪客的虛擬機!

LightVM使用一個叫noxs的精簡驅動程序(用于“no XenStore”)重新設計Xen控制平面，可以替代XenStore，并允許通過共享內存直接與前端和后端驅動程序進行通信。

標準Xen中的設備創建最終會調用bash腳本，這是一個緩慢的過程。 LightVM將二進制守護程序替換為執行預定義設置的二進制守護進程，而不需要FORK指令或bash腳本。

性能

此外，LightVM可以在30毫秒內保存一個VM，并在20ms恢復它。標準Xen分別需要128ms和550ms。

Unikernel內存使用非常接近Docker容器，Tinyx則需要更多，但在1000位客人中只有22GB。這只是當前服務器RAM的一小部分。

vm的CPU使用率也可以與容器相媲美，只要將vm縮減為只包括必需的功能:

　　用例

這里介紹了LightVM +輕量級虛擬機的四個不同的用例。

在所有這些場景中，使用容器將有助于性能提升，但會削弱隔離，而使用完整的vm將提供與輕量級vm相同的隔離，但性能較差。

·每個移動用戶的個人防火墻，在移動網關或近蜂窩基站(移動邊緣計算- MEC)中運行。這里使用了一個ClickOS unikernel鏡像，8000個防火墻可以運行在64核AMD機器上。在這種情況下，一臺運行LightVM的單一機器就可以為單元中的所有用戶運行個性化的防火墻，而不會成為瓶頸。

·在移動端計算中的即時服務實例化(類似于JITSU)。

·高密度TLS終止于CDNs，這需要內容提供商的長期保密密鑰。因此，需要在不同的內容提供者的代理之間進行強大的隔離。

·創建一個輕量級的計算服務，如AWS Lambda。對于這個用例，他們使用基于Micropython的unikernel來運行用Python編寫的計算。啟動和執行一個函數需要大約1.3 ms。當系統被故意強調的時候，比測試機器能夠處理的請求會更多，服務時間就會直線上升，直到大約800個vm為止。

我們展示的用例表明，對輕量級虛擬化有真正的需求，并且可以在par或優于容器的情況下模擬實現良好的隔離和性能。