正文：
什麼是vCPU？
vCPU，顧名思義，是虛擬CPU。 vCPU是虛擬機的部件，創建虛擬機時，需要配置vCPU資源。因此脫離VM，談論vCPU是沒有意義的。
vCPU是如何調用的？
虛擬化管理系統按照時間片輪轉方式進行資源調度，當系統內的VM所需要的vCPU核大於物理CPU核數時，虛擬化管理系統首先按照時間片輪流調度一遍，然後如果還有剩餘的CPU資源，則給所需要的vCPU。例如系統配置了40個vCPU，只有20個物理核。那麼平均每個vCPU獲取一個物理核50%的資源。由於有些VM忙，有些VM空閒，虛擬化系統會在一個調度周期內，劃分出若干時間片，輪流給每個vCPU使用。忙的vCPU可以佔用整個時間片，而閒的vCPU佔用部分時間片，會提前釋放資源。這樣在一個調度周期內，對每個vCPU都調度一遍後還有空閒的時間，調度器會用這剩餘的資源去調度忙的vCPU。 這樣做的目的是兼顧公平和效率。這中調度算法舉個例子：系統有1個CPU 2.0 Ghz，兩個VM，分配1個vCPU。如果VM1 和 VM2都忙，那麼各自相當於擁有一個1.0 Ghz的CPU。如果VM1很忙，VM1隻需要 500Mhz的處理能力，那麼在VM1看來，相當於暫時獲得了 1.5Ghz的處理器。
舉個更形象的例子：有一座廟（一個物理機），廟裡有一些和尚（VM），每頓飯只做20碗飯（20個物理核），有的和尚吃兩碗飯 (2vCPU)，有的和尚吃四碗飯(4vCPU)。如果這些和尚吃的總飯量，不超過20碗，按需分配，多出的飯，剩下。如果和尚的總需求超出了廟裡的總飯量，怎麼辦？那就把一碗飯分成若干份，均分到和尚的碗裡（vCPU）。更進一步的需求是：和尚又有不同的等級（CPU權重），均分資源方式就改進成了按照等級分廟裡的幾碗飯，主持可以分多一點，小和尚少一點。另外，有的和尚有特殊需求，只能從廟裡的某幾個碗中分飯吃（CPU 綁定CPU pin）。
上述的一些分配方法都有一個缺點，就是和尚究竟能吃多少飯，是不確定的。取決於廟裡有多少和尚、廟裡有多少碗飯，以及碗的大小。 所以VMware改進了一下，乾脆就定義了一個和尚吃幾碗，每碗飯量多少克。 這樣和尚無論到那個廟（與虛擬化環境無關），都保證能吃飽。 不過廟的管理就麻煩一些了，米飯不夠時，可能就不能招收新的和尚了（CPU資源不足，就無法創建VM了）
vCPU是不是越多越好？
虛擬機需要多少個vCPU呢？是不是個數越多性能越好呢？
這方面存在著很多誤區。給VM配置CPU資源的時候，要精打細算才能最大可能的利用已有資源，來滿足商業應用的需要。虛擬機性能取決於配置的合理性—確保虛擬機獲得足夠多的時鐘周期、內存空間以及IO帶寬。當配置錯誤或者計算需求增加導致虛擬機出現資源緊張狀況時，虛擬機性能及穩定性可能會受影響
有的情況下為某個VM設置過多vCPU數目，反而會造成該應能的性能下降。也造成整個系統的資源浪費。
如何合理分配vCPU資源？
了解了vCPU在虛擬化平臺裡的運行原理後，我們知道vCPU的分配並不是越多越好，分少了，VM性能不夠；分多了，也可能造成vm性能下降，那麼如何正確的分配vCPU呢？
手工的辦法是：
根據應用的情況先大致分一定數量的vCPU，然後根據實際情況調節vCPU個數。比如說我們先給VM分4vCPU，如果CPU使用率一直比較高，可成倍增加到8vCPU或16vCPU，這個主要是看應用強度。
如果ESXi只跑一個VM，原則是vCPU的個數不要多於物理CPU總個數。虛擬化vCPU還有一個原則就是夠用就好，只要CPU資源夠就可以了，不要對資源進行過度分配。
除了手工的方法外，另外一個推薦就是使用VMware的vRealize Operations Manage，它會給出建議。
後續會再寫一篇關於vRealize Operations Manage的介紹。