虛擬化技術(shù)調(diào)研

虛擬化技術(shù)簡介虛擬化技術(shù)就是通過在硬件與操作新系統(tǒng)之間插入這樣一層薄的虛擬機監(jiān)控程序，并通過其創(chuàng)建的物理資源與平臺的抽象接口，使得在同一硬件平臺上可以同時運行多個虛擬機。無論是內(nèi)存、設備還是處理器，對于各虛擬機而言，都被認為是自已獨占一套的這一體系結(jié)構(gòu)的改變實現(xiàn)了對服務應用的整合，計算資源的高效組織，以及具體的硬件體系結(jié)構(gòu)和緊密依賴于其上的軟件系統(tǒng)之間的隔閡。提高各種軟硬件資源大額利用率，節(jié)約了大量的IT成本。目前虛擬化技術(shù)主要有全虛擬化、半虛擬化和系統(tǒng)級虛擬化，基于這些虛擬化技術(shù)，涌現(xiàn)了一批虛擬機軟件，其中較著名的有VMWare、Xen和QEMU,大多數(shù)虛擬化應用的研究和開發(fā)都是以這些虛擬機軟件為底層平臺。單機環(huán)境下虛擬化的應用比較普遍，多機環(huán)境下虛擬化的應用尚處在初步發(fā)展階段，虛擬機在分布式環(huán)境下的應用已經(jīng)成為了虛擬化領(lǐng)域研究的熱點。從現(xiàn)有的多機環(huán)境下的虛擬化研究狀況來看，多機虛擬化技術(shù)只是將多個虛擬機聚集在一起，實現(xiàn)虛擬機在多機環(huán)境下的直接應用，并且在此之上完成了中央控制的管理，沒有達到有機整合的目的，在用戶應用環(huán)境構(gòu)建上也存在很多缺陷。應當在這個基礎(chǔ)上繼續(xù)研究將虛擬機和虛擬網(wǎng)絡整合在一起，克服現(xiàn)有多機系統(tǒng)的管理軟件依賴于特定操作系統(tǒng)的弱點，形成一個讓用戶能夠動態(tài)構(gòu)建虛擬運行環(huán)境的多機系統(tǒng)管理模式虛擬機監(jiān)控程序簡介虛擬機監(jiān)控程序是一種軟件，它為在系統(tǒng)上“虛擬”運行的來賓提供一套虛擬化硬件。虛擬機監(jiān)控程序創(chuàng)建一個底層硬件平臺抽象，這樣，一個或多個虛擬機(VM)無需知道它們共享平臺即可使用這個底層硬件平臺。在這種環(huán)境中，VM只是操作系統(tǒng)及其應用程序的容器。這種環(huán)境的一個有趣的優(yōu)點是一個VM與虛擬機監(jiān)控程序上運行的其他VMs隔離，這支持多個操作系統(tǒng)或多個配置不同的相似操作系統(tǒng)。如圖1：圖1.裸機操作系統(tǒng)和虛擬機監(jiān)控程序

