Lo scheduler di ESX, tra le altre funzioni che svolge, partiziona in modo logico i vari core presenti su un server fisico in “celle”. Questo valore è di 4 per ESX 3.5 e di 8 per ESX 4. Le celle non sono fisse, ma dinamiche, ovvero di volta in volta la composione dei core di una cella potrebbe variare.
L’esecuzione di una virtual machine, sia essa mono o multi processore, non può oltrepassare i limiti di una cella: da qui è possibile capire chiaramente perchè ESX 3.5 aveva un limite di 4 vCPU e ESX 4.0 ce l’ha di 8.
Con 3.5 capita una cosa abbastanza curiosa, che alla luce di questo dettaglio tecnico ha una sua spiegazione. Magari non è cosa normalissima, ma potrebbe capitare che un nuovo server dotato di processori a sei core venga installato con ESX 3.5 a bordo invece del nuovo ESX 4.0. Cosa succede in questo caso alla composizione delle celle? Immaginando di avere due processori 6 core, avremo 12 core, ovvero 3 celle. Però due di queste celle saranno contenute all’interno del medesimo processore, mentre una cella accorperà due core per ognuno dei due processori.
Questo si traduce in una variabilità nella velocità di esecuzione a seconda che in un dato momento una cella è compresa all’interno di un solo socket o è “spalmata” su due socket diversi. Brutto vero? Ovviamente il motivo di fondo è che ai tempi dell’uscita di ESX 3.5 non vi erano processori 6 core. Se pensate che questo comportamento possa impattare sulle performance di una VM, o quantomeno fargli assumere una performance variabile nel tempo, sappiate che è possibile modificare il valore di cell size:
– via client, andando in Configuration, Advanced Settings, VMkernel, cercate il parametro VMkernel.Boot.cpuCellSize e impostatelo a 6
– via command line, digitando esxcfg-advcfg –set-kernel 6 cpuCellSize (su un sistema ESX)
– via remote command line, digitando vicfg-advcfg –set-kernel 6 cpuCellSize (su un sistema ESXi)
In tutti i casi dovrete poi riavviare il server.
Ultima nota: queste cose servono per sistemi ad elevate prestazioni e con alti carichi di lavoro. Se avete problemi di performance con sistemi medi, cercate prima errori più marchiani, non avventuratevi in queste “finezze”.