什么是虛擬化？
一台PC機的組成包括：Keyboard(鍵盤)、Monitor(顯示器)、CPU、RAM、I/O(Disk，Network),這是基本的五大部件。
虛擬化就是在這些基礎物理設備上運行多個OS。
虛擬化面臨的重要問題概述：CPU、RAM、I/O的模擬。
CPU模擬:
(1) 所有OS設計時都認為Kernel是可以控制所有硬件,並可運行CPU的特權指令,即Kernel運行於CPU的Ring0上。
(2) 多個OS無法同時直接運行於硬件層之上,它們必須運行在Hypervisor層(下文稱:Host)上；就如同不安裝操作系統，
就不能安裝VMware,沒有VMware就無法讓虛擬機(下文稱:Guest)運行起來一樣。那問題來了,若GuestOS必須
運行在CPU的Ring0上,Host運行在哪里？
(3) OS設計時它認為自己是可以控制所有硬件資源的,那GuestOS之間不就可以相互影響了嗎？Guest1要關機,若
它直接執行CPU的特權指令關機,那它應該可以關閉整個物理機器,這不是虛擬化所希望的。
這些問題給CPU虛擬化帶來了諸多問題, 但實際上Host一定是真正能執行CPU的特權指令的,Guest運行起來后,它
實際控制的CPU是通過軟件模擬的CPU,實際上任何物理硬件都是通過集成電路進行運算,通過微代碼向外提供輸出結果
的接口,只有通過軟件模擬出這些接口就可以模擬硬件.
BT技術:
BinaryTranslation(二進制翻譯)技術,它可以讓Guest在發起特權指令時,直接將其翻譯為Host的系統調用,
以便加速Guest的執行性能.
BT技術出現是因為Guest用戶空間的APP要進行特權操作時,Guest上的APP需要先將請求發給Guest的Kernel,
Guest的Kernel經翻譯轉換發給模擬CPU,模擬CPU在將其轉換為Host的系統調用,再發給Host的Kernel，它再
進行翻譯轉換后給物理CPU執行.最后返回,這使得GuestOS的執行性能不高.
模擬CPU 和 虛擬CPU：
》模擬CPU：是完整虛擬,即模擬出CPU的環0,環1,環2,環3；這通常在底層硬件與虛擬環境的硬件不同時
采用模擬CPU的方式。
》虛擬CPU：僅模擬CPU的環0, Guest的用戶空間中的APP可直接運行在物理CPU的環3上,僅環0上的特權
指令進行翻譯.這是Guest的硬件環境與底層硬件環境一致時用。
完全虛擬化 和 半虛擬化:
》完全虛擬化(Full-Virtulization):
即Guest不知道自己是運行在虛擬化環境中,它一直都認為自己是可以控制全部的硬件資源.
因此需要將GuestOS對特權指令的操作都進行翻譯后，由Host帶為執行。
VMware的BT技術 和 AMD CPU的AMD-v、Intel的VT-x這兩種HVM(硬件虛擬化)技術實際
上都是完全虛擬化，因為它們都是幫助Host高效完成特權指令翻譯的技術。
注：
AMD-v 和 VT-x實現了將原先只有4環的CPU擴展為5環,並讓Host運行在-1環上,騰出環0給Guest用,
這樣Guest就認為自己是運行在環0上,並且可直接執行特權指令,但實際上,Guest調用環0上的特權指令時,
CPU會直接將其翻譯為真實的特權指令並激活Host的內核來調用環-1來執行特權指令，這進一步縮短了
翻譯流程。
Memory虛擬化:
(1) 在物理機中,內存的使用是經過虛擬化后，提供給物理機上運行的APP用的。
(2) 在物理機中,APP看到的內存是：
虛擬線性地址空間,即APP認為自己使用的是全部的物理內存,從0-1024(假設內存為1G)內核看到的內存是：
真實物理地址空間
(3) 由於物理機的內存已經被虛擬化過了, Guest訪問物理內存就需要再次被虛擬一層。
注:TLB: 轉換后頁面緩存
Host上的APP訪問內存的流程：
APP-->發送訪問線性地址:10page的數據-->CPU-->將10page的線性地址轉給MMU-->
查詢線性與物理地址映射表-->緩存映射關系到TLB,並讀取物理地址中的數據-->返回。
GuestOS上的APP訪問內存的流程：
Shadow Page Table的方式：
注: 假設將Guest的APP訪問的虛擬線程地址稱為:GVA.
將Guest虛擬機所獲得的虛擬物理內存地址稱為：GPA
Guest-APP-->發送訪問線性地址(GVA):10page的數據-->虛擬CPU-->
將其轉給虛擬MMU-->查詢並緩存映射到虛擬TLB-->
GPA的訪問請求被發給Host-->
但GPA並非Host的虛擬線性地址，又非真實物理地址,因此無法由真實CPU處理-->
Host上不得不采用軟件模擬來完成將GPA轉換為真實物理內存的物理地址，
此方式叫 Shadow page table(影子頁表)最終獲得物理內存中的數據，並返回給Guest.
Intel的EPT(Extended Page Table:擴展頁表) 和 AMD的NPT(Nested Page Table:嵌入頁表)技術
》MMU虛擬化 和 TLB虛擬化
注: TLB虛擬化: 由於GuestA和GuestB都被分配了1G的內存,GuestA和GuestB將具有相同的內存地址,
但GuestA和GuestB它們實際映射到Host上的物理內存的地址段肯定是不同的。但GuestA
訪問它的10page的數據若被緩存在TLB中，GuestB到CPU執行時,它恰巧也要訪問它的10page的數據
那TLB中緩存的條目肯定會對GuestB造成干擾，導致訪問錯誤，因此只能將TLB清空,即GuestB到CPU
上執行時,TLB是空的,因此CPU只能再通過MMU查映射關系,緩存TLB再訪問數據。這導致TLB成了擺設
沒有起到提高訪問物理內存效率的作用。這才出現了TLB的虛擬化, 而TLB的虛擬化將原先的只有兩個
字段緩存的TLB改成緩存三個字段: 一個GuestOS標識(實際為:VPID),一個GVA，一個HPA(Host中真實物理地址)。
Guest-APP-->發生訪問線性地址(GVA): 10page的數據--->這時訪問請求被同時發送了兩份,並同時分別走了以下路線
路線1-->虛擬CPU-->虛擬MMU-->虛擬TLB-->完成.
路線2-->EPT/NPT硬件實現的MMU-->EPT/NPT實現的TLB-->獲取真實物理地址中的數據-->返回給Guest.
這樣做后，即沒有改變GuestOS訪問內存的過程，同時提高了GuestOS訪問內存的效率。
注：
VPID(VirtualProcessorIdentifiers：虛擬處理器標識) ：它是在硬件上對TLB資源管理的優化,它給每個TLB項新增
了一個標識.用於不同vCPU的地址空間,從而能夠區分開Hypervisor和不同處理器的TLB。硬件區分了不同TLB
項分屬於不同的vCPU,因而避免了每次VM調出和調入時,讓全部的TLB失效這一動作,加速了VM切換和運行的效率。
查看EPT 和 VPID
grep -E 'ept|vpid' /proc/cpuinfo
或
cat /sys/module/kvm_intel/parameters/{ept,vpid}
關閉和開啟EPT 和 VPID的方法：
modprobe kvm_intel ept=0,vpid=0 && rmmod kvm_intel #關閉EPT和VPID.
modprobe kvm_intel ept=1,vpid=1 #開啟EPT和VPID.
I/O虛擬化：
(1) 外存設備虛擬化
磁盤、光驅、U盤
(2) 網絡設備虛擬化
網卡
(3) 輸入設備 ：
它的虛擬化采用角點當前被誰捕獲來模擬的,若當前被虛擬機捕獲,則會動態將模擬鍵盤或鼠標與物理設備關聯.
ps/2、USB
(4) 顯示設備 : 它不能被模擬。
VGA
I/O虛擬化的三種技術:
【注: 這三種技術只針對存儲和網絡，其I/O設備的模擬不采用這些技術。】
》模擬 ： 如VMware拿一個文件做為VM的磁盤,這就是模擬。
》半虛擬化：
模擬的過程：
Guest-APP去訪問I/O設備,如網卡,Guest-Kernel需要先調用虛擬網卡的驅動-->虛擬網卡驅動將數據
轉發給虛擬網卡-->虛擬網卡再轉給Hypervisor上模擬的網卡進程-->該網卡進程再將數據放入IO Stack(IO棧)中
等待真實網卡驅動將其轉給物理網卡並由其將數據轉發出去。
半虛擬化的過程：
Guest-APP去訪問I/O設備,如網卡,但此時GuestOS明確知道自己不能直接訪問到物理網卡,因此,
直接將數據轉給前端設備(它類似一個轉發器,但對GuestOS中的用戶看來它是一個網卡設備)-->
前端設備直接與Hypervisor上的網卡進程通信-->網卡進程將數據轉到IO Stack中-->
物理機驅動將其轉發給物理網卡。
注:
前端設備(IO frontend)：在Guest端省去了Guest虛擬網卡驅動的步驟。
后端設備(IO backend)：在Hypervisor端從虛擬網卡進程到物理網卡稱為后端設備。
》I/O透傳：
假如規划中該主機上需要運行4台虛擬機,該主機上安裝了6塊盤,6塊網卡,物理機磁盤和網卡都使用兩個，
剩余的都給虛擬機使用,那完全可以給每個虛擬機分一個物理磁盤和一個物理網卡,這樣其性能可幾乎
接近於硬件訪問，但這需要Hypervisor中的設備管理器來分配。
x86平台上DMA(直接內存訪問)是集中共享式管理的
假如當前Hypervisor管理着4塊網卡,現在GuestA和GuestB要發送數據到網卡上,
GuestA和GuestB都需要借助DMA來代其完成,但DMA是共享式管理,它僅僅負責接收
Kernel發來的命令然后,根據指示將指定內存地址中的數據發送到指定IO設備,如網卡,
或將網卡上收到的數據存入到指定的內存地址中。問題是Guest通過復雜的kernel調用
過程完成了DMA代其發送數據包到網卡,但GuestOS並不知道DMA將數據包發到那個網卡
上了，更沒有人知道回應的包到網卡后,應該轉發給那個GuestOS.
注:
DMA:它的作用是幫助Kernel完成一些需要長時間等待的任務,如：寫數據到磁盤,
從磁盤中讀數據到內存,將網卡上收到的數據讀到內存等; 這對提供Kernel的執行
效率是非常有幫助的。
IO設備：
每個IO設備上都有控制器,並且每個IO設備的控制器上都有寄存器且都有相應的端口地址。
IOMMU: IO內存地址管理單元
它的作用是自動將IO總線與相應的IO端口關聯的設備。
若需要將某塊網卡綁定給某GuestOS單獨使用,就需要在Hypervisor級別來控制對I/O端口的調用
就只能接受該GuestOS的調用了，而它的實現就需要借助DMA中實現IOMMU來完成。而Intel的VT-d
就是這樣一種技術，它在DMA中實現了IOMMU,並自動來完成IO總線與IO端口的映射關聯。
IOMMU的映射是完成將物理IO設備綁定給GuestOS的第一步,接着還需完成將物理IO設備的中斷信號
也要映射給該GuestOS,要知道物理設備在實現中斷映射通常采用中斷控制器 或 DMA等方式實現,而采用DMA方式
則需要DMA必須能夠訪問全部的物理內存,因為DMA需要將IO設備的寄存器中的數據搬到指定的內存地址空間
或反過來；而若將物理硬件綁定給GuestOS,則DMA就需要訪問GuestOS的全部物理內存,但實際上GuestOS
的內存是虛擬的,這就需要經過復雜的轉換后才能訪問到其對應的物理內存地址空間，這也進一步加大了
中斷信號與GuestOS的映射；而這還是完成虛擬機綁定硬件的第二步。
最后一步是完成IO設備緩沖區與GuestOS的映射,這里必須知道緩沖區一定是物理內存中的一段空間,如何讓
虛擬機的內核知道這是自己所管理的物理IO設備的IO緩沖區？；而這一切Intel的VT-d都幫我們實現了。
Intel的VT-d
簡單來說 VT-d 是一種基於北橋的硬件輔助虛擬化技術。
Intel的硬件輔助虛擬化技術：
CPU: vt-x， EPT， tagged-TLB
IO： vt-d，SR-IOV:單根設備虛擬化協議， VMDq
這些技術詳細分為三類：
第一類: 跟處理器相關: VT-x, EPT, tagged-TLB
第二類: 跟芯片相關: vt-d
第三類: 跟IO輸入輸出相關: VMDq 和 SR-IOV
IO虛擬化技術： QEMU(法國天才程序員開發) 、virtio(澳大利亞天才程序員開發)
KVM和Xen都需要借助以上兩種虛擬化技術實現IO虛擬化。
虛擬化技術分類：
(1) 模擬：【特點:虛擬硬件環境與底層硬件環境無關.】
著名的模擬器: PearPC, Bochs, QEMU
(2) 完全虛擬化: 【特點: 虛擬硬件環境與底層硬件環境必須一致。】
在完全虛擬化中通常采用兩種加速技術:
BT : 二進制翻譯加速技術
HVM: 基於硬件的虛擬化
知名的產品：
VMware Workstation, VMware Server, Parallels Disktop(iMac上用), KVM, Xen(HVM)
(3) 半虛擬化：【同樣要求虛擬硬件環境與底層硬件環境必須保持一致】
知名的開源產品: xen, uml(user-mode linux)
(4) OS級別的虛擬化（容器）:
OpenVZ, LXC(LinuX Container), libcontainer, Virtuozzo, Linux V Servers
Solaris Containers
FressBSD jails
(5) 庫虛擬化:
wine
網卡虛擬化-------橋接
通過讓網卡工作在混雜模式下,將收到的所有包都接收進來,最后將根據MAC來將數據包發給真實網卡和虛擬網卡。
CPU虛擬化------Ring0
在x86架構中CPU為了保護特權指令的運行，提供了指令的4個不同Privilege特權級別，術語稱
為Ring，從Ring 0～Ring 3。Ring 0的優先級最高,可運行所有特權指令，Ring 3最低。
而對於一個OS來說它必須是運行在Ring0上的，當然對於GuestOS來說也是如此，因此對於VMM
就必須模擬讓GuestOS認為自己是運行在Ring0上；這樣當GuestOS向CPU發送一個特權指令時，
VMM(虛擬機監控器,或叫Hypervisior)必須監測到並調用BT捕獲這個特權指令，在BT進程內部
將特權指令轉換為非特權指令，然后，由VMM向宿主OS發起請求進行處理。
BT(Binary Translation): 二進制翻譯器，它的作用是將GuestOS發出的特權指令轉換為非特權指令，
並交由宿主OS執行。它最早是由VMware采用的一種動態翻譯技術，它將捕獲的GuestOS發出的特權
指令直接在其進程內部進行轉換翻譯，最終達到VMM所允許執行的指令，再交由宿主OS執行。
由於VMM並不是所有特權指令都可捕獲,且有些特權指令執行失敗后，並不會返回給GuestOS
任何信息，還有在中斷虛擬化帶來的諸多問題VMM都不能很好的解決，因此，后來Intel和AMD分別
通過硬件實現了直接由CPU自身來實現虛擬化，即VT-x(intel) 和 AMD-V；這兩種解決方案的原理是
一樣的，在原先4個CPU等級執行環的基礎上新增量一個Ring-1的環，將所有CPU的特權指令放到Ring-1中，
並讓宿主機的Kernel可運行於Ring-1中，這就將Ring0空閑出來，接着讓GuestOS的Kernel可運行在
Ring0中，GuestOS執行的特性指令直接有CPU進行翻譯並交給Ring-1中 執行，這就是VT-X 和 AMD-V
實現的硬件虛擬化。
內存虛擬化
無內存虛擬化：
在沒有虛擬化時，GuestOS要請求內存空間時，它需要將請求的線性地址(虛擬地址:Virtual Address),
經MMU轉為Physical Address最后由VMM將GuestOS的PA轉交給真機的MMU，並由真機的MMU轉為
真機的PA,最后將數據存入真機的物理內存空間中。
有內存虛擬化：
GuestOS依然按它必須的方式將VA---->MMU---->PA,這個過程在GuestOS內部還是要走的,因為這是OS的
固定運行機制；而在內存虛擬化這種方式下,真機上被虛擬出了一個MMU,將GuestOS的VA(虛擬地址)又轉了
一份給真機虛擬的MMU,由真機虛擬的MMU直接將GuestOS的VA轉為真機的PA，而真機的PA與GuestOS的
PA之間是建立了一種透明的映射關系,就如：GuestOS的PA2就對應真機的PA10一樣。
真機上虛擬的MMU,又稱為影子MMU,它是對MMU芯片的虛擬化；Intel推出了一個EPT
(擴展頁表技術)而AMD推出了一個NPT(嵌套頁表技術)，他倆都是影子MMU的硬件虛擬化解決方案；
它們實現的方式是：原先影子MMU實現是這樣的，假如現在有A和B兩個GuestOS,CPU是輪流分別
處理它們的請求當CPU執行到A的時候,會將A請求的VA(Virtual Address)經影子MMU轉換為真機的
PA(Physical Address),並緩存在一個叫TLB的硬件芯片中存儲;當GuestOS A使用完本次的CPU時間片后,
CPU需要將A切到后台,將B切到前台執行,但為了防止B在執行過程中誤用A緩存在TLB中的結果,故必須
將其清空;當GuestOS A再次被調入前台執行時，發現自己的TLB被清空了,因此它會再次向影子MMU
發出內存空間的請求, 經轉換后在經結果緩存在TLB中,這時B的TLB緩存已經被清空了，這使得TLB緩存
目的變的沒有意義了。然而，EPT和NPT他們則通過在TLB中為每個GuestOS加入一個標記位，來區分
各自的緩存結果,這樣每次GuestOS切換回來后，直接在TLB中找到自己的標記就可以獲取MMU的轉換結果。
內存虛擬化的硬件解決方案:
Intel 和AMD分別通過EPT(Extended Page Tables)和 NPT(Nested Page Tables)為虛擬化應用提升影子MMU的性能,
並通過標記（tagged)TLB來避免虛擬機切換時頻繁清寫（flush）TLB以提高TLB緩存的命中率。
提升VM訪問PCI和PCIe硬件設備的硬件虛擬化解決方案:
Intel VT-d(Virtualization Technology for Directed I/O) 和 AMD Vi(也叫IOMMU) ：
深入了解VT-d和VT-x可參考: http://virtual.51cto.com/art/201102/245920.htm
PCI硬件設備對VT-d技術的支持與否,決定了VM是否可獨占使用該物理設備.並且這種使用
幾乎是不需要Hypervisor參與的。但是要真正實現VM直接使用物理設備,還需要中斷重映射
(Interrupt Remapping) 和DMA虛擬化(其中DMAR的核心芯片就是IOMMU) 的支持.
DMAR(DMA remapping):
它是Intel為支持虛擬化而設計的I/O虛擬化技術,它可簡單理解為替代軟件實現的影子頁表,但真正執行
將GuestOS的虛擬內存地址轉換為宿主機的物理地址的硬件芯片是IOMMU。DMAR出現的原因是
DMA只能訪問內存中的低地址空間,而且必須是連續的,這對虛擬化來說很難實現,因此Intel才在其CPU
重新實現了DMA,讓虛擬機能自由的訪問內存中任意地址空間,且可不連續。
IOMMA不僅將DMA地址虛擬化，還起到隔離、保護等作用，如下圖所示意，詳細請參閱Intel Virtualization Technology for Directed I/O
#深入理解DMAR和IRQ虛擬化參考,由於本人理解有限,這部分是引用http://virtual.51cto.com/art/201102/245920.htm
這篇博文的，僅作參考:
傳統的IOMMUs（I/O memory management units，I/O內存管理單元）提供了一種集中的方式管理所有的DMA——
除了傳統的內部DMA，還包括如AGP GART、TPT、RDMA over TCP/IP等這些特別的DMA，它通過在內存地址范圍
來區別設備，因此容易實現，卻不容易實現DMA隔離，因此VT-d通過更新設計的IOMMU架構， 實現了多個DMA
保護區域的存在，最終實現了DMA虛擬化。這個技術也叫做DMA Remapping。
I/O設備會產生非常多的中斷請求，I/O虛擬化必須正確地分離這些請求，並路由到不同的虛擬機上。
傳統設備的中斷請求可以具有兩種方式：一種 將通過I/O中斷控制器路由，一種是通過DMA寫請求直接
發送出去的MSI（message signaled interrupts，消息中斷），由於需要在DMA請求內嵌入目標
內存地址，因此這個架構須要完全訪問所有的內存地址，並不能實現中斷隔離。
VT-d實現的中斷重映射（interrupt-remapping）架構通過重新定義MSI的格式來解決這個問題，
新的MSI仍然是一個 DMA寫請求的形式，不過並不嵌入目標內存地址，取而代之的是一個消息ID，
通過維護一個表結構，硬件可以通過不同的消息ID辨認不同的虛擬機區域。 VT-d實現的中斷重映射
可以支持所有的I/O源，包括IOAPICs，以及所有的中斷類型，如通常的MSI以及擴展的MSI-X。
VT-d進行的改動還有很多，如硬件緩沖、地址翻譯等，通過這些種種措施，VT-d實現了北橋芯片
級別的I/O設備虛擬化。VT-d最終體現到虛擬化模型上的就是新增加了兩種設備虛擬化方式：
左邊是傳統的I/O模擬虛擬化，右邊是直接I/O設備分配
直接I/O設備分配：
虛擬機直接分配物理I/O設 備給虛擬機，這個模型下，虛擬機內部的驅動程序
直接和硬件設備直接通信，只需要經過少量，或者不經過VMM的管理。為了系統的健壯性，需要硬件的
虛擬化支 持，以隔離和保護硬件資源只給指定的虛擬機使用，硬件同時還需要具備多個I/O容器分區來
同時為多個虛擬機服務，這個模型幾乎完全消除了在VMM中運行驅 動程序的需求。例如CPU，雖然
CPU不算是通常意義的I/O設備——不過它確實就是通過這種方式分配給虛擬機，當然CPU的資源還處在
VMM的管理之 下。
I/O設備共享：
這個模型是I/O分配模型的一個擴展，對硬件具有很高的要求，需要設備支持多個功能接口，
每個接口可以單獨分配給一個虛擬機，這個模型無疑可以提供非常高的虛擬化性能表現。
運用VT-d技術，虛擬機得以使用直接I/O設備分配方式或者I/O設備共享方式來代替傳統的設備模擬/額外設備
接口方式，從而大大提升了虛擬化的I/O性能。
虛擬化的三大分類:
1. Full-Virtualization 完全虛擬化
【CPU不支持硬件虛擬化技術:模擬特權】
【CPU支持硬件虛擬化，VMM運行Ring-1,而GuestOS運行在Ring0，
此為硬件輔助的虛擬化：Hardware Asistant VM】
完全虛擬化缺點：
GuestOS的操作必須先通過System Call轉給宿主OS最終將結果，經過多道工序后返回給GuestOS。
如：GuestOS向外發包時，它先將包封裝后發給VMM，有VMM交由宿主OS，經CPU處理最終交由
宿主機的物理網卡，將包發出。
2. Para-Virtualization：半虛擬化（又稱PV）
讓GuestOS內核明確知道自己是工作虛擬環境中,要使用真實設備，可調用宿主機上專用的系統調用
來訪問宿主主機的物理硬件,而非自己直接訪問【所謂系統調用可簡單理解為：驅動】；如：可將GuestOS
訪問物理網卡做成系統調用，當GuestOS需要訪問物理網卡時，就可明確告訴它可直接通過系統調用來訪問
物理網卡，這樣可繞過宿主OS的參與直接完成訪問，其效率更高；由此來說CPU的指令集也是可以做出
系統調用的，這樣做不僅可讓GuestOS執行效率更高，而且還可去掉監聽，捕獲，及模擬指令集等冗余模塊。
但這就必須涉及到系統內核的修改，因此對於開源的Linux是可行的但對於閉源的Windows則是不可以的。
【注意：上面提到到虛擬機專用的System Call，實際是Hypervisor Call,它又叫：Hypercall】
3. PV on HVM（Para-Virtualization on Hardware Virtual Machine）
PV和硬件虛擬化技術結合起來用，可讓虛擬化不受OS的限制；用PV可解決開源OS中CPU的半虛擬化；
而Intel的VT-X和AMD的AMD-V可實現對CPU的硬件虛擬化，由硬件來完成GuestOS發出的特權指令的轉換，
而無需將CPU的特權指令輸出為Hypercall；而對於I/O（磁盤和網卡）和內存依然采用PV的方式實現。
虛擬機的三種通用模型：
第一種模型：OS+VMM 實現了Hypervisor的功能。這種是工作站中常見的模型，典型的有VMware Workstations。
第二種模型：VMM直接運行在硬件層之上，並提供硬件所需要的所有驅動，同時還提供了一個OS內核
所必須的各種功能，但這些功能通常是專門為運行在其上的虛擬機而設計的,如：創建，刪除虛擬機等。。
典型的有：VMware ESX，和VMware ESXi
第三種模型：Xen模型，Xen這種模型比較特殊，它雖然直接運行於硬件層之上，但它卻並沒有提供驅動所有硬件
的驅動，它僅僅提供了主要設備CPU，Interrupt(中斷)，Memory的驅動，因此它采用了一種取巧的方式，
要安裝Xen就先安裝一個主虛擬機，由它來驅動底層硬件；而所有虛擬機要訪問CPU，Interrupt，內存時，
Xen才自己來調度，為每個VM提供服務；在Xen中每台VM都被稱為一個Domain,它們安照順序排列
Dom0是Xen中在主VM，它也是特權VM。
三種模型所演變的五種虛擬機模型如下：
1. Xen模型的基本工作原理：
在Xen模型中Xen將管理GuestOS（GuestOS在Xen中被稱為DomU）的功能給了Dom0，當DomU要創建一個網卡,
在實現上是在Dom0上創建虛擬網卡軟件,DomU僅顯示已創建即可，當DomU要訪問物理網卡時,DomU實際是先將包發給
Xen的Hypercall，接着由Hypercall將請求轉給Dom0的虛擬網卡(Vnet)，最后Dom0對I/O硬件有直接操作的能力，因此
它直接繞過Xen將請求交給物理網卡發出；僅當DomU和Dom0要訪問CPU，內存，中斷時，才直接有Xen來調度處理。
Xen支持三種虛擬化類型:
PV(純半虛擬化)：
Xen是原生支持虛擬化的“先鋒人物”，若CPU，IO，Memory都不支持硬件虛擬化，Xen也可
提供高性能的半虛擬化方案，因為Xen使用Dom0來直接管理硬件，DomU要訪問硬件時，先將請求
發給Xen的HyperCall並由Hypercall將請求轉交給Dom0的虛擬硬件,最終由Dom0的虛擬硬件將請求
直接發給物理設備。
PV on HVM：
若構建Xen的硬件環境中，CPU支持AMD-V 或 VT-X，Memory支持AMD的NPT 或 Intel的EPT，
則Xen可以直接實現PV on HVM。這種性能最佳
Full：
Xen是可以直接實現完全虛擬化的,在完全虛擬化中，Dom0可通過軟件模擬I/O ， CPU指令集 和 其他硬件，
做為DomU的OS也無需修改操作系統的內核就可以直接運行在這種模式下，但其最大的缺點也很明顯，就是
通過軟件模擬的硬件性能會很差；但若CPU支持硬件虛擬化，也可在一定程度上提升性能。
Xen的重要工具和組件：
Qemu：Qemu是Dom0用來創建虛擬硬件的主要組件；Qemu最先是由法國的一位天才程序員開發的可跨
平台的硬件模擬器，其大小1M左右,小巧精悍，如：底層物理處理器是X86平台，使用Qemu就可模擬
一個蘋果的ARM處理器，甚至是PowerPC處理器，若上層模擬的處理器與物理處理器一致，它還可以
起到一定程度的硬件加速功能；通常Xen與Qemu共同使用，來為虛擬機建立模擬的網卡，硬盤(它
甚至可以模擬VMware的虛擬硬盤)等。
XM：它是Xen提供的VM管理工具，如創建，刪除，暫停，關閉，快照虛擬機等，XM主要是借助與Xen
輸出的API接口實現這些功能的。XM還可借助Xen的API為虛擬機動態添加CPU，且可模擬多顆，
不受物理CPU個數的限制。
Openstand：它是XM的一種圖形實現方式，它的功能也非常強大。
2. 第二種虛擬化模型---------KVM（Kernel-based Virtual Machine：基於內核的虛擬機）
KVM最早是以色列的一家軟件公司開發的，后被Redhat收購，Kernel2.6.20后KVM被整合到Kernel中，
加上紅帽對它的大力支持，現在KVM也是相對不錯的。
KVM的工作方式是：
將虛擬OS運行於用戶空間，它們就向進程一樣，而這些虛擬的GuestOS的所有硬件都是由Qemu模擬出來的，
如網卡，硬盤等，GuestOS要訪問物理設備，必須先將請求發給Qemu模擬的硬件設備，該設備實際是一個
用戶進程,由模擬的硬件負責將請求發給當前系統的內核來處理，最終由當前OS操作物理網卡完成數據發送。
注意：Qemu它自身完全可以做為一個虛擬服務器使用，但為何不直接使用Qemu，而使用KVM？
其主要原因在於Qemu可模擬所有硬件但它模擬的硬件是做為一個進程運行於用戶空間中的，
而KVM確是運行在內核空間中的模塊，它訪問的硬件的速度比用戶空間的進程更高效。
KVM+Qemu：這個組合僅限於64位平台，且CPU必須支持硬件虛擬化（VT-X或AMD-V）。
KVM和Xen被加入內核的時間
內核版本2.6.20 以后KVM被整合到Kernel中。
2.6.37后，可運行DomU的Xen被加入Kernel。
3.0.0后 運行於Dom0中的Xen也被加入內核。
Xen最早是由英國劍橋大學主導開發，現在以被Citrix(思傑)收購【思傑：全球第二大虛擬化解決方案提供商】
KVM： virtio 是紅帽提供的對KVM的I/O半虛擬化的增強技術，目前KVM已經支持透傳I/O技術。
3. 第一種虛擬化模型----------Container(容器)
這種虛擬化解決方案是每個用戶空間就是一個GuestOS，他們都被模擬出了一個硬盤，網卡等設備，
他們使用公共的OS，其性能比兩個內核的虛擬化要高的多。但缺點也是很明顯的，每個虛擬機之間的
隔離性較差，若一個VM將OS搞崩潰了，則所有的VM全部都會崩潰；雖有這方面的隱患，但目前其穩定性
也是比較可以的。
目前較流行的有：Docker，OpenVZ, Solaris Container, BSD Jails
4. 第一種虛擬化模型----------模擬器實現的虛擬化：
模擬硬件層：使用類似於Qemu的工具，來模擬所有GuestOS需要的硬件(如：CPU，內存，硬盤等....)
這種方式其遷移將變的非常方便，但其性能很差，這種完全虛擬化方案中Guestos的所有操作都由虛擬硬件翻譯后，
交由宿主OS執行。
5. 最后一種也是第一種模型，其實就類似於VMware Workstation，VirtualBox
附件1：
1974年Pepek 和 Goldberg在一篇論文中定義了“經典虛擬化（Classical virtualization)"的基本需求，
他們認為，一款真正意義上的VMM至少符合三個方面的標准：
1》等價執行（Equivalient Execution）:除了資源的可用性及時間上的不同之外,程序的在虛擬化環境中
及真實環境中的執行是完全相同的。
2》性能（Performance）：指令集中的大部分指令要能夠直接運行於CPU上；
3》安全（Safety）：VMM要能夠完全控制系統資源；
X86平台實現虛擬化技術的挑戰：
X86處理器有4個特權級別,Ring 0 ~ Ring 3,只有運行在Ring 0~2級時，處理器才可訪問特權資源或執行
特權指令；運行在Ring 0級時，處理器可以允許所有的特權指令，x86平台上的操作系統一般只使用Ring 0 和
Ring 3兩個級別，其中，操作系統運行在Ring 0級,用戶進程在Ring 3級。
特權級壓縮(Ring compression)
為了滿足上面所述的需求，VMM自身必須運行在Ring 0級,同時為了避免GuestOS控制系統資源，GuestOS
不得不降低自身的運行級別而運行於Ring 1 或 Ring 3(Ring 2不使用)，此外，VMM使用分頁或段限制的方式
保護物理內存的訪問，但是64位模式下段限制不起作用，而分頁又不區分Ring 0,1,2 為了統一和簡化VMM的設計，
GuestOS只能和用戶進程一樣運行在Ring3。 VMM必須監視GuestOS對GDT， IDT(這些是CPU的敏感寄存器,
如:指令寄存器)等特權資源的設置，防止GuestOS運行在Ring 0級，同時又要保護降級后的GuestOS不受Guest
進程的主動或無意破壞。
特權級別名(Ring Alias)
設計上的原因，操作系統假設自己運行於Ring 0，然而虛擬化環境中的GuestOS實際上運行於Ring1或 Ring 3，
由此,VMM必須保證各GuestOS不能得知其正運行於虛擬機中這一事實，以免其打破前面的“等價執行”標准，
例如：x86處理器的特權級別存放在CS代碼段寄存器內，GuestOS卻可以使用非特權PUSH指令將CS寄存器壓棧，
然后，POP出來檢查該值；又如：GuestOS在低特權級別時讀取特權寄存器GDT，LDT，IDT和TR（這些是CPU內部
的敏感寄存器,如：指令寄存器...）時並不發生異常，這些行為都不同於GuestOS的正常期望。
地址空間壓縮（Address Space Compression）
地址空間壓縮是指VMM必須在GuestOS的地址空間中保留一段供自己使用,這是x86虛擬化技術面臨的另一個挑戰。
VMM可完全運行於自有地址空間，也可部分運行於GuestOS的地址空間，前一種方式,需在VMM模式與GuestOS模式
之間切換，這會帶來較大的開銷此外,盡管運行於自己的地址空間,VMM依然需要在GuestOS的地址空間保留出一部分
來保存控制結構，如IDT和GDT。無論是哪一種方式，VMM必須保證自己用到的地址空間不會受到GuestOS的訪問后修改。
非特權敏感指令
x86使用的敏感指令並不完全隸屬於特權指令集，VMM將無法正確捕獲此類指令並作出處理。例如，非特權指令SMSW在寄存器
中存儲的機器狀態就能夠被GuestOS所讀取，這違反了經典虛擬化理論的要求。
靜默特權失敗（Silent privilege Failures）
x86在某些特權指令在失敗時並不返回錯誤，因此，其錯誤將無法被VMM捕獲，這將導致其違反經典虛擬化信條中的“等價執行”法則。
中斷虛擬化(Interrupt Virtualization)
虛擬化環境中，屏蔽中斷及非屏蔽中斷的管理都應該有VMM進行,然而，GuestOS對特權資源的每次訪問都會觸發處理器異常，
這必然會頻繁屏蔽或啟用中斷，若這些請求均由VMM處理，勢必會極大影響整體系統性能。
X86平台虛擬化
完整意義上的計算機由硬件平台和軟件平台共同組成，根據計算機體系結構理論，其硬件平台包括CPU，內存和各種I/O設備；
而軟件平台則包括BIOS，操作系統，運行時庫及各種應用程序，對於主機虛擬化技術來講，其主要負責虛擬硬件平台及BIOS，而
操作系統，運行時庫及各種應用程序可使用以往在物理平台上各種現在技術及產品。