[Vmware ESX] Trekt de Vmkernel scheduler het wel?

[albatross]

Ik heb net een verse installatie gedaan van Windows 2008 Server Datacenter VM (4 vCPU's, Q9450), op een ESX 3.5 server, en onderworpen aan een stress-test, met OCCT. Helaas krijg ik na 30 minutes of zo al de volgende bluescreen:

"A clock interrupt was not received on a secondary processor"

Niet goed. Ik onderzocht the crash-dump (zie beneden), en daar staat: "Probably caused by : ntoskrnl.exe". Dat is minder goed zelfs. Want dat betekent dat het niet plaatsvindt in een of andere galle driver of een third-party programma.

Ik bootte de server, dit keer met Windows 2008 Server direct (geen VM). En ik kon OCCT probleemloos draaien gedurende en aantal uren. Het ligt dus niet aan de instabiliteit van mijn systeem of zo. Het lijkt er eerder op dat de scheduler van de Vmkernel het niet helemaal trekt.

Dit is nogal serieus, want een Vmware bug van deze aard kan ik natuurlijk niet zelf fiksen. Maar goed, alvorens ik conslusies trek, heeft er hier iemand ervaring met het stressen van alle 4 zijn CPU's, binnen een VM, voor lange tijd? (Met OCCT/Orthos en zo). Ik moet er niet aan denken dat je ESX wel kunt draaien, zo lang je je VMs maar niet al te hard laat werken.

Bedankt, in ieder geval.


---------

Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\Mini081508-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Windows Server 2008 Kernel Version 6001 (Service Pack 1) MP (4 procs) Free x64
Product: LanManNt, suite: TerminalServer DataCenter SingleUserTS
Kernel base = 0xfffff800`01661000 PsLoadedModuleList = 0xfffff800`01826db0
Debug session time: Fri Aug 15 10:15:15.208 2008 (GMT+2)
System Uptime: 0 days 3:18:58.927
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Loading Kernel Symbols
.......................................................................................................................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 101, {30, 0, fffffa6001963180, 2}

*** WARNING: Unable to verify timestamp for hal.dll
*** ERROR: Module load completed but symbols could not be loaded for hal.dll
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*********************************************************************
Probably caused by : ntoskrnl.exe

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000030, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: fffffa6001963180, The PRCB address of the hung processor.
Arg4: 0000000000000002, 0.

Debugging Details:
------------------

*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************

MODULE_NAME: nt

FAULTING_MODULE: fffff80001661000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 479192b7

BUGCHECK_STR: CLOCK_WATCHDOG_TIMEOUT

CUSTOMER_CRASH_COUNT: 1

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntoskrnl.exe

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------

[Mark]

Draai je ESX op een whitebox of op officieel gecertificeerde hardware ? Want ja ik heb ervaring met stressen van VM (SAP performance tests) en ben nooit tegen het probleem aangelopen dat VMWare het niet meer trok, meestal ging het OS of de applicatie zelf op zijn gat.

[ Voor 59% gewijzigd door Mark op 16-08-2008 11:23 ]

[Pim.]

Voorop gesteld dat ik hier geen ervaring mee heb.

Alles wat ik er op na lees wijst toch richting een hardware matig probleem en dan specifiek richting CPU of BIOS.
Ik zou nog een andere manier proberen om te stress testen (bijvoorbeeld met de D.net client ) en even je BIOS upgraden.

[albatross]

Pim. schreef op zaterdag 16 augustus 2008 @ 11:18:
Voorop gesteld dat ik hier geen ervaring mee heb.

Alles wat ik er op na lees wijst toch richting een hardware matig probleem en dan specifiek richting CPU of BIOS.
Ik zou nog een andere manier proberen om te stress testen (bijvoorbeeld met de D.net client ) en even je BIOS upgraden.

Zoals ik al aangaf, wanneer ik opstart met een gewone harddisk (niet de RAID), met Windows 2008 Server erop, kan ik gewoon uren OCCT draaien zonder enig probleem. Lijkt me toch geen hardware probleem, dan.

[[ash]]

Zelf heb ik veel ervaring met het werken met ESX servers welke zwaar belast worden. Denk bijvoorbeeld aan een continue belasting van ongeveer 90%. De problemen waardoor ESX onderuit gingen was altijd hardware gerelateerd. Defecte CPU of geheugen module.
Ik ben ook erg benieuwd of je op gecertificeerde hardware of op whitelabel hardware draait zoals Mark vraagt.

Hoe wil je eigenlijk ESX gebruiken? ESX is namelijk niet bedoeld om daar 1 VM op te draaien welke je tot 100% belast. ESX is bedoeld voor consolidatie. Dus meerdere VMs op 1 ESX server waarbij de totale belasting hoog op mag lopen.

Ook het aanbieden van meerdere virtuele CPU's aan een VM is niet zonder consequenties. Zo wil het niet altijd zeggen dat meerdere virtuele CPU's ook zal leiden tot meer performance. Het kan zelfs performance verslechteren. Helemaal als er ook andere VM's op de ESX server draaien. Dit heeft allemaal te maken met de wijze waarop ESX met de CPU scheduling omgaat.

albatross schreef op zaterdag 16 augustus 2008 @ 11:32:
[...]

Zoals ik al aangaf, wanneer ik opstart met een gewone harddisk (niet de RAID), met Windows 2008 Server erop, kan ik gewoon uren OCCT draaien zonder enig probleem. Lijkt me toch geen hardware probleem, dan.

Dat wil niet zeggen dat jouw hardware volledig ondersteund wordt door ESX.

[albatross]

Mark schreef op zaterdag 16 augustus 2008 @ 11:16:
Draai je ESX op een whitebox of op officieel gecertificeerde hardware ? Want ja ik heb ervaring met stressen van VM (SAP performance tests) en ben nooit tegen het probleem aangelopen dat VMWare het niet meer trok, meestal ging het OS of de applicatie zelf op zijn gat.

Ik draai het op een whitebox (P5Q-Pro bordje). Netwerk kaart en E200 RAID controller staan overigens wel op hun HCL.

En tja, het is moeilijk te bepalen over hier het guest OS zelf onderuit gaat, of vanwege de Vmkernel. Ik had liever gezien dat de BSOD veroorzaakt werd in een of andere driver, uiteraard.

Weet je toevallig ook of ik de VM kan debuggen? (in een log of zo). Dat zou me wellicht wat verder helpen (aangezien een mogelijke Vmware anomalie/conditie daar gerapporteerd zal worden).

[Dutch2007]

als 2008 niet onderuit gaat, kan je dan niet gewoon Hyper-V proberen?

met 2008 enterprise kreeg je d8 ik 3 standard licenties d'r "gratis" bij...

[[ash]]

Er is voldoende logging te vinden op de ESX server onder /var/log.
Maar omdat je deze vraag stelt heb ik het idee dat je weinig verstand hebt van ESX, laat staan de technieken welke ESX gebruikt. Misschien is het daarom verstandiger om Vmware workstation of server te gebruiken.
Je heb ook nog niet verteld hoe je ESX wil gaan gebruiken.

[Mark]

albatross schreef op zaterdag 16 augustus 2008 @ 11:38:
[...]

Ik draai het op een whitebox (P5Q-Pro bordje). Netwerk kaart en E200 RAID controller staan overigens wel op hun HCL.

Dan staan er nog veel zaken niet op de HCL en vermoed ik eerder dat het probleem toch in je systeem zit. De enigste keer dat ik problemen kreeg met crashende VM's was door rot geheugen en een hikkende fiber channel adapter. Overigens crasht dan eerder je hele ESX doos als 1 enkele VM.

En tja, het is moeilijk te bepalen over hier het guest OS zelf onderuit gaat, of vanwege de Vmkernel. Ik had liever gezien dat de BSOD veroorzaakt werd in een of andere driver, uiteraard.

Weet je toevallig ook of ik de VM kan debuggen? (in een log of zo). Dat zou me wellicht wat verder helpen (aangezien een mogelijke Vmware anomalie/conditie daar gerapporteerd zal worden).

Vanuit het oogpunt van ESX kun je weinig debuggen zo, voor ESX gaat de VM namelijk niet plat maar het OS binnen de VM. Aangezien ESX niks kan debuggen wat er binnen het OS op de VM draait kun je dat dus schudden.

Ik heb zelf ook wel eens stress tests gedraait op een 4 vCPU systeem welke gewoon dagen lang gelopen heeft. Het verschil was dat het wel gebeurde op gecertificeerde hardware (Dell R900 met 4 x Quad Core Xeon) en dat was met Windows 2003.

[albatross]

[ash] schreef op zaterdag 16 augustus 2008 @ 11:37:
Hoe wil je eigenlijk ESX gebruiken? ESX is namelijk niet bedoeld om daar 1 VM op te draaien welke je tot 100% belast. ESX is bedoeld voor consolidatie. Dus meerdere VMs op 1 ESX server waarbij de totale belasting hoog op mag lopen.

Er draaien 2 VM's op: een FreeBSD server (met 1 core) en een Windows 2008 Server, waarmee ik wil gaan renderen. Dat renderen (VC-1 -> AVC transcoding) neemt echt 100% CPU in beslag, op alle 4 de cores!).

Ook het aanbieden van meerdere virtuele CPU's aan een VM is niet zonder consequenties. Zo wil het niet altijd zeggen dat meerdere virtuele CPU's ook zal leiden tot meer performance. Het kan zelfs performance verslechteren. Helemaal als er ook andere VM's op de ESX server draaien. Dit heeft allemaal te maken met de wijze waarop ESX met de CPU scheduling omgaat.

Dat laatste bedoelde ik dus toen ik mijn vermoeden uitsprak dat de Vmkernel scheduler dit wellicht niet helemaal trekt. Lijkt er haast op alsof ik beter af ben 2 vCPU's toe te kennen, en die dan vast te pinnen met een fixed affinity (en hetzelfde te doen voor FreeBSD). Lijkt me dat de scheduler het dan makkelijker heeft. Kun je je in die gedachte vinden?

Dat wil niet zeggen dat jouw hardware volledig ondersteund wordt door ESX.

Klopt, maar mijn hardware is in ieder geval niet stuk, wilde ik maar zeggen.

[Verwijderd]

Beste, het is nu ook wel zo dat VMWare bekend staat om performance drops wanneer je meerdere vCPU's in 1 VM gebruikt. Om de kracht van je 4 cores te gebruiken hoef je echt geen 4 vCPU's te gebruiken. Meer nog, indien je slechts 1 CPU met 4 cores in je machine hebt steken zou ik zowiezo geen 4 vCPU's aan je VM geven, maximaal 3 en dan zeker zien dat je de "affinity" zo instelt dat de 3 cores aan jouw VM zijn toegewezen.

Ook zeker zien dat je de ESX 3.5 Update 2 (laatste build van 13/08) installeert aangezien dat de enige is die Windows 2008 Server "officieel" ondersteunt. alle voorgaande builds hadden enkel support in experimentele status.

Grtz,
Thanis

[albatross]

Verwijderd schreef op zaterdag 16 augustus 2008 @ 11:52:
Om de kracht van je 4 cores te gebruiken hoef je echt geen 4 vCPU's te gebruiken.

Als ik maar twee cores toewijs, dan kan ik toch ook maar gewoon de helft van de rekenkracht van de gehele quad-core gebruiken?

Meer nog, indien je slechts 1 CPU met 4 cores in je machine hebt steken zou ik zowiezo geen 4 vCPU's aan je VM geven, maximaal 3 en dan zeker zien dat je de "affinity" zo instelt dat de 3 cores aan jouw VM zijn toegewezen.

3 is volgens mij geen optie. Je krijgt de keuze tussen 1, 2, of 4.

Ook zeker zien dat je de ESX 3.5 Update 2 (laatste build van 13/08) installeert aangezien dat de enige is die Windows 2008 Server "officieel" ondersteunt. alle voorgaande builds hadden enkel support in experimentele status.

Ben er een beetje huiverig voor, na het recente licentie-fiasco. Maar goed, ik wist niet dat 2008 niet echt officieel ondersteund was daarvoor. Misschien dan toch maar aandurven.

[Verwijderd]

albatross schreef op zaterdag 16 augustus 2008 @ 12:01:
[...]

Als ik maar twee cores toewijs, dan kan ik toch ook maar gewoon de helft van de rekenkracht van de gehele quad-core gebruiken?

Hangt ervan af hoe je de affinity instelt natuurlijk. Als uw 2vcpu's niet vastgepinned worden aan 2 cores, dan kan je theorethisch gezien de volledige 4 cores gebruiken. Maar hou er rekening mee dat ESX nog altijd zelf ook wat CPU en RAM gebruikt, dus als je 4 van de 4 cores gaat toewijzen aan 1 VM en die 100% belast, kan ik me best voorstellen dat ESX dan wel een probleem gaat geven.

Wil jij toch 4 cores gebruiken, dan zul je eigenlijk 8 cores in je server moeten steken. ESX is niet bedoeld om 1 VM aan 100% te draaien gelijk aan 1 fysieke server. Bedoeling is om meerdere VM's te kunnen draaien die eventueel samen tot een goeie 90% belasting mogen/kunnen genereren.

Grtz,
Thanis

[albatross]

Verwijderd schreef op zaterdag 16 augustus 2008 @ 12:14:
[...]
Hangt ervan af hoe je de affinity instelt natuurlijk. Als uw 2vcpu's niet vastgepinned worden aan 2 cores, dan kan je theorethisch gezien de volledige 4 cores gebruiken.

Ik heb, een maand of zo geleden, die vraag eens gesteld op het officiele Vmware forum. Daar werd me verzekerd dat Vmware een vCPU niet dusdanig virtualiseert dat je alle kracht van zeg de gezamelijke 4 cores, in 1 vCPU kunt proppen. Iedere vCPU draait in principe op 1 core, maar de threads kunnen 'roamen' (verspringen van core), tenzij je dat dus met een forced affinity tegenhoudt.

Zeg je nu dus feitelijk dat ik toch gewoon 2 vCPU's toe kan wijzen, en dan effectief toch de kracht van (bijna) 4 krijg? Dat zou wel heel interessant wezen.

[Verwijderd]

albatross schreef op zaterdag 16 augustus 2008 @ 12:24:
[...]

Ik heb, een maand of zo geleden, die vraag eens gesteld op het officiele Vmware forum. Daar werd me verzekerd dat Vmware een vCPU niet dusdanig virtualiseert dat je alle kracht van zeg de gezamelijke 4 cores, in 1 vCPU kunt proppen. Iedere vCPU draait in principe op 1 core, maar de threads kunnen 'roamen' (verspringen van core), tenzij je dat dus met een forced affinity tegenhoudt.

Zeg je nu dus feitelijk dat ik toch gewoon 2 vCPU's toe kan wijzen, en dan effectief toch de kracht van (bijna) 4 krijg? Dat zou wel heel interessant wezen.

Mja, hetgene ze op het forum zeggen klopt wel. Echter, in de praktijk haal je met 1 vCPU quasi evenveel performance als de fysieke machine met alle cores. Uiteraard mag er dan niks anders draaien op de machine.

Grtz,
Thanis

[Verwijderd]

Mits je ook echt een multithreaded iets draait!

VMWare kan niet van 4 cores 1 core maken, dus als je maar 1 thread hebt draaien gaat die ene thread niet ineens 4x zo snel (zou heel mooi zijn als dat wel zo was )

[albatross]

Verwijderd schreef op zaterdag 16 augustus 2008 @ 17:11:
Mits je ook echt een multithreaded iets draait!

VMWare kan niet van 4 cores 1 core maken, dus als je maar 1 thread hebt draaien gaat die ene thread niet ineens 4x zo snel (zou heel mooi zijn als dat wel zo was )

Maar het verhaal is toch interessant genoeg. Als een app dan multi-threaded is, zou die dan toch over alle cores verdeeld worden, ook al heb je maar 1 vCPU toegewezen? Je zou dus feitelijk NIET affinity moeten toewijzen aan die ene vCPU: dan krijg je met een multi-threaded app toch nog wat gezamelijke CPU kracht mee.

[DukeBox]

Volgens mij klopt dat niet helemaal.. als ik een systeem draai met 4 vCPU's op een dual quadcore systeem kan ik maar maximaal 4 cores belasten. Ik draai bijvoorbeeld 8 threads welke 100% cpu gebruiken, dan zie ik ze maar verdeeld staan over 4 cores en dus 50% per thread.

edit: offtopic (letterlijk) http://www.vmug.nl/module...ums&file=viewtopic&t=2974

[ Voor 15% gewijzigd door DukeBox op 17-08-2008 22:46 ]