WMVMApplic^lioriE4ppliesiDri￡□SWMVMApplic^lioriE4ppliesiDri￡□SOSHypervisorSarverxdesKtapOS1ApplicaLlanEVM日Ml骼ddfidEmbeddeddevice在x86平臺上運行的“1類虛擬機監(jiān)控程序”(包括MicrosoftHyper-V和VMwareESXServer)得到了很大發(fā)展，這也導致產(chǎn)生一些混淆。大多數(shù)人使用的虛擬機監(jiān)控程序(特別是對于客戶端系統(tǒng))被稱為“2類虛擬機監(jiān)控程序”。類虛擬機監(jiān)控程序直接在主機硬件上運行，而無需 “主機操作系統(tǒng)”。MicrosoftHyper-V和VMwareESXServer是1類虛擬機監(jiān)控程序的常見例子。類虛擬機監(jiān)控程序需要運行主機操作系統(tǒng)。通常，2類虛擬機監(jiān)控程序主要作為用戶模式應用程序在其主機操作系統(tǒng)上運行。MicrosoftVirtualPC和VMwareWorkstation是2類虛擬機監(jiān)控程序的常見例子。嵌入式虛擬化的特征與傳統(tǒng)虛擬機監(jiān)控程序不同，嵌入式虛擬機監(jiān)控程序?qū)崿F(xiàn)了一種不同的抽象擁有與其他平臺不同的限制。本節(jié)探索嵌入式空間中提供的一些限制和功能。效率所有虛擬機監(jiān)控程序都致力于提高效率，但嵌入式虛擬機監(jiān)控程序必須處理在傳統(tǒng)虛擬化環(huán)境之外添加的限制。因此，嵌入式虛擬機監(jiān)控程序必須規(guī)模小，且擁有極高的內(nèi)存使用效率。安全性規(guī)模小有其優(yōu)勢。應用程序的代碼越小，就越容易驗證和證明它是沒有bug的。事實上，有些嵌入式虛擬機監(jiān)控程序供應商已經(jīng)正式驗證了他們的虛擬機監(jiān)控程序，并保證它們沒有bug。虛擬機監(jiān)控程序越小，平臺就可能越安全可靠。這是因為虛擬機監(jiān)控程序通常是系統(tǒng)惟一以特權(quán)模式運行的部分，充當所謂的可信計算基(TrustedComputingBase,TCB),形成一個更安全的平臺。通信嵌入式虛擬機監(jiān)控程序的目的在于與多個來賓和應用程序共享一個硬件平臺，但通常還擴展一些通信方法以便它們交互。這個通信通道既有效又安全，允許特權(quán)和非特權(quán)應用程序并存。隔離隔離來賓和應用程序的能力與安全性相關(guān)。除了提供安全性和可靠性的容器之外，這種能力還提供許可隔離方面的好處。使用嵌入式虛擬機監(jiān)控程序的通信機制允許專有軟件和開源軟件在隔離的環(huán)境中共存。隨著嵌入式設備變得更加開放，混合專有軟件和第三方或開源軟件的愿望成為一個重要需求。實時功能最后，嵌入式虛擬機監(jiān)控程序必須支持擁有實時功能的調(diào)度。對于手持式設備，虛擬機監(jiān)控程序能夠與核心通信功能和第三方應用程序共享平臺。具有實時特征的調(diào)度允許這些關(guān)鍵功能與一些盡力運行的應用程序共存。虛擬機監(jiān)控器設計說明考慮嵌入式系統(tǒng)的軟件設計要求不同于服務器或桌面環(huán)境的軟件設計要求。這些要求來自很多因素，包括系統(tǒng)的封閉性以及在這些系統(tǒng)上運行的實時任務。它決定了嵌入式系統(tǒng)環(huán)境的VMM設計。盡管許多嵌入式系統(tǒng)的要求有些類似，但是在嵌入式系統(tǒng)領(lǐng)域內(nèi)，不同的應用卻有不同的要求。在Intel推出含Intel虛擬化技術(shù)(IntelVT)的處理器之前，為不同的嵌入式系統(tǒng)應用開發(fā)一個VMM是一件復雜的事情，而且成本極高。有了IntelVT，嵌入式系統(tǒng)的特殊要求可由本文討論的目標產(chǎn)品低價滿足。針對嵌入式系統(tǒng)，VMM的設計應該考慮到嵌入式系統(tǒng)獨特的隔離要求、靜態(tài)特性，以及實時任務的支持虛擬機監(jiān)控器設計要求隔離要求嵌入式VMM與一般VMM要求之間的差異決定了VM如何彼此隔離。大多數(shù)嵌入式系統(tǒng)是封閉系統(tǒng)，即所有的軟件由一個廠家編寫，最終用戶不能運行自己的軟件。在有些情況下，這樣可以減少通用VMM中的隔離要求。在嵌入式系統(tǒng)中，減少隔離通?？商岣咝阅芑蛱岣咝阅艿念A期。但在其他情況下比如有關(guān)安全應用中，而應增加隔離而不是減少隔離，甚至還要求認證。有2個嵌入式VMM,通過減少隔離要求來支持最優(yōu)化。第一個，許多實時操作系統(tǒng)運行不要分頁。因為跨頁使實時系統(tǒng)預期的代碼性能以及有效地滿足實時性變得困難。也導致了整體性能降低。在IntelVT系統(tǒng)中，運行沒有分頁的客體(guest)減少客體(guest)之間的隔離一客體(guest)能讀寫所有物理內(nèi)存，包括設備或其他客體(guest)內(nèi)存。在通用環(huán)境中，這是不可接受的，但是在一些嵌入式環(huán)境中，可能是優(yōu)先選擇的。第二個，I／0性能對于一個嵌入式系統(tǒng)的成功與否可能是至關(guān)重要的。這導致一些嵌入式VMM廠家允許VM直接訪問內(nèi)存訪問(DMA)設備。這提高了性能，但是也允許一個惡意應用或設備驅(qū)動讀寫系統(tǒng)上的其他客體(guest)內(nèi)存。在軟件環(huán)境固定的環(huán)境中，這樣的折衷可以被接受。即使一些嵌入式環(huán)境允許減少客體(guest)之間的隔離，但其他嵌入式環(huán)境有例外。尤其是，像由Lynux—Works支持那些有關(guān)安全和有關(guān)安全裝置的環(huán)境不允許這種折衷。此外，IntelVT降低了生成VMM的成本，這樣，用不同的設計折衷開發(fā)目標VMM成為可能。靜態(tài)虛擬機很多嵌入式系統(tǒng)設計總是準確地知道將有運行什么任務。也準確地知道系統(tǒng)將使用什么樣硬件。這使得設計者在設計時對如何分配硬件運行任務做出選擇。于是，當使用嵌入式0S時，典型地，設計者靜態(tài)分配特定的核和特定的內(nèi)存區(qū)域給處理任務。這樣減少了在GPOS中通常很重要的動態(tài)調(diào)度和動態(tài)內(nèi)存管理。在虛擬化環(huán)境中，VMM為客體操作系統(tǒng)(guestOS)負責處理器調(diào)度和內(nèi)存管理，就如同操作系統(tǒng)(OS)為應用程序負責處理器調(diào)度和內(nèi)存管理。在嵌入式環(huán)境中，對0S的很多要求也適用于嵌入式環(huán)境中的VMM。需要注意的是，設計的VMM，在有關(guān)如何給VM分配資源時，系統(tǒng)設計者可以靜態(tài)配置選擇。嵌入式環(huán)境在二個方面改變了VMM的設計。第一，調(diào)度設計簡化了，設計者可能手工靜態(tài)地把任務映射到處理器核。調(diào)度發(fā)生在同一個核上運行的VM之間，使用不同于桌面系統(tǒng)中使用的調(diào)度策略，核之間的調(diào)度被簡化。第二，設計內(nèi)存管理更多地針對可配置性而不是動態(tài)分配。VMM依賴設計者規(guī)劃分配給每個VM的內(nèi)存區(qū)域。這樣簡化了VMM內(nèi)內(nèi)存管理的設計，但是增加了配置VMM的復雜性。實時系統(tǒng)支持很多嵌入式系統(tǒng)要求支持實時任務。像微軟Win—dows這樣的通用操作系統(tǒng)(GPOS)不能提供實時控制，其原因之一就是由于調(diào)度算法的限制。在這種情況下,調(diào)度是實體，它決定一個特定的進程或線程在指定的處理器上允許花多少時間。微軟Windows使用基于優(yōu)先級搶先的調(diào)度算法。這基本上意味著相同優(yōu)先級的線程輪巡調(diào)度，優(yōu)先級高的線程先于優(yōu)先級低的線程獲得服務?！皀ux也是基于優(yōu)先級的調(diào)度算法。但是，RTOS通常使用嚴格的優(yōu)先級調(diào)度任務。優(yōu)先級調(diào)度允許優(yōu)先級高的任務運行，只要它們有工作要做。通用調(diào)度算法總是試圖保證沒有任務能阻止另一任務的進程。在虛擬化環(huán)境中支持實時任務是一個挑戰(zhàn)。典型地，VMM不可見地在RTOS中運行單個任務，也不知道它們的優(yōu)先級。目前，嵌入式VMM廠家用的解決方案就是在處理器核上隔離RTOS，或者只允許RTOS與GPOS共享一個核并且給RTOS嚴格的、高于GPOS的優(yōu)先級。在中斷處理方式上實時環(huán)境與通用環(huán)境之間也存在差異。在很多嵌入式應用中，由外部硬件產(chǎn)生的中斷必須在特定的時間內(nèi)響應。GPOS不必具有在這樣的能力，因為如果不限制時間，它們常常就關(guān)掉中斷處理。這種做法對于要求實時控制的應用是不可接受的。對于實時中斷處理，IntelVT起著重要作用。有了IntelVT，系統(tǒng)可以配置成這樣，當一個客體關(guān)閉中斷，只有發(fā)送給它自己的中斷被關(guān)閉。另一方面，如果當RTOS正在運行一個關(guān)鍵任務時GPOS的中斷發(fā)生，VMM將推遲發(fā)送中斷，直到RTOS完成了該關(guān)鍵任務。許多嵌入式系統(tǒng)要求以不同的優(yōu)先級運行的代碼之間嚴格區(qū)分I/O的優(yōu)先次序。例如，如果多個VM訪問同一個網(wǎng)絡設備，應用可能要求客體之間增強某些服務質(zhì)量（QoS）的保證。這些保證可能以帶寬或延遲的保證形式出現(xiàn)。一般地，這樣的要求不會出現(xiàn)在通用系統(tǒng)中。這使得用于VM間共享設備的設計變得復雜。嵌入式系統(tǒng)有獨特的設計要求，大大影響了如何為這樣的系統(tǒng)設計VMM。IntelVT降低了生成一個VMM的成本。它允許VMM廠家把重點放在如何滿足他們的市場需求，而不是花大氣力應對虛擬化系統(tǒng)硬件的復雜性。2.4嵌入式虛擬機監(jiān)控程序示例PikeOSPikeOS是一個有趣的架構(gòu)，因為它主要實現(xiàn)了一個所謂的分離內(nèi)核（separationkernel）。與虛擬機監(jiān)控程序類似，分離（或分區(qū)）內(nèi)核安全地隔離上級來賓的環(huán)境。PikeOS用于處理航空電子工業(yè)中安全性至關(guān)重要的航空電子應用程序。引入一個嵌入式虛擬機監(jiān)控程序允許在同一個平臺上同時使用較早的遺留應用程序（在一個VM中）和更新的應用程序（見圖2）。圖3.PikeOS嵌入式虛擬化Parliton&VM W VW1UserApplic^rtiansApplicationsPiHaOSr*sdiv?Mk|-I'11PikeOSsyslemsoftw-aneAk&ClSsepHratiorimicrokernelKjemelArchitecture:platformBup^nrrpackagesEiribecWed阿憫在內(nèi)核領(lǐng)域中，PikeOS實現(xiàn)了一套架構(gòu)和平臺支持包，用于特殊的硬件環(huán)境（x86、PowerPC、SuperH等）以及提供虛擬化平臺的分離微核。PikeOS不僅支持來賓操作系統(tǒng)（及其關(guān)聯(lián)應用程序），還支持針對一個特定問題領(lǐng)域的更簡單的應用程序編程接口和運行時環(huán)境（RTE）,比如PikeOS原生接口和實時Java。PikeOS系統(tǒng)軟件層向來賓分配資源（空間和時間）。此系統(tǒng)依賴半虛擬化，以便來賓操作系統(tǒng)意識到它們已被虛擬化。盡管通常用于航空電子工業(yè)，但PikeOS不久以后有可能通過AutomotiveOpenSystemArchitecture（AUTOSAR）進入汽車。OKL42006年，OpenKernelLabs（OKLabs）創(chuàng)立，致力于為嵌入式系統(tǒng)開發(fā)微核和虛擬機監(jiān)控程序。這個實驗室在這些領(lǐng)域中的工作創(chuàng)造了一個術(shù)語：microvisor，表示一個具有虛擬化功能的微核。OKLabs在嵌入式虛擬化領(lǐng)域中取得了迄今為止最大的成功，其開源OKL4microvisor已部署到超過10億臺設備中，如EvokeA4消息傳遞電話——部支持虛擬化和兩個并發(fā)操作系統(tǒng)（包括Linux）運行的電話。OKL4繼承了L4微核系列（由JochenLiedtke開發(fā)）的遺產(chǎn)。L4的靈感來自Mach，Mach是卡內(nèi)基梅隆大學開發(fā)的微核，作為傳統(tǒng)UNIX內(nèi)核的一個“簡易（drop-in）"替代者。L4最初完全在x86Assembly中設計，以便實現(xiàn)一個最優(yōu)解決方案。后來，它用C++開發(fā)，現(xiàn)在存在于一系列微核中：從L4Ka::Hazelnut（針對IntelArchitecture、32位和基于ARM的架構(gòu)設計）到4Ka::Pistachio（針對平臺獨立性設計，在BerkeleySoftwareDistribution許可下發(fā)布）。OKL4實現(xiàn)了名為安全單元的分區(qū)，用于對此架構(gòu)中的VMs進行分區(qū)。OKL4microvisor占據(jù)了特權(quán)內(nèi)核空間，所有VMs、原生應用程序和驅(qū)動程序被推到單獨的隔離分區(qū)中，一種高效的進程間通信（InterprocessCommunication,IPC）機制允許各單元進行通信和合作（見圖3）。除VMs之間的傳統(tǒng)IPC外，由于硬件設備驅(qū)動程序被推到microvisor之外（這在微核中很常見），因此這種IPC很重要：這是一種公共路徑輸入/輸出。另外，由于單獨的應用程序和驅(qū)動程序可以集成到?jīng)]有操作系統(tǒng)的平臺，因此OKL4的組件模型是輕量級的。

