一、CPU虛擬化
1、多CPU服務器架構:SMP/NUMA/MPP
目前的商用服務器大體可以分爲三類，即對稱多處理器結構 (SMP ： Symmetric Multi-Processor) ，非一致存儲訪問結構 (NUMA ： Non-Uniform Memory Access) ，以及海量並行處理結構 (MPP ： Massive Parallel Processing) 。 1)SMP(Symmetric Multi-Processor) //多處理器結構
圖1：
所有的CPU共享全部資源，如總線，內存和I/O系統等，操作系統或管理數據庫的複本只有一個，這種系統有一個最大的特點就是共享所有資源。多個CPU之間沒有區別，平等地訪問內存、外設、一個操作系統。SMP 服務器的主要問題，那就是它的擴展能力非常有限。
操作系統管理着一個隊列，每個處理器依次處理隊列中的進程。如果兩個處理器同時請求訪問一個資源（例如同一段內存地址），由硬件、軟件的鎖機制去解決資源爭用問題。
所謂對稱多處理器結構，是指服務器中多個 CPU 對稱工作，無主次或從屬關係。各 CPU 共享相同的物理內存，每個 CPU 訪問內存中的任何地址所需時間是相同的，因此 SMP 也被稱爲一致存儲器訪問結構 (UMA ： Uniform Memory Access) 。對 SMP 服務器進行擴展的方式包括增加內存、使用更快的 CPU 、增加 CPU 、擴充 I/O( 槽口數與總線數 ) 以及添加更多的外部設備 ( 通常是磁盤存儲 ) 。
SMP 服務器的主要特徵是共享，系統中所有資源 (CPU 、內存、 I/O 等 ) 都是共享的。也正是由於這種特徵，導致了 SMP 服務器的主要問題，那就是它的擴展能力非常有限。對於 SMP 服務器而言，每一個共享的環節都可能造成 SMP 服務器擴展時的瓶頸，而最受限制的則是內存。由於每個 CPU 必須通過相同的內存總線訪問相同的內存資源，因此隨着 CPU 數量的增加，內存訪問衝突將迅速增加，最終會造成 CPU 資源的浪費，使 CPU 性能的有效性大大降低。實驗證明， SMP 服務器 CPU 利用率最好的情況是 2 至 4 個 CPU 。
2)NUMA(Non-Uniform Memory Access)
圖2：
利用 NUMA 技術，可以把幾十個 CPU( 甚至上百個 CPU) 組合在一個服務器內。
NUMA 服務器的基本特徵是具有多個 CPU 模塊，每個 CPU 模塊由多個 CPU( 如 4 個 ) 組成，並且具有獨立的本地內存、 I/O 槽口等。由於其節點之間可以通過互聯模塊 ( 如稱爲 Crossbar Switch) 進行連接和信息交互，因此每個 CPU 可以訪問整個系統的內存 ( 這是 NUMA 系統與 MPP 系統的重要差別 ) 。顯然，訪問本地內存的速度將遠遠高於訪問遠地內存 ( 系統內其它節點的內存 ) 的速度，這也是非一致存儲訪問 NUMA 的由來。由於這個特點，爲了更好地發揮系統性能，開發應用程序時需要儘量減少不同 CPU 模塊之間的信息交互。
利用 NUMA 技術，可以較好地解決原來 SMP 系統的擴展問題，在一個物理服務器內可以支持上百個 CPU 。比較典型的 NUMA 服務器的例子包括 HP 的 Superdome 、 SUN15K 、 IBMp690 等。
但 NUMA 技術同樣有一定缺陷，由於訪問遠地內存的延時遠遠超過本地內存，因此當 CPU 數量增加時，系統性能無法線性增加。如 HP 公司發佈 Superdome 服務器時，曾公佈了它與 HP 其它 UNIX 服務器的相對性能值，結果發現， 64 路 CPU 的 Superdome (NUMA 結構 ) 的相對性能值是 20 ，而 8 路 N4000( 共享的 SMP 結構 ) 的相對性能值是 6.3 。從這個結果可以看到， 8 倍數量的 CPU 換來的只是 3 倍性能的提升。
3)MPP(Massive Parallel Processing)
MPP由多個 SMP 服務器通過一定的節點互聯網絡進行連接，協同工作，完成相同的任務，從用戶的角度來看是一個服務器系統。其基本特徵是由多個 SMP 服務器 ( 每個 SMP 服務器稱節點 ) 通過節點互聯網絡連接而成，每個節點只訪問自己的本地資源 ( 內存、存儲等 ) ，是一種完全無共享 (Share Nothing) 結構，因而擴展能力最好，理論上其擴展無限制，目前的技術可實現 512 個節點互聯，數千個 CPU 。目前業界對節點互聯網絡暫無標準，如 NCR 的 Bynet ， IBM 的 SPSwitch ，它們都採用了不同的內部實現機制。但節點互聯網僅供 MPP 服務器內部使用，對用戶而言是透明的。
每個 SMP 節點也可以運行自己的操作系統、數據庫等。但和 NUMA 不同的是，它不存在異地內存訪問的問題。換言之，每個節點內的 CPU 不能訪問另一個節點的內存。節點之間的信息交互是通過節點互聯網絡實現的，這個過程一般稱爲數據重分配 (Data Redistribution) 。
但是 MPP 服務器需要一種複雜的機制來調度和平衡各個節點的負載和並行處理過程。目前一些基於 MPP 技術的服務器往往通過系統級軟件 ( 如數據庫 ) 來屏蔽這種複雜性。舉例來說， NCR 的 Teradata 就是基於 MPP 技術的一個關係數據庫軟件，基於此數據庫來開發應用時，不管後臺服務器由多少個節點組成，開發人員所面對的都是同一個數據庫系統，而不需要考慮如何調度其中某幾個節點的負載。
MPP (Massively Parallel Processing)，大規模並行處理系統，這樣的系統是由許多鬆耦合的處理單元組成的，要注意的是這裏指的是處理單元而不是處理器。每個單元內的CPU都有自己私有的資源，如總線，內存，硬盤等。在每個單元內都有操作系統和管理數據庫的實例複本。這種結構最大的特點在於不共享資源。
圖3：
4)對比
MPP和SMP對比)
處理大規模事務時：MPP效率高於SMP //如果通信時間較多，那麼MPP系統就不佔優勢了
OTLP適用於SMP，數據挖掘和決策支持適用MPP
SMP的瓶頸在於總線
numa和MPP對比)
相同點:NUMA 與 MPP 具有許多相似之處：它們都由多個節點組成，每個節點都具有自己的 CPU 、內存、 I/O ，節點之間都可以通過節點互聯機制進行信息交互。
節點互連不同：NUMA 的節點互聯機制是在同一個物理服務器內部實現的，當某個 CPU 需要進行遠地內存訪問時，它必須等待，這也是 NUMA 服務器無法實現 CPU 增加時性能線性擴展的主要原因。而 MPP 的節點互聯機制是在不同的 SMP 服務器外部通過 I/O 實現的，每個節點只訪問本地內存和存儲，節點之間的信息交互與節點本身的處理是並行進行的。因此 MPP 在增加節點時性能基本上可以實現線性擴展。
內存訪問機制不同：在 NUMA 服務器內部，任何一個 CPU 可以訪問整個系統的內存，但遠地訪問的性能遠遠低於本地內存訪問，因此在開發應用程序時應該儘量避免遠地內存訪問。在 MPP 服務器中，每個節點只訪問本地內存，不存在遠地內存訪問的問題。
圖4：
NUMA、MPP、SMP之間性能的區別)
NUMA的節點互聯機制是在同一個物理服務器內部實現的，當某個CPU需要進行遠地內存訪問時，它必須等待，這也是NUMA服務器無法實現CPU增加時性能線性擴展。
MPP的節點互聯機制是在不同的SMP服務器外部通過I/O實現的，每個節點只訪問本地內存和存儲，節點之間的信息交互與節點本身的處理是並行進行的。因此MPP在增加節點時性能基本上可以實現線性擴展。
SMP所有的CPU資源是共享的，因此完全實現線性擴展。
NUMA、MPP、SMP之間擴展的區別)
NUMA理論上可以無限擴展，目前技術比較成熟的能夠支持上百個CPU進行擴展。如HP的SUPERDOME。
MPP理論上也可以實現無限擴展，目前技術比較成熟的能夠支持512個節點，數千個CPU進行擴展。
SMP擴展能力很差，目前2個到4個CPU的利用率最好，但是IBM的BOOK技術，能夠將CPU擴展到8個。
MPP是由多個SMP構成，多個SMP服務器通過一定的節點互聯網絡進行連接，協同工作，完成相同的任務。
MPP和SMP、NUMA應用之間的區別)
MPP的優勢：
MPP系統不共享資源，因此對它而言，資源比SMP要多，當需要處理的事務達到一定規模時，MPP的效率要比SMP好。由於MPP系統因爲要在不同處理單元之間傳送信息，在通訊時間少的時候，那MPP系統可以充分發揮資源的優勢，達到高效率。也就是說：操作相互之間沒有什麼關係，處理單元之間需要進行的通信比較少，那採用MPP系統就要好。因此，MPP系統在決策支持和數據挖掘方面顯示了優勢。
SMP的優勢：
MPP系統因爲要在不同處理單元之間傳送信息，所以它的效率要比SMP要差一點。在通訊時間多的時候，那MPP系統可以充分發揮資源的優勢。因此當前使用的OTLP程序中，用戶訪問一箇中心數據庫，如果採用SMP系統結構，它的效率要比採用MPP結構要快得多。
NUMA架構的優勢：
NUMA架構來看，它可以在一個物理服務器內集成許多CPU，使系統具有較高的事務處理能力，由於遠地內存訪問時延遠長於本地內存訪問，因此需要儘量減少不同CPU模塊之間的數據交互。顯然，NUMA架構更適用於OLTP事務處理環境，當用於數據倉庫環境時，由於大量複雜的數據處理必然導致大量的數據交互，將使CPU的利用率大大降低。
5)查看服務器的CPU架構：
[root@node112 ~]# uname -a
Linux node112 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux //SMP架構
2、CPU虛擬化技術
1)基於二進制翻譯的全虛擬化（Full Virtualization with Binary Translation）
客戶操作系統運行在 Ring 1，它在執行特權指令時，會觸發異常（CPU的機制，沒權限的指令會觸發異常），然後 VMM 捕獲這個異常，在異常裏面做翻譯，模擬，最後返回到客戶操作系統內，客戶操作系統認爲自己的特權指令工作正常，繼續運行。但是這個性能損耗，就非常的大，簡單的一條指令，執行完，了事，現在卻要通過複雜的異常處理過程。
異常 “捕獲（trap）-翻譯（handle）-模擬（emulate）” 過程：
2)超虛擬化（或者半虛擬化/操作系統輔助虛擬化 Paravirtualization）
修改操作系統內核，替換掉不能虛擬化的指令，通過超級調用（hypercall）直接和底層的虛擬化層hypervisor來通訊，hypervisor 同時也提供了超級調用接口來滿足其他關鍵內核操作，比如內存管理、中斷和時間保持。
3)硬件輔助的全虛擬化
AMD-v和Interl-VT
二、KVM-CPU虛擬化
1、KVM虛擬機創建過程
圖：kvm_create
（1）qemu-kvm 通過對 /dev/kvm 的 一系列 ICOTL 命令控制虛機
（2）一個 KVM 虛機即一個 Linux qemu-kvm 進程，與其他 Linux 進程一樣被Linux 進程調度器調度。
（3）KVM 虛機包括虛擬內存、虛擬CPU和虛機 I/O設備，其中，內存和 CPU 的虛擬化由 KVM 內核模塊負責實現，I/O 設備的虛擬化由 QEMU 負責實現。
（3）KVM戶機系統的內存是 qumu-kvm 進程的地址空間的一部分。
（4）KVM 虛機的 vCPU 作爲 線程運行在 qemu-kvm 進程的上下文中。
VCPU、QEMU 進程、Linux 進程調度和物理CPU之間的邏輯關係：
圖：kvm_create2
2、KVM的guest代碼運行在物理CPU之上
Intel VT技術，增加了兩種運行模式：VMX root 模式和 VMX nonroot 模式。通常來講，主機操作系統和 VMM 運行在 VMX root 模式中，客戶機操作系統及其應用運行在 VMX nonroot 模式中。
因爲兩個模式都支持所有的 ring，因此，客戶機可以運行在它所需要的 ring 中（OS 運行在 ring 0 中，應用運行在 ring 3 中），VMM 也運行在其需要的 ring 中 （對 KVM 來說，QEMU 運行在 ring 3，KVM 運行在 ring 0）。CPU 在兩種模式之間的切換稱爲 VMX 切換。從 root mode 進入 nonroot mode，稱爲 VM entry；從 nonroot mode 進入 root mode，稱爲 VM exit。可見，CPU 受控制地在兩種模式之間切換，輪流執行 VMM 代碼和 Guest OS 代碼。
對 KVM 虛機來說，運行在 VMX Root Mode 下的 VMM 在需要執行 Guest OS 指令時執行 VMLAUNCH 指令將 CPU 轉換到 VMX non-root mode，開始執行客戶機代碼，即 VM entry 過程；在 Guest OS 需要退出該 mode 時，CPU 自動切換到 VMX Root mode，即 VM exit 過程。可見，KVM 客戶機代碼是受 VMM 控制直接運行在物理 CPU 上的。QEMU 只是通過 KVM 控制虛機的代碼被 CPU 執行，但是它們本身並不執行其代碼。也就是說，CPU 並沒有真正的被虛級化成虛擬的 CPU 給客戶機使用。圖：guest
幾個概念：socket（顆，CPU 的物理單位）、core（核，每個 CPU 中的物理內核）、thread （超線程，通常來說，一個 CPU core 只提供一個 thread，這時客戶機就只看到一個 CPU；但是，超線程技術實現了 CPU 核的虛擬化，一個核被虛擬化出多個邏輯 CPU，可以同時運行多個線程）。
上圖分三層，他們分別是是VM層，VMKernel層和物理層。對於物理服務器而言，所有的CPU資源都分配給單獨的操作系統和上面運行的應用。應用將請求先發送給操作系統，然後操作系統調度物理的CPU資源。在虛擬化平臺比如 KVM 中，在VM層和物理層之間加入了VMkernel層，從而允許所有的VM共享物理層的資源。VM上的應用將請求發送給VM上的操作系統，然後操縱系統調度Virtual CPU資源（操作系統認爲Virtual CPU和物理 CPU是一樣的），然後VMkernel層對多個物理CPU Core進行資源調度，從而滿足Virtual CPU的需要。在虛擬化平臺中OS CPU Scheduler和Hyperviisor CPU Scheduler都在各自的領域內進行資源調度。
KVM 中，可以指定 socket，core 和 thread 的數目，比如 設置 “-smp 5,sockets=5,cores=1,threads=1”，則 vCPU 的數目爲 511 = 5。客戶機看到的是基於 KVM vCPU 的 CPU 核，而 vCPU 作爲 QEMU 線程被 Linux 作爲普通的線程/輕量級進程調度到物理的 CPU 核上。
3、guest系統的代碼運行方式
一個普通的 Linux 內核有兩種執行模式：內核模式（Kenerl）和用戶模式 （User）。爲了支持帶有虛擬化功能的 CPU，KVM 向 Linux 內核增加了第三種模式即客戶機模式（Guest），該模式對應於 CPU 的 VMX non-root mode。圖：三種模式 
KVM 內核模塊作爲 User mode 和 Guest mode 之間的橋樑：
User mode 中的 QEMU-KVM 會通過 ICOTL 命令來運行虛擬機
KVM 內核模塊收到該請求後，它先做一些準備工作，比如將 VCPU 上下文加載到 VMCS （virtual machine control structure）等，然後驅動 CPU 進入 VMX non-root 模式，開始執行客戶機代碼
三種模式的分工爲：
Guest 模式：執行客戶機系統非 I/O 代碼，並在需要的時候驅動 CPU 退出該模式
Kernel 模式：負責將 CPU 切換到 Guest mode 執行 Guest OS 代碼，並在 CPU 退出 Guest mode 時回到 Kenerl 模式
User 模式：代表客戶機系統執行 I/O 操作
圖：模式
QEMU-KVM 相比原生 QEMU 的改動：
原生的 QEMU 通過指令翻譯實現 CPU 的完全虛擬化，但是修改後的 QEMU-KVM 會調用 ICOTL 命令來調用 KVM 模塊。
原生的 QEMU 是單線程實現，QEMU-KVM 是多線程實現。
主機 Linux 將一個虛擬視作一個 QEMU 進程，該進程包括下面幾種線程：
I/O 線程用於管理模擬設備
vCPU 線程用於運行 Guest 代碼
其它線程，比如處理 event loop，offloaded tasks 等的線程
SMP設置爲4：1 個主線程（I/O 線程）、4 個 vCPU 線程、3 個其它線程
SMP設置爲8：1 個主線程（I/O 線程）、6 個 vCPU 線程、3 個其它線程
圖：線程
客戶機代碼執行（客戶機線程） I/O 線程 非 I/O 線程
虛擬CPU（主機 QEMU 線程） QEMU I/O 線程 QEMU vCPU 線程
物理 CPU 物理 CPU 的 VMX non-root 模式中 物理 CPU 的 VMX non-root 模式中
4、從guest線程到物理CPU的兩次調度
客戶機內的線程調度到物理CPU，2個過程：
1.客戶機線程調度到客戶機物理CPU 即 KVM vCPU，該調度由客戶機操作系統負責，每個客戶機操作系統的實現方式不同。在 KVM 上，vCPU 在客戶機系統看起來就像是物理 CPU，因此其調度方法也沒有什麼不同。
2.vCPU 線程調度到物理 CPU 即主機物理 CPU，該調度由 Hypervisor 即 Linux 負責。
KVM 使用標準的 Linux 進程調度方法來調度 vCPU 進程。Linux 系統中，線程和進程的區別是 進程有獨立的內核空間，線程是代碼的執行單位，也就是調度的基本單位。Linux 中，線程是就是輕量級的進程，也就是共享了部分資源(地址空間、文件句柄、信號量等等)的進程，所以線程也按照進程的調度方式來進行調度。
（1）Linux 進程調度。通常情況下，在SMP系統中，Linux內核的進程調度器根據自有的調度策略將系統中的一個可運行（runable）進程調度到某個CPU上執行。
（2）處理器親和性：可以設置 vCPU 在指定的物理 CPU 上運行
根據 Linux 進程調度策略，可以看出，在 Linux 主機上運行的 KVM 客戶機 的總 vCPU 數目最好是不要超過物理 CPU 內核數，否則，會出現線程間的 CPU 內核資源競爭，導致有虛機因爲 vCPU 進程等待而導致速度很慢。
5、客戶機CPU結構和模型
SMP類型的：-smp <n>[,cores=<ncores>][,threads=<nthreads>][,sockets=<nsocks>][,maxcpus=<maxcpus>]
numa類型的：-numa <nodes>[,mem=<size>][,cpus=<cpu[-cpu>]][,nodeid=<node>]
執行：qemu-kvm獲取主機所支持的CPU模型列表
每個 Hypervisor 都有自己的策略，來定義默認上哪些CPU功能會被暴露給客戶機。至於哪些功能會被暴露給客戶機系統，取決於客戶機的配置。qemu32 和 qemu64 是基本的客戶機 CPU 模型，但是還有其他的模型可以使用。你可以使用 qemu-kvm 命令的 -cpu <model> 參數來指定客戶機的 CPU 模型，還可以附加指定的 CPU 特性。"-cpu" 會將該指定 CPU 模型的所有功能全部暴露給客戶機，即使某些特性在主機的物理CPU上不支持，這時候QEMU/KVM 會模擬這些特性，因此，這時候也許會出現一定的性能下降。
RedHat Linux 6 上使用默認的 cpu64-rhe16 作爲客戶機 CPU model：
你可以指定特定的 CPU model 和 feature：
6、客戶機vCPU數目的分配方法
1)不是客戶機的 vCPU 越多，其性能就越好，因爲線程切換會耗費大量的時間；應該根據負載需要分配最少的 vCPU。
2)主機上的客戶機的 vCPU 總數不應該超過物理 CPU 內核總數。不超過的話，就不存在 CPU 競爭，每個 vCPU 線程在一個物理 CPU 核上被執行；超過的話，會出現部分線程等待 CPU 以及一個 CPU 核上的線程之間的切換，這會有 overhead。
3)將負載分爲計算負載和 I/O 負載，對計算負載，需要分配較多的 vCPU，甚至考慮 CPU 親和性，將指定的物理 CPU 核分給給這些客戶機。
我們來假設一個主機有 2 個socket，每個 socket 有 4 個core。主頻2.4G MHZ 那麼一共可用的資源是 2*4*2.4G= 19.2G MHZ。假設主機上運行了三個VM，VM1和VM2設置爲1socket*1core，VM3設置爲1socket*2core。那麼VM1和VM2分別有1個vCPU，而VM3有2個vCPU。假設其他設置爲缺省設置。那麼三個VM獲得該主機CPU資源分配如下：VM1：25%； VM2：25%； VM3:50%假設運行在VM3上的應用支持多線程，那麼該應用可以充分利用到所非配的CPU資源。2vCPU的設置是合適的。假設運行在VM3上的應用不支持多線程，該應用根本無法同時使用利用2個vCPU. 與此同時，VMkernal層的CPU Scheduler必須等待物理層中兩個空閒的pCPU，纔開始資源調配來滿足2個vCPU的需要。在僅有2vCPU的情況下，對該VM的性能不會有太大負面影響。但如果分配4vCPU或者更多，這種資源調度上的負擔有可能會對該VM上運行的應用有很大負面影響。
確定 vCPU 數目的步驟。假如我們要創建一個VM，以下幾步可以幫助確定合適的vCPU數目
也可以直接使用 -cpu host，這樣的話會客戶機使用和主機相同的 CPU model。
1]瞭解應用並設置初始值
該應用是否是關鍵應用，是否有Service Level Agreement。一定要對運行在虛擬機上的應用是否支持多線程深入瞭解。諮詢應用的提供商是否支持多線程和SMP（Symmetricmulti-processing）。參考該應用在物理服務器上運行時所需要的CPU個數。如果沒有參照信息，可設置1vCPU作爲初始值，然後密切觀測資源使用情況。
2]觀測資源使用情況
確定一個時間段，觀測該虛擬機的資源使用情況。時間段取決於應用的特點和要求，可以是數天，甚至數週。不僅觀測該VM的CPU使用率，而且觀測在操作系統內該應用對CPU的佔用率。特別要區分CPU使用率平均值和CPU使用率峯值。
假如分配有4個vCPU，如果在該VM上的應用的CPU
使用峯值等於25%， 也就是僅僅能最多使用25%的全部CPU資源，說明該應用是單線程的，僅能夠使用一個vCPU （4 * 25% = 1 ）
平均值小於38%，而峯值小於45%，考慮減少 vCPU 數目
平均值大於75%，而峯值大於90%，考慮增加 vCPU 數目
3] 更改vCPU數目並觀測結果
每次的改動儘量少，如果可能需要4vCPU，先設置2vCPU在觀測性能是否可以接受。
三、kvm的內存虛擬化
1、內存虛擬化
虛擬機的內存虛擬化很象現在的操作系統支持的虛擬內存方式，應用程序看到鄰近的內存地址空間，這個地址空間無需和下面的物理機器內存直接對應，操作系統保持着虛擬頁到物理頁的映射。現在所有的 x86 CPU 都包括了一個稱爲內存管理的模塊MMU（Memory Management Unit）和 TLB(Translation Lookaside Buffer)，通過MMU和TLB來優化虛擬內存的性能。
KVM 實現客戶機內存的方式是，利用mmap系統調用，在QEMU主線程的虛擬地址空間中申明一段連續的大小的空間用於客戶機物理內存映射。圖:mem_1、mem_2
VMM 內存虛擬化的實現方式：
軟件方式：通過軟件實現內存地址的翻譯，比如 Shadow page table （影子頁表）技術
硬件實現：基於 CPU 的輔助虛擬化功能，比如 AMD 的 NPT 和 Intel 的 EPT 技術
圖:mem_3
2、kvm內存虛擬化
KVM 中，虛機的物理內存即爲 qemu-kvm 進程所佔用的內存空間。KVM 使用 CPU 輔助的內存虛擬化方式。在 Intel 和 AMD 平臺，其內存虛擬化的實現方式分別爲：
AMD 平臺上的 NPT （Nested Page Tables） 技術
Intel 平臺上的 EPT （Extended Page Tables）技術
圖：mem_4
EPT的好處是，它的兩階段記憶體轉換，特點就是將 Guest Physical Address → System Physical Address，VMM不用再保留一份 SPT (Shadow Page Table)，以及以往還得經過 SPT 這個轉換過程。除了降低各部虛擬機器在切換時所造成的效能損耗外，硬體指令集也比虛擬化軟體處理來得可靠與穩定。
3、KSM（Kernel SamePage Merging 或者 Kernel Shared Memory）
KSM 在 Linux 2.6.32 版本中被加入到內核中。
原理：KSM 作爲內核中的守護進程（稱爲 ksmd）存在，它定期執行頁面掃描，識別副本頁面併合並副本，釋放這些頁面以供它用。因此，在多個進程中，Linux將內核相似的內存頁合併成一個內存頁。這個特性，被KVM用來減少多個相似的虛擬機的內存佔用，提高內存的使用效率。由於內存是共享的，所以多個虛擬機使用的內存減少了。這個特性，對於虛擬機使用相同鏡像和操作系統時，效果更加明顯。但是，事情總是有代價的，使用這個特性，都要增加內核開銷，用時間換空間。所以爲了提高效率，可以將這個特性關閉。
效果：在運行類似的客戶機操作系統時，通過 KSM，可以節約大量的內存，從而可以實現更多的內存超分，運行更多的虛機。（1）初始狀態：
圖:3.3-1
（2）合併後：
圖:3.3-2
（3）Guest 1 寫內存後：
圖:3.3-3
4、KVM Huge Page Backed Memory （巨頁內存技術）
Intel 的 x86 CPU 通常使用4Kb內存頁，當是經過配置，也能夠使用巨頁(huge page): (4MB on x86_32, 2MB on x86_64 and x86_32 PAE)
使用巨頁，KVM的虛擬機的頁表將使用更少的內存，並且將提高CPU的效率。最高情況下，可以提高20%的效率！使用方法，需要三部：
mkdir /dev/hugepages
mount -t hugetlbfs hugetlbfs /dev/hugepages
#保留一些內存給巨頁
sysctl vm.nr_hugepages=2048 （使用 x86_64 系統時，這相當於從物理內存中保留了2048 x 2M = 4GB 的空間來給虛擬機使用）
#給 kvm 傳遞參數 hugepages
qemu-kvm - qemu-kvm -mem-path /dev/hugepages
也可以在配置文件里加入：
<memoryBacking>
<hugepages/>
</memoryBacking>
驗證方式，當虛擬機正常啓動以後，在物理機裏查看：
cat /proc/meminfo |grep -i hugepages
參考博客：
http://www.cnblogs.com/yubo/archive/2010/04/23/1718810.html
http://www.cnblogs.com/sammyliu/p/4543597.html
http://www.cnblogs.com/zhaoyl/archive/2012/09/04/2671156.html //Linux進程調度
http://blog.chinaunix.net/uid-26000137-id-3761114.html //qeum-kvm io線程