Ik zit op dit moment met een rare situatie. Ik heb een VM draaien op ESX 3.5U4 welke een in mijn ogen rare performance grafiek laat zien in Virtual Center.

De VM draait Windows 2003, is terminal server en handelt wat aanvullende taken af als bv distributie van anti-virus definitie bestanden. De VM heeft een enkele vCPU en 2048 MB aan geheugen toegekend. Voor de rest zijn er geen speciale instellingen voor de VM gedaan zoals reservations etc.

Wanneer ik de CPU usage grafiek in Virtual Center bekijk heeft de VM continu 100% CPU load (met bijbehorende 3 GHz aan CPU gebruik overeenkomend met een enkele core van de multi core ESX host).

Kijk ik binnen de VM zelf dan is de CPU belasting maar ongeveer 25% gemiddeld en zijn er zelden uitschieters naar de 100%. Binnen de VM reageer alles prima hetgeen niet zo is (dwz merkbaar traag) wanneer ik een CPU burn doe op een test VM met 1 vCPU. Ik zou bij 100% CPU ook binnen de VM trage performance verwachten.

Ik kan het 100% CPU gebruik niet zoals in Virtual Center is aangegeven niet verklaren. Andere VMs die ik op deze host draai tonen dit gedrag niet. Ook een vMotion naar een andere ESX host lost niets op.

De ESX hosts zijn van alle beschikbare patches voor ES3.5u4 voorzien en de VM draait de nieuwste versie VMware tools.

Toevoeging: de betreffende VM is een geïmporteerde fysieke machine.

Ik lees her en der ook zaken over dit soort problemen door HAL mismatches. De HAL die Windows nu gebruikt is een ACPI multiprocessor. Via device manager -> update driver kan ik deze niet aanpassen naar een ACPI uniprocessor driver gezien ik deze HAL niet kan selecteren. Sommige posts op internet geven aan dat terug gaan van ACPI multiprocessor naar uniprocessor op deze manier inderdaad niet zou kunnen en dat voor Windows 2003 de multiprocessor HAL goed zou zijn, ook al is er maar 1 vCPU. Kan iemand hier iets meer over vertellen? Kunnen deze problemen inderdaad door een HAL mismatch worden veroorzaakt? Ik heb meerdere geimporteerde VMs draaien met 1 vCPU en een ACPI multiprocessor HAL welke dit soort problemen niet geven.

In de VMware knowledge base lees ik overigens ook nog deze opmerking:
"If a virtual machine is created as SMP and later changed to become UP, you can address the high CPU utilization by installing VMware Tools. " bij dit artikel http://kb.vmware.com/selfservice/micros ... nalId=1077

VMware tools is echter al up2date.

Wie helpt?

Vaak zie je alleen fouten met HAL voorbij komen als je gebruik maakt van een downgrade van 2 naar 1 cpu, een upgrade van 1 naar 2 gaat vaak met 1 a 2 herstarts automatisch en hoef je niets aan te doen.

Gaat het erom dat je de performance counters niet begrijpt of dat je performance problemen hebt op je terminal server?

Probeer beetje de standaard waardes aan te houden, denk aan 4096 mb geheugen, 2 vCPU's enkele devices uit te schakelen die je niet gebruikt, custom VMware Tools installatie met de ballooning driver etc..

wellicht heb je hier iets aan

http://blog.vmpros.nl/2009/05/05/vmware ... mware-esx/

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Het gaat er om dat de VM een enkele core helemaal vol trekt zonder dat er echt iets in de VM gebeurt, dwz de CPU usage in de VM geeft ongeveer 25% aan en lager. Kortom, ondanks dat binnen de VM amper activiteit is trekt de VM 100% CPU op ESX terwijl de VM zelf wel altijd lekker reageert.

De fysieke host had 2 cpu's maar dit is voor de VM teruggeschroeft naar een enkele CPU.

Dat is ook de reden waarom ik een probleem met de HAL vermoed. Mede omdat de perofrmance binnen de VM gewoon top is (deze terminal server word amper gebruikt).

Ik lees jammer genoeg echter nergens een goede manier om van de acpi multiprocessor HAL naar een uniprocessor HAL te komen zonder reinstall.