圖3.圖3.OKL4microvisorNOVA2010年，NOVA微虛擬機監(jiān)控程序問世。與此前的微核架構(gòu)類似，NOVA實現(xiàn)了一個瘦微核，包含一些用于非特權(quán)代碼的獨立層。NOVA利用新硬件平臺的虛擬化功能來提高基于組件的系統(tǒng)的性能。NOVA包含一個微虛擬機監(jiān)控程序和用戶級環(huán)境，用于系統(tǒng)的核心功能。這些核心元素（如圖5所示）包括：一個根分區(qū)管理器（用于管理微內(nèi)核外的資源分配）、底層硬件設備的驅(qū)動程序、用于每個來賓管理（來賓和主機之間的）內(nèi)存映射的VM監(jiān)控器（VMM）以及敏感指令模擬。NOVA實現(xiàn)了全面虛擬化，因此某些指令（比如x86CPUID）必須針對每個來賓、根據(jù)其配置恰當模擬。VMM還為每個來賓可用的設備實現(xiàn)了設備模擬。由于NOVA實現(xiàn)了全面虛擬化，因此支持未更改的來賓操作系統(tǒng)。圖5.NOVA微虛擬機監(jiān)控程序架構(gòu)KJMT10INOVAmlcror^tHfvisoiuserdfrvzKJMT10INOVAmlcror^tHfvisoiuserdfrvz微虛擬機監(jiān)控程序本身實現(xiàn)了調(diào)度器、內(nèi)存管理和消息傳遞通信接口，以及其他核心特性，比如保護域（用于空間隔離）和調(diào)度上下文（用于臨時隔離）。

