This post is also available in: Inglese

Reading Time: 3 minutes

In una macchina fisica il termine CPU è utilizzato normalmente per identificare il package fisico (oppure socket) che contiene la CPU. Le unità di processo contenute all’interno di questo package sono generalmente identificate con il termine “core” (da notare che in realtà ogni singolo core poi può contenere più unità di tipo ALU e può essere visto, tramite la funzione di hyper-threading, come più unità logiche). I sistemi con più di una CPU di solito sono chiamati sistemi SMP (in realtà esistono diversi modelli possibili), mentre i sistemi con una CPU a più core vengono generalmente indicati come sistemi multi-core. Sistemi con più CPU, ciascuna con più core, sono sistemi più complessi (e in genere il modello utilizzato al momento per questo tipo di sistemi è l’architettura NUMA).

Invece in una macchina virtuale il termine vCPU è utilizzato genericamente per identificare un core di elaborazione assegnato a una VM. Più vCPU definiscono tipicamente un’architettura vSMP molto semplice, equivalente ad un sistema fisico con più CPU ciascuna a singolo core.

Il numero di vCPU allocabili ad ogni VM dipendere fondamentarlmente dal tipo di hypervisor e dal tipo di licenza (per VMware vedere: http://www.vmware.com/products/vsphere/buy/editions_comparison.html). In VMware vSphere, per tutte le edizioni eccetto la Enterprise+ il limite era (in vSphere 4.x) di 4 vCPU, e era è (in vSphere 5) di 8 vCPU. Per la edizione Enterprise+ era di 8 ed ora è di 32.

Ma il numero di vCPU può avere un serio impatto anche sul tipo di licensing a livello di guest OS. Ad esempio Windows XP o 7 sono limitati ad un massimo di 2 CPUs “fisiche” che diventano, nel caso precendente, un massimo di 2 vCPU… Ogni CPU però può avere più core e questo è permesso dal licensing.

Per simulare questa situazione anche in virtuale è possibile ragguppare le varie vCPU in virtual core in modo da “imbrogliare” il sistema operativo guest. Questo è possibile attraverso un’opzione avanzata nel file vmx della VM. Da notare che con vSphere 5 questa impostazione è disponibile anche da vSphere Client.

Sempre riguardo vSphere 5, è stato introdotto (nel virtual hardware v8) anche il concetto di Virtual NUMA (vNUMA) che permette di esporre alla VM la topologia NUMA dell’host fisico, in questo modo i sistemi operativi guest in grado di gestire NUMA e le applicazioni potranno utilizzare nel modo più efficiente l’architettura esistente. Per maggiori informazioni consultare il technical white paper What’s New in Performance in VMware vSphere™ 5.0

Share

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.