[Centos] VM resource verdeling

[EXX]

Ik ben op dit moment bezig met het virtualizeren van een systeem, opgebouwd uit meerdere servers.

Als host platform gebruik ik een HP Z600 server met 2 Xeon quadcore CPUs (in totaal 16 CPU threads) en 8 GB geheugen. Op dit systeem draait Centos 6.4, met de bijbehorende VM software.

Op deze host zijn een 6 virtuele machines aangemaakt; elk van deze loopt onder RHEL 5.5, met daarop weer een java of C++ applicatie. De 6 virtuele computers communiceren met elkaar via virtuele LANs.

Nu heb ik de CPU en geheugen resources mooi opgedeeld onder de virtuele machines. 4 VMs hebben maximaal 2 CPU threads, en 2 VMs mogen op 4 CPU threads lopen. Ook de 8 GB is mooi verdeeld over de 6 VMs.

Nu heb ik een probleem met de 2 VMs die 4 CPU threads gebruiken. De CPU usage loopt vaak vast tegen de 100%. Het top command in de VM geeft een CPU usage van bijna 400%, dus 100% usage voor alle 4 de cores/treads. Kijk ik echter in de Performance Diagnostic van de VM, dan zie ik dat er slechts 1 toegekende processor thread wordt gebruikt en dat de CPU load 25% bedraagt.

Hoe kan dit / waar komt dit verschil vandaan?

[CAPSLOCK2000]

Volgens mij, en ik ben geen expert, is hyperthreading niet geschikt voor virtualisatie. Met 2 x 4 cores heb je dus 8 vcpu's, geen 16. Ik vermoed dat niet alle software dat snapt.

Misschien gebruik je wel 1 CPU-core om vier vCPU's te simuleren. De VM ziet dan wel 4 CPU's maar zodra de eerste bezet is kunnen de anderen niks doen. Virtualisatie verbergt dat en de VM ziet dus alleen maar dat al z'n cpu's de hele tijd bezig zijn, vandaar 400% CPU.

Je monitor software ziet dat je 4 cores hebt toegekend maar ziet ook dat er in praktijk maar 1 gebruikt wordt. Dat komt dus neer op 25% belasting.

Het kan ook nog zo zijn dat je VM in praktijk twee echte cores krijgt om vier CPU's te simuleren en dat Performance Diagnostics naar het totaal aan cores kijkt. 2 / 8 = 25%.

Bovenstaande verhaal komt helemaal uit mijn dikke duim, iedere overeenkomst met de werkelijkheid berust op toeval.