NOVA被視為一個第三代微核，它的前輩包括Mach和Chorus（第一代微核）以及L4（第二代微核）。CodezeroCodezeroEmbeddedHypervisor是一個遵循LR架構(gòu)的新微核，但經(jīng)過徹底重寫，以利用微核設計中的最新研究成果。它遵循微核的基本原理，因為它只在特權(quán)微核中實現(xiàn)地址空間、線程管理和IPC,以及一些虛擬化功能。如圖6所示，Codezero在硬件平臺上實現(xiàn)了一個典型的抽象層，這個抽象層實現(xiàn)了線程處理、IPC、地址空間管理、地址空間映射、安全性、電源以及錯誤恢復管理。Codezero的調(diào)度器包含針對來賓線程和微核線程的內(nèi)核優(yōu)先（以及用于優(yōu)先的時間片）。Codezero中的虛擬化通過容器實現(xiàn)。每個容器都是一個隔離的執(zhí)行環(huán)境，包含自己的資源集（內(nèi)存、線程等）。這種分區(qū)還與Codezero的安全性和資源管理策略協(xié)同工作，這些策略定義每個容器的功能。圖6.嵌入管理程序架構(gòu)的CodezeroApDiicatiersBan&rrretBlsoftwarescack.KernelCODEZEROemnacKiecin^pannwrEmbeddeddeviceirati口nsHqdIiApDiicatiersBan&rrretBlsoftwarescack.KernelCODEZEROemnacKiecin^pannwrEmbeddeddeviceirati口nsHqdIicaliansLrux.AndraidRIOSCodezero受益于最新微核設計成果。為提高效率，Codezero實現(xiàn)了三種IPC（全部基于約會模型［rendezvousmodel］）。Codezero實現(xiàn)了短IPC（在用戶空間線程之間）、全面IPC（256字節(jié)）和擴展IPC（2048字節(jié)）。大型緩沖區(qū)的IPC通過共享頁面映射執(zhí)行。Codezero還專門針對嵌入式系統(tǒng)設計，支持多核處理器和基于ARM的設計。虛擬機監(jiān)控器時間開銷虛擬化性能開銷概況在虛擬化技術(shù)中，硬件和其上執(zhí)行的操作系統(tǒng)之間插入了一層薄的軟件，稱為虛擬機監(jiān)控器，又叫虛擬機管理程序，它獨立于各個操作系統(tǒng)域存在，由其控制著多個操作系統(tǒng)的執(zhí)行。并由這個軟件來隔離開硬件和操作系統(tǒng)，從而實現(xiàn)對系統(tǒng)的虛擬化，包括處理器虛擬化，內(nèi)存管理虛擬化，以及10虛擬化等。從應用程序的角度觀察，下層的體系結(jié)構(gòu)對其是透明的，它無法發(fā)覺其自身是運行在虛擬的平臺上，還是實體計算機上，因為通過虛擬機監(jiān)控程序的虛擬化，對于應用程序而言，其效果是同樣的。由于這一體系結(jié)構(gòu)的改變，各個客戶操作系統(tǒng)內(nèi)核原有的一些操作，需要切換至虛擬機監(jiān)控器中執(zhí)行，而這一執(zhí)行方式的切換在以前是并不存在的，是虛擬化技術(shù)中所特有的。而這一虛擬機監(jiān)控器進入和退出操作可以通過不同的方式來實現(xiàn)。在虛擬化中，這個切換是通過一個特殊的跳轉(zhuǎn)實現(xiàn)，而在硬件支持虛擬化中，這是一組新的指令集。但是無論是哪種實現(xiàn)方式，都有一個共有的、公認的因素，那就是這一進入和退出操作絕不是輕易得來的，是需要付出一定的性能代價的。進入虛擬機監(jiān)控器時，CPU需要運行在一個更高權(quán)限的狀態(tài)，因此，許多內(nèi)部狀態(tài)需要保存和重置。這一過程就產(chǎn)生較多的性能開銷，同時，類似于系統(tǒng)調(diào)用，一些CPU緩存中的內(nèi)容將會丟失。盡管可能通過某些技巧來避免對于CPU緩存的直接刷新，但是虛擬機監(jiān)控器本身的代碼和數(shù)據(jù)同樣需要進行緩存，這就意味著一些舊的緩存內(nèi)容不可避免的被替換了，從而導致需要對這一部分進行保存和重置，進而產(chǎn)生新的性能開銷。由于涉及虛擬機監(jiān)控器的操作比較頻繁，因而這一性能開銷不容低估。對于如何減小這些性能開銷，各個虛擬化實現(xiàn)方案擁有其各自的解決方法，但是這一性能開銷是不可能消失的。目前國內(nèi)外對于虛擬化CPU開銷的研究主要集中在CPU的調(diào)度算法上，并沒有對整體的用于管理的CPU開銷有系統(tǒng)的研究，但是普遍意識到分配給hypervisor的計算資源對于系統(tǒng)性能會產(chǎn)生比較大的影響，但由于目前的測量工具不能準確反映真實的CPU使用情況，不能夠很好地去度量和評價分配給hypervisor的計算資源。數(shù)，可以將用于iotransfer的CPU開銷從DomO的整個CPU使用中剝離開，從而得到在進行IO操作時候，整個虛擬計算系統(tǒng)引入的CPU開銷。但是該測量方法中，單次flipping的Cost,主要通過一種統(tǒng)計的方法獲得，并不準確。而同時對于這個過程中是否還存在其他的開銷，并不能夠很細致地指出。在全虛擬化系統(tǒng)中，并不存在這種flipping的過程，全虛擬化系統(tǒng)中的主要CPU開銷是用在了VMM的entry和exit上，而目前并沒有合適的工具去測量這一過程中的CPU開銷。在眾多的研究中，對于用于管理的CPU開銷重視不夠，都只是基于某一特定目的去獲取相應的信息。至于這個開銷與其影響因子之間的關(guān)系，并沒有人去特意的關(guān)注和研究?？偠灾壳皣鴥?nèi)外的研究方向主要集中于兩個方向：針對某一特定目的而測量該任務路徑上CPU的開銷，并對其調(diào)優(yōu)，其優(yōu)化并不適應于多VM情形。對于多個VM的情形，更多關(guān)注的是如何提高對有效資源的利用率，而沒有去關(guān)注有效資源的減少，即開銷。相對時間開銷的概念存在VMM額外開銷的依據(jù)主要有以下2個方面：目前的虛擬機為了實現(xiàn)對硬件資源的訪問控制需要運行大量的額外指令和操作，這些指令的執(zhí)行必然帶來CPU執(zhí)行時間的增加；虛擬機性能測試實驗中獲得的數(shù)據(jù)說明VMM的運行降低了真實主機的運行效率，在對VMwareinfrastructure3Suite的測試中發(fā)現(xiàn)，運行虛擬機導致至少1O%的性能損耗，最高能達到2O%。然而首先需要解決的問題是如何計算這些開銷。測量程序的絕對執(zhí)行時間不僅對計時的準確性要求高，而且很容易受目標主機中運行狀況的影響?？梢圆捎?個程序的執(zhí)行時間差對VMM執(zhí)行開銷進行描述。由于目標主機負載的變化對2個程序的執(zhí)行時間影響相似，在目標主機中同時運行2個測試程序，通過計算2個程序的相對執(zhí)行時間，與實驗獲得的虛擬機判別指標進行比較。這種采用相對執(zhí)行時間描述VMM額外執(zhí)行開銷的方法，降低了對計時準確性的要求，并且能夠克服目標主機負載變化產(chǎn)生的影響。指令選取與程序構(gòu)造為了產(chǎn)生易于檢測的相對時間開銷，需要VMM執(zhí)行大量的額外代碼。實驗發(fā)現(xiàn)，目前主流虛擬機中的VMM在執(zhí)行特定指令時，由于虛擬指令系統(tǒng)的運行而產(chǎn)生大量額外的操作，但真實主機中這些指令卻能夠直接執(zhí)行，其產(chǎn)生的執(zhí)行時間與在虛擬機環(huán)境下差異明顯，因此利用這些特定指令能夠構(gòu)造一個產(chǎn)生大量VMM額外時間開銷的指令序列。在本地環(huán)境中分別對Xen3.0.2,VMwareWorkstation和vanillaLinux3種不同類型的虛擬機測試特定指令的執(zhí)行時間。經(jīng)對比，確定程序中的指令序列由以下指令組成：cli,mov%cr0,%eax,mov%cr2,%eax,mov%cr3,%eax和mov%eax,%cr3。設計一條由上述指令組成的指令序列，包含該指令序列的程序為P1,目標主機完全執(zhí)行P1的時間為It。同時，設計另一個程序P2,該程序不包含該指令序列，其他指令與P1相同，P2的執(zhí)行時間21VMMttt,VMMt為VMM執(zhí)行額外指令的時間。相對執(zhí)行時間tA為P1和P2在目標主機中執(zhí)行時間的差值，即12tttA二-。判別指標的確定在CPU為Pentium4系列的前提下，在選取虛擬機判別指標這個關(guān)鍵問題上，將CPU主頻和VMM執(zhí)行效率作為重要條件進行分析。為方便討論，將真實主機抽象為2類：主頻最高的主機FR和主頻最低的主機SR；將VMM抽象為2類：執(zhí)行效率最高的虛擬機FV和執(zhí)行效率最低的虛擬機SV。目標主機可能存在以下5種情況：真實的物理主機由于P1中產(chǎn)生VMM時間開銷的指令序列并不對真實主機產(chǎn)生額外的時間開銷，而P1,P2在其他指令的設計上基本相同。在這種目標環(huán)境中，Pl和P2的執(zhí)行時間相差不大，相對時間開銷tA近似為零。FR中運行FVtl由tVMM和其他指令產(chǎn)生的執(zhí)行時間組成，而P2由于沒有產(chǎn)生VMM時間開銷的指令序列，因此t2與真實主機中P2的執(zhí)行時間相同。由于主頻和虛擬機執(zhí)行效率均為最高，此時tA最小。FR中運行SV與(2)相比，此時的虛擬機執(zhí)行效率降低而主頻沒有變化，所以，t2基本不變，tVMM顯著增加，tA增大。SR中運行FV與(2)相比，此時的虛擬機執(zhí)行效率不變但主頻降低，所以11,t2和tVMM均增大。但由于11,t2受CPU影響程度相似，tA隨tVMM增大而增大。SR中運行SV此時，由于主頻和虛擬機執(zhí)行效率均為最低，因此程序的執(zhí)行時間最大，tA最大。通過對以上5種情況的分析發(fā)現(xiàn)，只要將(2)中的相對執(zhí)行時間tA作為標準，如果實際檢測到的相對執(zhí)行時間比該值大，則能夠判定目標為虛擬機，反之則為真實主機。實驗分析實驗表明，第(2)種情況中的目標主機處于最輕負載的情況下，CPU主頻最高的主機運行vanillaLinux時產(chǎn)生的相對時間開銷能夠被作為VMM存在性的判定標準。目前，OVD能夠在目標主機中發(fā)現(xiàn)VMwareWorkstation5,Xen3.0.2和VanillaLinux等3種類型的虛擬機，與目前主要的發(fā)現(xiàn)方法相比，能夠適應的虛擬機類型更多，如表2所示。^2a/D與主渝虛擬柵炭現(xiàn)方浩功能對比VM^ureWortsialion.5Xcn3.D.2VainillaLinui>'77MDo-py-doo-QKK口J&門KXRedPill寸KX基于VMM時間開銷的虛擬機發(fā)現(xiàn)方法OVD，利用虛擬機中普遍存在的VMM時間開銷對目標進行虛擬機判別，在目標的虛擬機類型不確定情況下，具有較強的適應性。由于基于虛擬機的惡意軟件已經(jīng)對計算機系統(tǒng)安全構(gòu)成新的威脅，因此對其進行判別成為虛擬機發(fā)現(xiàn)技術(shù)研究的當務之急。下一步研究工作將主要集中于通過判別目標主機中是否被惡意安裝VMM，實現(xiàn)對VMBR的識別，為采取措施對其進行防范提供依據(jù)。虛擬化性能測量工具介紹XenMon,一批具有優(yōu)秀性能功能表現(xiàn)的虛擬化性能評測技術(shù)和評測方法紛紛涌現(xiàn)，XenMon,Xenoprof,Vconsolidate以及VMmark.是其中表現(xiàn)最為突出的四種，對于這四個系統(tǒng)的介紹如下：XenMonenMon是一款基于Xen虛擬機環(huán)境的性能監(jiān)控與分析的工具集，主要用于實時監(jiān)控各個虛擬機對于計算資源的使用情況，比較其中的差異，同時對虛擬機對于共享資源的訪問和資源調(diào)度情況也做出了一定的分析。XenoprofXenoprof項目是一個系統(tǒng)級的統(tǒng)計分析工具，它使得OProfile能夠適用于基于Xen的虛擬環(huán)境，從而能夠?qū)?nèi)核、應用程序等的性能信息進行監(jiān)控。通過使用Xenoprof可以得到單路徑上CPU的開銷以及其分布。但對于多個VM,并在其上運行不同類型的負載，Xenoprof就局限于硬件計數(shù)器的數(shù)量，而不能動態(tài)的獲得期望的性能統(tǒng)計結(jié)果。vConsolidatevConsolidate評測的是服務器整合性能指標，同時運行四項不同的性能指標評測進程，最后綜合得出最終性能結(jié)果。分別為針對數(shù)據(jù)庫應用、郵件服務、Java和Web四項應用的性能指標評測組件。整個系統(tǒng)在評測過程中針對每個應用類型啟動一個虛擬機，然后在每個虛擬機中運行一個組件，然后啟動額外的一臺空閑虛擬機，其上不運行任何組件，只用于模擬空置的虛擬機，由此構(gòu)成一個整體，從而更準確地去模擬真實的服務器聚合環(huán)境。VMmarkVMark則是另外的一種評測服務器整合性能的方法。由Makhja等提出“組件”（tile）這一概念，即一批虛擬機，在其上執(zhí)行著不同的工作負載，由此代表在同一個物理計算平臺上上運行的各種不同的工作負載。當需要的“組件”個數(shù)增加的時候，表示整個系統(tǒng)此刻是被過度使用的。因為，“組件”中的工作負載是被嚴格限制的，因此不可能達到其最高利用率。在每個測量周期中，通過將不同的benchmark結(jié)果進行統(tǒng)一的規(guī)格化處理，參照與同樣的參考系，測試結(jié)果被整合成一個統(tǒng)一的指標VMmark目前包括六種主要的工作負載：文件監(jiān)控器、郵件監(jiān)控器、Web監(jiān)控器、備用監(jiān)控器、OLTP數(shù)據(jù)庫和Java順序登錄系統(tǒng)。3.4測量系統(tǒng)體系結(jié)構(gòu)基于Xen設計的虛擬計算環(huán)境中CPU開銷測量系統(tǒng)(VOMS),該系統(tǒng)能夠準確地獲取虛擬機調(diào)度開銷和特權(quán)操作開銷這兩類的系統(tǒng)開銷。為了獲取時間相關(guān)信息并基于這些信息計算虛擬計算系統(tǒng)中CPU的開銷，系統(tǒng)不僅要采集虛擬機監(jiān)控器中的相關(guān)信息，同時也需要采集各個虛擬機中的相關(guān)信息，因此該系統(tǒng)的實現(xiàn)主要基于Xentrace和Xenrelay機制。同時，系統(tǒng)還應當提供相應的控制接口，并通過這些接口可以由用戶指定哪些事件將生效哪些不生效，從而獲得感興趣的信息。如下圖所示，系統(tǒng)由運行在domain。服務器端(VOMSserver)以及運行在虛擬機監(jiān)控器內(nèi)部的內(nèi)部采集模塊(GatherHyper)和運行在各個客戶虛擬機中的前端采集模塊(GatherFrontend)組成。r事件癢ClyeCEue￡tAar事件癢ClyeCEue￡tAa羋特M1￡flU€￡tJid(C1hrFronici(KoitJdmain)氐務謹壬cV-0Ms倍氈覽理與品吞中心(P￡D匸VEIC*uZVOMS系統(tǒng)體系結(jié)構(gòu)系統(tǒng)分為3個功能模塊：如圖下所示，這3個功能模塊相互協(xié)作完成系統(tǒng)任務前端信息采集模塊內(nèi)部信息采集模塊

