CPU虚拟化技术
基本概念：
- 物理CPU數(shù)量：實際服務器插槽上的CPU個數(shù)；
- 核：一塊CPU上面能處理數(shù)據(jù)的芯片組的數(shù)量；
- 超線程：在一個實體芯片組中提供兩個邏輯線程；
- 邏輯CPU數(shù)量：物理CPU數(shù)量*核*超線程（若支持超線程，該值為2）；
- vCPU:虛機分配的CPU，一個服務器或集群可分配的vCPU數(shù)量為為 （邏輯CPU數(shù)量 - （控制臺需要的邏輯ｃｐｕ數(shù)量））× 虛擬化比例因子（考慮過載，預估為１．２～１．５）
1. 為什么需要 CPU 虛擬化
X86 操作系統(tǒng)是設計在直接運行在裸硬件設備上的，因此它們自動認為它們完全占有計算機硬件。x86 架構(gòu)提供四個特權(quán)級別給操作系統(tǒng)和應用程序來訪問硬件。?Ring 是指 CPU 的運行級別，Ring 0是最高級別，Ring1次之，Ring2更次之……?就 Linux+x86 來說，?
- 操作系統(tǒng)（內(nèi)核）需要直接訪問硬件和內(nèi)存，因此它的代碼需要運行在最高運行級別 ?Ring0上，這樣它可以使用特權(quán)指令，控制中斷、修改頁表、訪問設備等等。?
- 應用程序的代碼運行在最低運行級別上ring3上，不能做受控操作。如果要做，比如要訪問磁盤，寫文件，那就要通過執(zhí)行系統(tǒng)調(diào)用（函數(shù)），執(zhí)行系統(tǒng)調(diào)用的時候，CPU的運行級別會發(fā)生從ring3到ring0的切換，并跳轉(zhuǎn)到系統(tǒng)調(diào)用對應的內(nèi)核代碼位置執(zhí)行，這樣內(nèi)核就為你完成了設備訪問，完成之后再從ring0返回ring3。這個過程也稱作用戶態(tài)和內(nèi)核態(tài)的切換。
那么，虛擬化在這里就遇到了一個難題，因為宿主操作系統(tǒng)是工作在 ring0 的，客戶操作系統(tǒng)就不能也在 ring0 了，但是它不知道這一點，以前執(zhí)行什么指令，現(xiàn)在還是執(zhí)行什么指令，但是沒有執(zhí)行權(quán)限是會出錯的。所以這時候虛擬機管理程序（VMM）需要避免這件事情發(fā)生。 虛機怎么通過 VMM 實現(xiàn) Guest CPU 對硬件的訪問，根據(jù)其原理不同有三種實現(xiàn)技術(shù)：
1. 全虛擬化
2. 半虛擬化
3. 硬件輔助的虛擬化?
?
1.1 基于二進制翻譯的全虛擬化（Full Virtualization with Binary Translation）
?
客戶操作系統(tǒng)運行在?Ring 1，它在執(zhí)行特權(quán)指令時，會觸發(fā)異常（CPU的機制，沒權(quán)限的指令會觸發(fā)異常），然后 VMM 捕獲這個異常，在異常里面做翻譯，模擬，最后返回到客戶操作系統(tǒng)內(nèi)，客戶操作系統(tǒng)認為自己的特權(quán)指令工作正常，繼續(xù)運行。但是這個性能損耗，就非常的大，簡單的一條指令，執(zhí)行完，了事，現(xiàn)在卻要通過復雜的異常處理過程。
異常 “捕獲（trap）-翻譯（handle）-模擬（emulate）” 過程：
1.2. 超虛擬化（或者半虛擬化/操作系統(tǒng)輔助虛擬化 Paravirtualization）?
? 半虛擬化的思想就是，修改操作系統(tǒng)內(nèi)核，替換掉不能虛擬化的指令，通過超級調(diào)用（hypercall）直接和底層的虛擬化層hypervisor來通訊，hypervisor?同時也提供了超級調(diào)用接口來滿足其他關(guān)鍵內(nèi)核操作，比如內(nèi)存管理、中斷和時間保持。
? 這種做法省去了全虛擬化中的捕獲和模擬，大大提高了效率。所以像XEN這種半虛擬化技術(shù)，客戶機操作系統(tǒng)都是有一個專門的定制內(nèi)核版本，和x86、mips、arm這些內(nèi)核版本等價。這樣以來，就不會有捕獲異常、翻譯、模擬的過程了，性能損耗非常低。這就是XEN這種半虛擬化架構(gòu)的優(yōu)勢。這也是為什么XEN只支持虛擬化Linux，無法虛擬化windows原因，微軟不改代碼啊。
1.3. 硬件輔助的全虛擬化?
? ? 2005年后，CPU廠商Intel 和 AMD?開始支持虛擬化了。 Intel 引入了 Intel-VT （Virtualization Technology）技術(shù)。 這種 CPU，有 VMX root operation 和 VMX non-root operation兩種模式，兩種模式都支持Ring 0 ~ Ring 3 共?4 個運行級別。這樣，VMM 可以運行在 VMX root operation模式下，客戶 OS 運行在VMX non-root operation模式下。
? 而且兩種操作模式可以互相轉(zhuǎn)換。運行在 VMX root operation 模式下的 VMM 通過顯式調(diào)用 VMLAUNCH 或 VMRESUME 指令切換到 VMX non-root operation 模式，硬件自動加載 Guest OS 的上下文，于是 Guest OS 獲得運行，這種轉(zhuǎn)換稱為 VM entry。Guest OS 運行過程中遇到需要 VMM 處理的事件，例如外部中斷或缺頁異常，或者主動調(diào)用 VMCALL 指令調(diào)用 VMM 的服務的時候（與系統(tǒng)調(diào)用類似），硬件自動掛起 Guest OS，切換到 VMX root operation 模式，恢復 VMM 的運行，這種轉(zhuǎn)換稱為 VM exit。VMX root operation 模式下軟件的行為與在沒有 VT-x 技術(shù)的處理器上的行為基本一致；而VMX non-root operation 模式則有很大不同，最主要的區(qū)別是此時運行某些指令或遇到某些事件時，發(fā)生 VM exit。
?
也就說，硬件這層就做了些區(qū)分，這樣全虛擬化下，那些靠“捕獲異常-翻譯-模擬”的實現(xiàn)就不需要了。而且CPU廠商，支持虛擬化的力度越來越大，靠硬件輔助的全虛擬化技術(shù)的性能逐漸逼近半虛擬化，再加上全虛擬化不需要修改客戶操作系統(tǒng)這一優(yōu)勢，全虛擬化技術(shù)應該是未來的發(fā)展趨勢。
?
? | 利用二進制翻譯的全虛擬化 | 硬件輔助虛擬化 | 操作系統(tǒng)協(xié)助/半虛擬化 |
| 實現(xiàn)技術(shù) | BT和直接執(zhí)行 | 遇到特權(quán)指令轉(zhuǎn)到root模式執(zhí)行 | Hypercall |
| 客戶操作系統(tǒng)修改/兼容性 | 無需修改客戶操作系統(tǒng)，最佳兼容性 | 無需修改客戶操作系統(tǒng)，最佳兼容性 | 客戶操作系統(tǒng)需要修改來支持hypercall，因此它不能運行在物理硬件本身或其他的hypervisor上，兼容性差，不支持Windows |
| 性能 | 差 | 全虛擬化下，CPU需要在兩種模式之間切換，帶來性能開銷；但是，其性能在逐漸逼近半虛擬化。 | 好。半虛擬化下CPU性能開銷幾乎為0，虛機的性能接近于物理機。 |
| 應用廠商 | VMware Workstation/QEMU/Virtual PC | VMware ESXi/Microsoft Hyper-V/Xen 3.0/KVM | Xen |
2. KVM CPU 虛擬化
KVM 是基于CPU 輔助的全虛擬化方案，它需要CPU虛擬化特性的支持。
2.1. CPU 物理特性
這個命令查看主機上的CPU 物理情況：
[s1@rh65 ~]$ numactl --hardware available: 2 nodes (0-1) //2顆CPU node 0 cpus: 0 1 2 3 4 5 12 13 14 15 16 17 //這顆 CPU 有8個內(nèi)核 node 0 size: 12276 MB node 0 free: 7060 MB node 1 cpus: 6 7 8 9 10 11 18 19 20 21 22 23 node 1 size: 8192 MB node 1 free: 6773 MB node distances: node 0 1 0: 10 21 1: 21 10要支持 KVM， Intel CPU 的 vmx 或者 AMD CPU 的 svm 擴展必須生效了：
[root@rh65 s1]# egrep "(vmx|svm)" /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm arat epb dts tpr_shadow vnmi flexpriority ept vpid2.2 多 CPU 服務器架構(gòu)：SMP，NMP，NUMA
從系統(tǒng)架構(gòu)來看，目前的商用服務器大體可以分為三類：
- 多處理器結(jié)構(gòu) (SMP ： Symmetric Multi-Processor)：所有的CPU共享全部資源，如總線，內(nèi)存和I/O系統(tǒng)等，操作系統(tǒng)或管理數(shù)據(jù)庫的復本只有一個，這種系統(tǒng)有一個最大的特點就是共享所有資源。多個CPU之間沒有區(qū)別，平等地訪問內(nèi)存、外設、一個操作系統(tǒng)。SMP 服務器的主要問題，那就是它的擴展能力非常有限。實驗證明， SMP 服務器 CPU 利用率最好的情況是 2 至 4 個 CPU 。
- 海量并行處理結(jié)構(gòu) (MPP ： Massive Parallel Processing)?：NUMA 服務器的基本特征是具有多個 CPU 模塊，每個 CPU 模塊由多個 CPU( 如 4 個 ) 組成，并且具有獨立的本地內(nèi)存、 I/O 槽口等。在一個物理服務器內(nèi)可以支持上百個 CPU 。但 NUMA 技術(shù)同樣有一定缺陷，由于訪問遠地內(nèi)存的延時遠遠超過本地內(nèi)存，因此當 CPU 數(shù)量增加時，系統(tǒng)性能無法線性增加。
- MPP 模式則是一種分布式存儲器模式，能夠?qū)⒏嗟奶幚砥骷{入一個系統(tǒng)的存儲器。一個分布式存儲器模式具有多個節(jié)點，每個節(jié)點都有自己的存儲器，可以配置為SMP模式，也可以配置為非SMP模式。單個的節(jié)點相互連接起來就形成了一個總系統(tǒng)。MPP可以近似理解成一個SMP的橫向擴展集群，MPP一般要依靠軟件實現(xiàn)。
- 非一致存儲訪問結(jié)構(gòu) (NUMA ： Non-Uniform Memory Access)：它由多個 SMP 服務器通過一定的節(jié)點互聯(lián)網(wǎng)絡進行連接，協(xié)同工作，完成相同的任務，從用戶的角度來看是一個服務器系統(tǒng)。其基本特征是由多個 SMP 服務器 ( 每個 SMP 服務器稱節(jié)點 ) 通過節(jié)點互聯(lián)網(wǎng)絡連接而成，每個節(jié)點只訪問自己的本地資源 ( 內(nèi)存、存儲等 ) ，是一種完全無共享 (Share Nothing) 結(jié)構(gòu)。
詳細描述可以參考?SMP、NUMA、MPP體系結(jié)構(gòu)介紹。
查看你的服務器的 CPU 架構(gòu)：
[root@rh65 s1]# uname -a Linux rh65 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux #這服務器是 SMP 架構(gòu)?2.2 KVM CPU 虛擬化
2.2.1 KVM 虛機的創(chuàng)建過程
可見：
（1）qemu-kvm 通過對 /dev/kvm 的 一系列 ICOTL 命令控制虛機，比如
open("/dev/kvm", O_RDWR|O_LARGEFILE) = 3 ioctl(3, KVM_GET_API_VERSION, 0) = 12 ioctl(3, KVM_CHECK_EXTENSION, 0x19) = 0 ioctl(3, KVM_CREATE_VM, 0) = 4 ioctl(3, KVM_CHECK_EXTENSION, 0x4) = 1 ioctl(3, KVM_CHECK_EXTENSION, 0x4) = 1 ioctl(4, KVM_SET_TSS_ADDR, 0xfffbd000) = 0 ioctl(3, KVM_CHECK_EXTENSION, 0x25) = 0 ioctl(3, KVM_CHECK_EXTENSION, 0xb) = 1 ioctl(4, KVM_CREATE_PIT, 0xb) = 0 ioctl(3, KVM_CHECK_EXTENSION, 0xf) = 2 ioctl(3, KVM_CHECK_EXTENSION, 0x3) = 1 ioctl(3, KVM_CHECK_EXTENSION, 0) = 1 ioctl(4, KVM_CREATE_IRQCHIP, 0) = 0 ioctl(3, KVM_CHECK_EXTENSION, 0x1a) = 0（2）一個?KVM 虛機即一個 Linux qemu-kvm 進程，與其他 Linux 進程一樣被Linux 進程調(diào)度器調(diào)度。
（3）KVM 虛機包括虛擬內(nèi)存、虛擬CPU和虛機 I/O設備，其中，內(nèi)存和 CPU 的虛擬化由 KVM 內(nèi)核模塊負責實現(xiàn)，I/O 設備的虛擬化由 QEMU 負責實現(xiàn)。
（3）KVM戶機系統(tǒng)的內(nèi)存是 qumu-kvm 進程的地址空間的一部分。
（4）KVM 虛機的 vCPU 作為 線程運行在 qemu-kvm 進程的上下文中。
vCPU、QEMU 進程、LInux 進程調(diào)度和物理CPU之間的邏輯關(guān)系：
2.2.2 因為 CPU 中的虛擬化功能的支持，并不存在虛擬的 CPU，KVM Guest 代碼是運行在物理 CPU 之上
? ? 根據(jù)上面的 1.3 章節(jié)，支持虛擬化的 CPU 中都增加了新的功能。以 Intel VT 技術(shù)為例，它增加了兩種運行模式：VMX root 模式和?VMX nonroot 模式。通常來講，主機操作系統(tǒng)和 VMM 運行在 VMX root 模式中，客戶機操作系統(tǒng)及其應用運行在 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 受控制地在兩種模式之間切換，輪流執(zhí)行 VMM 代碼和 Guest OS 代碼。
? 對 KVM 虛機來說，運行在 VMX Root Mode 下的 VMM 在需要執(zhí)行 Guest OS 指令時執(zhí)行?VMLAUNCH 指令將 CPU 轉(zhuǎn)換到 VMX non-root mode，開始執(zhí)行客戶機代碼，即 VM entry 過程；在 Guest OS 需要退出該 mode 時，CPU 自動切換到 VMX Root mode，即 VM exit 過程。可見，KVM 客戶機代碼是受 VMM 控制直接運行在物理 CPU 上的。QEMU 只是通過 KVM 控制虛機的代碼被 CPU 執(zhí)行，但是它們本身并不執(zhí)行其代碼。也就是說，CPU 并沒有真正的被虛級化成虛擬的 CPU 給客戶機使用。
?這篇文章?是關(guān)于 vSphere 中 CPU 虛擬化的，我覺得它和 KVM CPU 虛擬化存在很大的一致。下圖是使用 2 socket 2 core 共 4 個 vCPU 的情形：
?? 幾個概念：socket （顆，CPU 的物理單位），core （核，每個 CPU 中的物理內(nèi)核），thread （超線程，通常來說，一個 CPU core 只提供一個 thread，這時客戶機就只看到一個 CPU；但是，超線程技術(shù)實現(xiàn)了 CPU 核的虛擬化，一個核被虛擬化出多個邏輯 CPU，可以同時運行多個線程）。?
? 上圖分三層，他們分別是是VM層，VMKernel層和物理層。對于物理服務器而言，所有的CPU資源都分配給單獨的操作系統(tǒng)和上面運行的應用。應用將請求先發(fā)送給操作系統(tǒng)，然后操作系統(tǒng)調(diào)度物理的CPU資源。在虛擬化平臺比如 KVM 中，在VM層和物理層之間加入了VMkernel層，從而允許所有的VM共享物理層的資源。VM上的應用將請求發(fā)送給VM上的操作系統(tǒng)，然后操縱系統(tǒng)調(diào)度Virtual CPU資源（操作系統(tǒng)認為Virtual CPU和物理 CPU是一樣的），然后VMkernel層對多個物理CPU Core進行資源調(diào)度，從而滿足Virtual CPU的需要。在虛擬化平臺中OS CPU Scheduler和Hyperviisor CPU Scheduler都在各自的領(lǐng)域內(nèi)進行資源調(diào)度。?
? ?KVM 中，可以指定 socket，core 和 thread 的數(shù)目，比如 設置 “-smp 5,sockets=5,cores=1,threads=1”，則 vCPU 的數(shù)目為 5*1*1 = 5。客戶機看到的是基于 KVM vCPU 的 CPU 核，而 vCPU 作為 QEMU 線程被 Linux 作為普通的線程/輕量級進程調(diào)度到物理的 CPU 核上。至于你是該使用多 socket 和 多core，這篇文章?有仔細的分析，其結(jié)論是在 VMware ESXi 上，性能沒什么區(qū)別，只是某些客戶機操作系統(tǒng)會限制物理 CPU 的數(shù)目，這種情況下，可以使用少 socket 多 core。
2.2.3 客戶機系統(tǒng)的代碼是如何運行的
?一個普通的 Linux 內(nèi)核有兩種執(zhí)行模式：內(nèi)核模式（Kenerl）和用戶模式 （User）。為了支持帶有虛擬化功能的 CPU，KVM 向 Linux 內(nèi)核增加了第三種模式即客戶機模式（Guest），該模式對應于 CPU 的 VMX non-root mode。
KVM 內(nèi)核模塊作為 User mode 和 Guest mode 之間的橋梁：
- User mode 中的 QEMU-KVM 會通過 ICOTL 命令來運行虛擬機
- KVM 內(nèi)核模塊收到該請求后，它先做一些準備工作，比如將 VCPU 上下文加載到 VMCS （virtual machine control structure）等，然后驅(qū)動 CPU 進入 VMX non-root 模式，開始執(zhí)行客戶機代碼
三種模式的分工為：
- Guest 模式：執(zhí)行客戶機系統(tǒng)非 I/O 代碼，并在需要的時候驅(qū)動 CPU 退出該模式
- Kernel 模式：負責將 CPU 切換到 Guest mode 執(zhí)行 Guest OS 代碼，并在 CPU 退出 ?Guest mode 時回到 Kenerl 模式
- User 模式：代表客戶機系統(tǒng)執(zhí)行 I/O 操作
(來源)
QEMU-KVM 相比原生 QEMU 的改動：
- 原生的 QEMU 通過指令翻譯實現(xiàn) CPU 的完全虛擬化，但是修改后的 QEMU-KVM 會調(diào)用 ICOTL 命令來調(diào)用 KVM 模塊。
- 原生的 QEMU 是單線程實現(xiàn)，QEMU-KVM 是多線程實現(xiàn)。
主機 Linux 將一個虛擬視作一個 QEMU 進程，該進程包括下面幾種線程：
- I/O 線程用于管理模擬設備
- vCPU 線程用于運行 Guest 代碼
- 其它線程，比如處理 event loop，offloaded tasks 等的線程
在我的測試環(huán)境中（RedHata Linux 作 Hypervisor）：
| smp 設置的值 | 線程數(shù) | 線程 |
| 4 | 8 | 1 個主線程（I/O 線程）、4 個 vCPU 線程、3 個其它線程 |
| 6 | 10 | 1 個主線程（I/O 線程）、6 個 vCPU 線程、3 個其它線程 |
這篇文章?談談了這些線程的情況。
(來源)
| 客戶機代碼執(zhí)行（客戶機線程） | I/O 線程 | 非 I/O 線程 |
| 虛擬CPU（主機 QEMU 線程） | QEMU I/O 線程 | QEMU vCPU 線程 |
| 物理 CPU | 物理 CPU 的 VMX non-root 模式中 | 物理 CPU 的 VMX non-root 模式中 ? |
2.2.4 從客戶機線程到物理 CPU 的兩次調(diào)度
要將客戶機內(nèi)的線程調(diào)度到某個物理 CPU，需要經(jīng)歷兩個過程：
? ? KVM 使用標準的 Linux 進程調(diào)度方法來調(diào)度 vCPU 進程。Linux 系統(tǒng)中，線程和進程的區(qū)別是 進程有獨立的內(nèi)核空間，線程是代碼的執(zhí)行單位，也就是調(diào)度的基本單位。Linux 中，線程是就是輕量級的進程，也就是共享了部分資源(地址空間、文件句柄、信號量等等)的進程，所以線程也按照進程的調(diào)度方式來進行調(diào)度。
（1）Linux 進程調(diào)度原理可以參考?這篇文章?和?這篇文章。通常情況下，在SMP系統(tǒng)中，Linux內(nèi)核的進程調(diào)度器根據(jù)自有的調(diào)度策略將系統(tǒng)中的一個可運行（runable）進程調(diào)度到某個CPU上執(zhí)行。下面是 Linux 進程的狀態(tài)機：
（2）處理器親和性：可以設置 vCPU 在指定的物理 CPU 上運行，具體可以參考這篇文章?和?這篇文章。
? ? 根據(jù) Linux 進程調(diào)度策略，可以看出，在 Linux 主機上運行的 KVM 客戶機 的總 vCPU 數(shù)目最好是不要超過物理 CPU 內(nèi)核數(shù)，否則，會出現(xiàn)線程間的 CPU 內(nèi)核資源競爭，導致有虛機因為 vCPU 進程等待而導致速度很慢。
關(guān)于這兩次調(diào)度，業(yè)界有很多的研究，比如上海交大的論文?Schedule Processes, not VCPUs?提出動態(tài)地減少 vCPU 的數(shù)目即減少第二次調(diào)度。
另外，這篇文章?談到的是 vSphere CPU 的調(diào)度方式，有空的時候可以研究下并和 KVM vCPU 的調(diào)度方式進行比較。
2.3 客戶機CPU結(jié)構(gòu)和模型
KVM 支持 SMP 和 NUMA 多CPU架構(gòu)的主機和客戶機。對 SMP 類型的客戶機，使用 “-smp”參數(shù)：
-smp <n>[,cores=<ncores>][,threads=<nthreads>][,sockets=<nsocks>][,maxcpus=<maxcpus>]對 NUMA 類型的客戶機，使用 “-numa”參數(shù)：
-numa <nodes>[,mem=<size>][,cpus=<cpu[-cpu>]][,nodeid=<node>]??
CPU 模型 （models）定義了哪些主機的 CPU 功能 （features）會被暴露給客戶機操作系統(tǒng)。為了在具有不同 CPU 功能的主機之間做安全的遷移，qemu-kvm 往往不會將主機CPU的所有功能都暴露給客戶機。其原理如下：
?
你可以運行?qemu-kvm -cpu ??命令來獲取主機所支持的 CPU 模型列表。
? ? 每個 Hypervisor 都有自己的策略，來定義默認上哪些CPU功能會被暴露給客戶機。至于哪些功能會被暴露給客戶機系統(tǒng)，取決于客戶機的配置。qemu32 和 qemu64 是基本的客戶機 CPU 模型，但是還有其他的模型可以使用。你可以使用 qemu-kvm 命令的 -cpu <model> 參數(shù)來指定客戶機的 CPU 模型，還可以附加指定的 CPU 特性。"-cpu" 會將該指定 CPU 模型的所有功能全部暴露給客戶機，即使某些特性在主機的物理CPU上不支持，這時候QEMU/KVM 會模擬這些特性，因此，這時候也許會出現(xiàn)一定的性能下降。?
RedHat Linux 6 上使用默認的 cpu64-rhe16 作為客戶機 CPU model：
?
你可以指定特定的 CPU model 和 feature：
qemu-kvm -cpu Nehalem,+aes?
你也可以直接使用 -cpu host，這樣的話會客戶機使用和主機相同的 CPU model。
2.4 客戶機 vCPU 數(shù)目的分配方法
這篇文章 （http://my.oschina.net/chape/blog/173981） 介紹了一些指導性方法，摘要如下：
我們來假設一個主機有 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，才開始資源調(diào)配來滿足2個vCPU的需要。在僅有2vCPU的情況下，對該VM的性能不會有太大負面影響。但如果分配4vCPU或者更多，這種資源調(diào)度上的負擔有可能會對該VM上運行的應用有很大負面影響。
確定 vCPU 數(shù)目的步驟。假如我們要創(chuàng)建一個VM，以下幾步可以幫助確定合適的vCPU數(shù)目
1 了解應用并設置初始值
? ? 該應用是否是關(guān)鍵應用，是否有Service Level Agreement。一定要對運行在虛擬機上的應用是否支持多線程深入了解。咨詢應用的提供商是否支持多線程和SMP（Symmetricmulti-processing）。參考該應用在物理服務器上運行時所需要的CPU個數(shù)。如果沒有參照信息，可設置1vCPU作為初始值，然后密切觀測資源使用情況。
2 觀測資源使用情況
? ? 確定一個時間段，觀測該虛擬機的資源使用情況。時間段取決于應用的特點和要求，可以是數(shù)天，甚至數(shù)周。不僅觀測該VM的CPU使用率，而且觀測在操作系統(tǒng)內(nèi)該應用對CPU的占用率。特別要區(qū)分CPU使用率平均值和CPU使用率峰值。
? ? ?假如分配有4個vCPU，如果在該VM上的應用的CPU
- 使用峰值等于25%， 也就是僅僅能最多使用25%的全部CPU資源，說明該應用是單線程的，僅能夠使用一個vCPU （4 * 25% = 1 ）
- 平均值小于38%，而峰值小于45%，考慮減少 vCPU 數(shù)目
- 平均值大于75%，而峰值大于90%，考慮增加 vCPU 數(shù)目
3 更改vCPU數(shù)目并觀測結(jié)果
每次的改動盡量少，如果可能需要4vCPU，先設置2vCPU在觀測性能是否可以接受。
總結(jié)
- 上一篇： Exynos4412裸机开发 —— RT
- 下一篇： unity算法面试_Unity面试准备