3)信息處理分析模塊4)圖表顯示模塊5)采集控制模塊6)處理控制模塊曲船理至純CPU開悄阿盤咅覘廠皆恵肚複塩 ！lb俚礙就塊控制為塊圖二“虛擬計巨篥就CPU開銷瀏量系統(tǒng)功能欖塊因

系統(tǒng)工作流程VOMS系統(tǒng)基本測量流程如圖所示是季二潔劉塔星否超言有廠邑白愷忌ft叵住優(yōu)載疋試VOMS系統(tǒng)基本測量流程如圖所示是季二潔劉塔星否超言有廠邑白愷忌ft叵住優(yōu)載疋試星召楚佇壬生杲否有匸W岸三咅丄?&牛不黒復兵西棗至二惟.港護赴楣的上析與址計址淳，軫出葺蘭洶試壟杲運交滅?共逞白蘭主二咗嚴葺涉對齊與扯理.克借到文件.習庁駛出到耳主笆持對宜色呈邑皆三弓戶匡蘭刃雀方妄蛙配劉試方龕「啟訪各平惰后釆彙慎疑用戶配置基本測試方案，并將測試信息寫入配置文件；讀取配置文件，等待測試命令下達；判斷是否是開始測試，如果是則執(zhí)行測試工作，如果否則退出；信息處理模塊等候信息采集模塊傳回信息；判斷是否有信息傳回，如果有就執(zhí)行(6)，否則回到(4)繼續(xù)等待；對收到的信息進行甄別，等待與之對應的來自其他模塊的信息；判斷是否有對應信息傳回，如果有就繼續(xù)執(zhí)行，否則回到(6)繼續(xù)等待（8） 將收到的來自不同模塊的信息進行處理與對齊，記錄在文件中，輸出到屏幕上；（9） 判斷各個虛擬機上的負載是否運行完畢，如果否則回到（4）繼續(xù)等待，否則就繼續(xù)執(zhí)行；（10） 通過控制模塊停止各個信息采集模塊的信息采集工作，然后進行最終的數(shù)據(jù)分析與統(tǒng)計工作，輸出最終的測試結(jié)果。VOMS系統(tǒng)體系結(jié)構(gòu)由于當前虛擬化性能評測領(lǐng)域?qū)τ谔摂M化系統(tǒng)中的CPU開銷并無準確界定，基于虛擬化技術(shù)提高了對資源的利用率，但同時引入的虛擬化的開銷使得有效資源減小了這一指導思想制定界定原則為:虛擬化系統(tǒng)中的CPU開銷是由于虛擬化技術(shù)的引入所帶來的不同于傳統(tǒng)系統(tǒng)的不可避免的CPU開銷，即相較于傳統(tǒng)系統(tǒng)中特權(quán)操作路徑上增加的部分操作所消耗的CPU時間片即為虛擬化系統(tǒng)中CPU的性能開銷。Xen3.4.1額外增加的操作Xen3.4.1在操作路徑上額外增加的操作主要分為兩個方面:3.7.1虛擬機之間進行調(diào)度時產(chǎn)生的CPU性能開銷在傳統(tǒng)系統(tǒng)中，在多個虛擬機之間進行調(diào)度的需求并不存在，因為在同一時間只有唯一的操作系統(tǒng)占據(jù)并使用物理計算資源，從某種意義上來說，這個時刻只存在一個“虛擬機”，那么虛擬機之間的調(diào)度自然也不會存在了。但是在虛擬計算系統(tǒng)中，物理計算資源不再僅僅由唯一的操作系統(tǒng)獨享，而是在多個虛擬機直接共享。從微觀的角度看，一個虛擬機在任意時刻只能占據(jù)一套計算資源，盡管這套計算資源從宏觀上看是多個虛擬機復用的。因此，從微觀的粒度看，虛擬機之間的調(diào)度，不可避免，而執(zhí)行這一部分操作所需要消耗的CPU時間片也是必須的，因而這一部分開銷屬于定義中的虛擬計算環(huán)境本身的CPU開銷。在系統(tǒng)中將其定義為調(diào)度開銷。3?7?2由特權(quán)域代理執(zhí)行某些特權(quán)指令產(chǎn)生的額外CPU開銷Xen上的虛擬化的主要指導思想就在于將客戶操作系統(tǒng)遷徙到低特權(quán)環(huán)執(zhí)行，眾所周知，X86的體系結(jié)構(gòu)上，CPU執(zhí)行環(huán)境擁有4個環(huán)級，從0環(huán)到3環(huán)，特權(quán)級依次降低，低特權(quán)級環(huán)境不能執(zhí)行高特權(quán)級的指令，在這一過程中，需要進行環(huán)級的切換。在傳統(tǒng)的計算系統(tǒng)中，由于操作系統(tǒng)掌控全局，占有統(tǒng)治地位，因而，操作系統(tǒng)需要運行在最高特權(quán)級，也就是運行在0環(huán)中，但是由于虛擬化技術(shù)的引入，虛擬機監(jiān)控器需要統(tǒng)一地管理和分配計算資源，而客戶操作系統(tǒng)對于計算資源的訪問并不再能隨心所欲，必須在虛擬機監(jiān)控器的監(jiān)督管理之下進行。因而，虛擬機監(jiān)控器的特權(quán)級必須要高于操作系統(tǒng)的特權(quán)級。在X86的體系結(jié)構(gòu)中，雖然設置了4個特權(quán)級別，但是其中的1環(huán)和2環(huán)并沒有充分的利用。因此，給虛擬化的實現(xiàn)提供了機會。在Xen中，客戶操作系統(tǒng)不再運行在0環(huán)，而是運行在較低特權(quán)級的環(huán)上，這一過程被稱為“降環(huán)”在X86體系結(jié)構(gòu)上Xen的默認安裝是將客戶操作系統(tǒng)運行在1環(huán)上，被稱為處理器當前特權(quán)級1。而虛擬機監(jiān)控器則運行在當前特權(quán)級0，即0環(huán)上，其他的各種應用不發(fā)生改變，仍然運行在4環(huán)上。在IA-32指令集中大約包含250條指令，而其中大約17條指令當其運行在1環(huán)的時候，就會產(chǎn)生一定的問題。這些問題主要表現(xiàn)在兩個方面，第一，在1環(huán)上運行這些指令可能會導致產(chǎn)生一個一般性保護異常，也叫做一般性保護錯誤。第二個問題產(chǎn)生時并不會產(chǎn)生一般性保護異常，而是沉默性錯誤，并不會被任何異常處理器捕獲。為了解決這兩個問題。Xen設置了hypercall(超級調(diào)用)機制用來將控制權(quán)限從 1環(huán)切換到0環(huán)，同時通過do_general_protection()函數(shù)來處理一般性保護異常。在某些情況下，這個處理函數(shù)會檢測CPU收到的指令的相關(guān)操作碼,然后在0環(huán)上模擬這些指令的執(zhí)行。在傳統(tǒng)計算系統(tǒng)中，這些機制和處理函數(shù)都不存在，因此，這些操作遵循界定原則。因此，這一部分操作也屬于傳統(tǒng)操作路徑上增加的操作，它們消耗的時間片也就屬于虛擬計算環(huán)境中的CPU開銷的一部分。在系統(tǒng)中，把這類時間片消耗稱為特權(quán)操作開銷。1.5系統(tǒng)功能模塊結(jié)構(gòu)根據(jù)系統(tǒng)體系結(jié)構(gòu)與系統(tǒng)的功能實3.8虛擬計算環(huán)境中CPU開銷測量系統(tǒng)主要實現(xiàn)技術(shù)首先指出虛擬計算環(huán)境中CPU開銷測量的兩個指標，然后針對這兩個指標，說明了各個區(qū)域如何進行CPU開銷的相關(guān)數(shù)據(jù)采集，分別描述了客戶虛擬機內(nèi)數(shù)據(jù)采集機制，和虛擬機監(jiān)控器內(nèi)數(shù)據(jù)采集機制；然后，闡述了如何對采集到的CPU開銷相關(guān)的數(shù)據(jù)信息進行轉(zhuǎn)換處理,最后，通過設計一個統(tǒng)一的測試控制平臺，闡述虛擬計算系統(tǒng)CPU開銷的基本測試方法，從而能夠更加方便地測試和研究各個影響因子與CPU開銷的關(guān)系。CPU開銷測量指標基于虛擬計算環(huán)境中CPU開銷的界定原則，即虛擬化系統(tǒng)中的CPU開銷是由于虛擬化技術(shù)的引入所帶來的不同于傳統(tǒng)系統(tǒng)的不可避免的CPU開銷，即相較于傳統(tǒng)系統(tǒng)中特權(quán)操作路徑上增加的部分操作所消耗的CPU時間片即為虛擬化系統(tǒng)中CPU的性能開銷。確定虛擬計算環(huán)境中CPU開銷測量的指標主要分為兩類：虛擬機間調(diào)度開銷在傳統(tǒng)系統(tǒng)中，在多個虛擬機之間進行調(diào)度的需求并不存在，因為在同一時間只有唯一的操作系統(tǒng)占據(jù)并使用物理計算資源，從某種意義上來說，這個時刻只存在一個“虛擬機”，那么虛擬機之間的調(diào)度自然也不會存在了。但是在虛擬計算系統(tǒng)中，物理計算資源不再僅僅由唯一的操作系統(tǒng)獨享，而是在多個虛擬機直接共享。從微觀的角度看，一個虛擬機在任意時刻只能占據(jù)一套計算資源，盡管這套計算資源從宏觀上看是多個虛擬機復用的。因此，從微觀的粒度看，虛擬機之間的調(diào)度，不可避免，而執(zhí)行這一部分操作所需要消耗的CPU時間片也是必須的，因而這一部分開銷屬于定義中的虛擬計算環(huán)境本身的CPU開銷。在系統(tǒng)中將其定義為虛擬機間調(diào)度開銷。特權(quán)操作開銷在傳統(tǒng)的計算系統(tǒng)中，由于操作系統(tǒng)掌控全局，占有統(tǒng)治地位，因而，操作系統(tǒng)需要運行在最高特權(quán)級，也就是運行在0環(huán)中，但是由于虛擬化技術(shù)的引入，虛擬機監(jiān)控器需要統(tǒng)一地管理和分配計算資源，而客戶操作系統(tǒng)對于計算資源的訪問并不再能隨心所欲，必須在虛擬機監(jiān)控器的監(jiān)督管理之下進行。因而，虛擬機監(jiān)控器的特權(quán)級必須要高于操作系統(tǒng)的特權(quán)級。在Xen中，客戶操作系統(tǒng)不再運行在0環(huán)，而是運行在較低特權(quán)級的環(huán)上，這一過程被稱為“降環(huán)”，在X86體系結(jié)構(gòu)上Xen的默認安裝是將客戶操作系統(tǒng)運行在1環(huán)上，被稱為處理器當前特權(quán)級1。而虛擬機監(jiān)控器則運行在當前特權(quán)級0，即0環(huán)上，其他的各種應用不發(fā)生改變，仍然運行在4環(huán)上。Xen設置了hypercall(超級調(diào)用)機制用來將控制權(quán)限從1環(huán)切換到0環(huán)，同時通過do_general_protection()函數(shù)來處理一般性保護異常。在某些情況下，這個處理函數(shù)會檢測CPU收到的指令的相關(guān)操作碼，然后在0環(huán)上模擬這些指令的執(zhí)行。在傳統(tǒng)計算系統(tǒng)中，這些機制和處理函數(shù)都不存在，因此，這些操作遵循界定原則。因此，這一部分操作也屬于傳統(tǒng)操作路徑上增加的操作，它們消耗的時間片也就屬于虛擬計算環(huán)境中的CPU開銷的一部分。在系統(tǒng)中，把這類時間片消耗稱為特權(quán)操作開銷。3.9系統(tǒng)測試虛擬計算系統(tǒng)中CPU開銷測量系統(tǒng)的功能測試情況并針對不同系統(tǒng)環(huán)境,進行了基本的測試與分析性。首先，描述了測試環(huán)境；然后對整個系統(tǒng)進行了基本的功能測試，最后，針對于影響虛擬計算系統(tǒng)CPU開銷的幾組因子設計了不同的對照實驗，并對測試結(jié)果進行了分析。測試環(huán)境因為本系統(tǒng)測量的主要是單服務器虛擬計算環(huán)境中CPU開銷，因而測試環(huán)境是在一臺服務器上進行。采用的服務器硬件配置具體情況如表4.1所示。此外，虛擬計算系統(tǒng)中CPU開銷測量系統(tǒng)是基于Xen實現(xiàn)，所以在服務器上安裝了Xen3.4.1版本。由于本系統(tǒng)對于Xen的版本依耐性不大。因此，測試環(huán)境，可以移植到Xen的其他版本實現(xiàn)本系統(tǒng)。domain。采用的操作系統(tǒng)版本是RedhatEnterpriseLinux5.1，操作系統(tǒng)內(nèi)核版本為2.6.18.各個虛擬機的都是基于domainO的文件系統(tǒng)生成的統(tǒng)一模板，其配置情況如表4.2所示因此在測試的時候能夠最大可能性減少虛擬機之間差異帶來的結(jié)果偏差表丄1 服務器恒息迅宣機器名CPU硬盤平臺IP服務器眾核3.06GHz1GBL2OGEJXen3.4.1m.168^13.144表4衛(wèi)虛擬機基本信息配置內(nèi)核眾本VCPU個數(shù)內(nèi)存平臺IP2.6.1￡-xeti1個