'Purple screen of death' in ESXi 6.0 u2

[albatross]

Hmm, heb nu al twee keer, kort achter elkaar, de volgende 'purple screen of death' gehad in EXSi 6.0:

2016-07-22T17:10:23.890Z cpu6:33031)@BlueScreen: PCPU 1 locked up. Failed to ack TLB invalidate (total of 2 locked up, PCPU(s): 0,1).
2016-07-22T17:10:23.890Z cpu6:33031)Code start: 0x418008000000 VMK uptime: 44:09:34:31.713
2016-07-22T17:10:23.890Z cpu6:33031)0x4390c839bbd0:[0x418008077afa]PanicvPanicInt@vmkernel#nover+0x37e stack: 0x4390c839bc68
2016-07-22T17:10:23.890Z cpu6:33031)0x4390c839bc60:[0x418008077dc5]Panic_NoSave@vmkernel#nover+0x4d stack: 0x4390c839bcc0
2016-07-22T17:10:23.890Z cpu6:33031)0x4390c839bcc0:[0x41800808be15]TLBGetLockedCPUBacktraces@vmkernel#nover+0x25d stack: 0x9
2016-07-22T17:10:23.890Z cpu6:33031)0x4390c839be80:[0x41800808c106]TLBDoInvalidate@vmkernel#nover+0x21a stack: 0x4390c99a7000
2016-07-22T17:10:23.891Z cpu6:33031)0x4390c839bed0:[0x4180085d0f30]UserMem_CartelFlush@<None>#<None>+0xc0 stack: 0x0
2016-07-22T17:10:23.891Z cpu6:33031)0x4390c839bf50:[0x418008640e26]UserMemTouchedEstimationLoop@<None>#<None>+0x1d2 stack: 0x2d88092c2a
2016-07-22T17:10:23.891Z cpu6:33031)0x4390c839bfd0:[0x418008214a3e]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0

Vandaag was het PCPU 11. Zo kort achter elkaar, dat kan geen toeval meer wezen. Is er geen cpu test of iets dergelijks te doen in ESXi? Baal hier stevig van. Mijn server heeft maanden zo goed gedraaid (en hij staat ook lekker gekoeld, nu het zo warm is)

[albatross]

P.S. Overigens wel bizar: ook na de purple screen bleef Xpenology gewoon draaien! Dwz, ik kon de file manager openen, die weliswaar zei dat er geen shared disk waren, maar toch: wanneer ESXi in een purple screen zit, en net gecore-dumped heeft, hoe kan de virtuele NAS dan nog ooit draaien?!

[CH4OS]

Ik weet het niet 100% zeker, maar Windows herstart bij een BSOD (mits het aan staat) ook pas als de kernel dump klaar is. Wellicht geldt dat voor ESXi ook en herstart hij dus pas als die dump klaar is. In de tussentijd blijft 'de boel' wat nog wel reageert en werkt gewoon draaien.

[albatross]

CH40S schreef op maandag 25 juli 2016 @ 18:48:
Ik weet het niet 100% zeker, maar Windows herstart bij een BSOD (mits het aan staat) ook pas als de kernel dump klaar is. Wellicht geldt dat voor ESXi ook en herstart hij dus pas als die dump klaar is. In de tussentijd blijft 'de boel' wat nog wel reageert en werkt gewoon draaien.

Ja, dat klinkt logisch. Maar goed, dat was meer anekdotisch. Nu nog mijn 'purple screen' zelf.

[albatross]

Die foutmelding, "PCPU 1 locked up. Failed to ack TLB invalidate," daar staat op de Vmware site een prima verklaring voor, maar nog steeds niet eenduidig wat het nou veroorzaakt (kan een driver lockup wezen, of toch een hardware error). En ESXi lijkt 0 test-tools aan boord te hebben.

[CH4OS]

Uitgaande van https://kb.vmware.com/sel...playKC&externalId=1020214 lijkt het erop dat het wellicht aan de CPU ligt? Iets wat http://www.itechlounge.ne...ed-to-ack-tlb-invalidate/ lijkt te bevestigen, maar is wat specifieker.

[ Voor 30% gewijzigd door CH4OS op 25-07-2016 21:02 ]

[albatross]

CH40S schreef op maandag 25 juli 2016 @ 21:02:
Uitgaande van https://kb.vmware.com/sel...playKC&externalId=1020214 lijkt het erop dat het wellicht aan de CPU ligt? Iets wat http://www.itechlounge.ne...ed-to-ack-tlb-invalidate/ lijkt te bevestigen, maar is wat specifieker.

Het probleem is dat beide artikelen een software (driver) fout niet uitsluiten.

En CPU echt stuk? Niet onmogelijk, maar lijkt me erg onwaarschijnlijk. Maar goed, vandaar dat ik dus naar wat test-progjes aan het zoeken was voor binnen ESXi.

[Hero of Time]

Hier ook, ESXi is Server Software. Hoort oorspronkelijk dus niet in NOS.

[HyperBart]

albatross schreef op dinsdag 26 juli 2016 @ 01:45:
[...]


Het probleem is dat beide artikelen een software (driver) fout niet uitsluiten.

En CPU echt stuk? Niet onmogelijk, maar lijkt me erg onwaarschijnlijk. Maar goed, vandaar dat ik dus naar wat test-progjes aan het zoeken was voor binnen ESXi.

Test programma's ga je niet vinden in ESXi, ik stel wel voor dat je met memtest eens aan de slag gaat, die spreekt de CPU ook wel een stuk aan.

Doorgaans gaat een CPU niet zo snel stuk hoor, dus het zou me verbazen. Aangezien CPU en MEM een sterke relatie hebben met elkaar zou ik geheugen verdenken.

Heb je voor je PSOD's kwamen een paar keer gereboot? Misschien is er iets corrupt. ESXi draait normaal in memory, maar bij een reboot moet ie wat ophalen van SD of disk natuurlijk.

Wat ik indertijd wel een fijn tooltje vond is StressLinux. Ik had een clustertje van 3 ESXi hosts met G1610 Celeron's en ik heb SL toen gebruikt om te kijken of het allemaal koel genoeg bleef met passieve koeling.

[ Voor 40% gewijzigd door HyperBart op 26-07-2016 12:10 ]

[albatross]

HyperBart schreef op dinsdag 26 juli 2016 @ 12:06:
[...]


Test programma's ga je niet vinden in ESXi, ik stel wel voor dat je met memtest eens aan de slag gaat, die spreekt de CPU ook wel een stuk aan.

Doorgaans gaat een CPU niet zo snel stuk hoor, dus het zou me verbazen. Aangezien CPU en MEM een sterke relatie hebben met elkaar zou ik geheugen verdenken.

Ja, zo dacht ik dus ook. Ik ben al zo'n 24 uur memtest86 aan het draaien. Tot dusver geen errors.

Heb je voor je PSOD's kwamen een paar keer gereboot? Misschien is er iets corrupt. ESXi draait normaal in memory, maar bij een reboot moet ie wat ophalen van SD of disk natuurlijk.

Ik het voor de eerste keer niet gereboot. Hij had voor de eerste PSOD zo'n 44 dagen aangestaan. Daarna gereboot, uiteraard, en toen kwam 2 dagen later weer diezelfde PSOD.

Wat ik indertijd wel een fijn tooltje vond is StressLinux. Ik had een clustertje van 3 ESXi hosts met G1610 Celeron's en ik heb SL toen gebruikt om te kijken of het allemaal koel genoeg bleef met passieve koeling.

Dat tooltje zal ik ook eens bekijken. Bedankt!

[albatross]

Heb nu stresslinux draaien, met:

stress --cpu 2000 --timeout 1d

Hoop dat ik het zo goed gedaan heb.

[HyperBart]

albatross schreef op dinsdag 26 juli 2016 @ 19:28:
Heb nu stresslinux draaien, met:

stress --cpu 2000 --timeout 1d

Hoop dat ik het zo goed gedaan heb.

Paar workers minder had ook gemogen natuurlijk . Kijk eens of je ook het geheugen kan aanspreken met VM en VM-BYTES eventueel.

[albatross]

HyperBart schreef op woensdag 27 juli 2016 @ 11:41:
[...]


Paar workers minder had ook gemogen natuurlijk . Kijk eens of je ook het geheugen kan aanspreken met VM en VM-BYTES eventueel.

Ik las op een site ergens dat het voorbeeld van 10 workers veel te weinig is, en ze suggereerden zo'n 2000. Aangezien mijn Windows machine gebruikt wordt voor renderen, staat die normaliter dus op 100% CPU belasting. Dus die 2000 leek me wel redelijk.

Nog geen fout gedetecteerd, overigens. Kan me ook niet echt voorstellen dat het de CPU is, maar moet wel getest worden.

Ik heb die Windows machine 4000 shares gegeven, overigens (= 'high'). Een vriend van mij zei dat daardoor de lockup kon ontstaan. Lijkt me toch sterk; ten eerste omdat het geven van shares gewoon 100% supported is, en ten tweede omdat mijn machine het hiervoor ook gewoon maanden goed gedaan heeft.

[Question Mark]

Is je hardware wel compleet supported door VMWare?

[albatross]

Question Mark schreef op woensdag 27 juli 2016 @ 13:10:
Is je hardware wel compleet supported door VMWare?

Vast niet. Gewoon mijn oude P6X58D Premium moederbord, met i7 980X, met passthru voor de onboard ICH10R en Marvell SATA2 controllers). Maar het heeft in ieder geval maanden probleemloos gedraaid, tot ik opeens 2 PSOD's kreeg, zeer kort na elkaar.

[albatross]

HyperBart schreef op dinsdag 26 juli 2016 @ 12:06:
[...]

Wat ik indertijd wel een fijn tooltje vond is StressLinux. Ik had een clustertje van 3 ESXi hosts met G1610 Celeron's en ik heb SL toen gebruikt om te kijken of het allemaal koel genoeg bleef met passieve koeling.

Test is net afgelopen. Zoals verwacht, geen CPU errors. Ben ik mooi klaar mee dan, LOL. Zo weet ik nog niks. Die crash dump van ESXi is ook een zooitje ongeregeld: duizenden vage entries, zonder een eenduidige aanwijzing welk subsysteeem de fout nou veroorzaakte. En support bij Vmware is zo goed als afwezig. Zucht.

[Question Mark]

De support bij VMWare is prima, alleen niet gratis...

Bovendien heeft VMWare redelijk strenge eisen aan ondersteunde hardware. Als jij hardware gebruikt waarvan bekend is dat VMWare deze niet ondersteund kun je verwachten dat hier geen ondersteuning op is.

[albatross]

Question Mark schreef op donderdag 28 juli 2016 @ 09:15:
De support bij VMWare is prima, alleen niet gratis...

Bovendien heeft VMWare redelijk strenge eisen aan ondersteunde hardware. Als jij hardware gebruikt waarvan bekend is dat VMWare deze niet ondersteund kun je verwachten dat hier geen ondersteuning op is.

Ik doelde uiteraard op de community support. Ook die is zeer mager. Bovendien is alle hardware die ik gebruik gewoon ondersteund (de X58 chipset + de SATA controllers, iig).

[HyperBart]

Mja, ik snap wel waar Question Mark op doelt, neemt niet weg dat dit ook nog een hobby forum is en dat de vraag prima gesteld mag worden, niet QM (nofi)? Er zijn zat combinaties die niet op de HCL staan en waar ESXi prima op draait en ESXi knalt er normaal ook niet zomaar uit. Als de combo ook tijden goed heeft gedraaid en nu plots begint te bokken vind ik de vraag ook wel terecht.

Ik doe maar een balletje opgooien, maar heb je toevallig een zelfde socket CPU liggen of kan je zoiets goedkoop scoren op V&A ofzo? Ik zou het dan zo eens mbv uitsluiting proberen te testen. Heel jammer en ook wel wat raar dat SL geen fouten genereerde

[Question Mark]

HyperBart schreef op donderdag 28 juli 2016 @ 09:37:
Mja, ik snap wel waar Question Mark op doelt, neemt niet weg dat dit ook nog een hobby forum is en dat de vraag prima gesteld mag worden, niet QM (nofi)?

Absoluut mag dit topic... Graag zelfs!

Ik reageerde alleen even op het fout dat er gemeld werd dat VMWare geen support levert. Dat klopt niet. De support bij VMware is meer dan uitstekend, alleen niet in dit geval. En dat is begrijpelijk.

In een supported omgeving had TS gewoon de logfiles kunnen verzamelen en die op kunnen sturen naar VMWare. Dan had VMWare de oorzaak wel achterhaald.

albatross schreef op donderdag 28 juli 2016 @ 09:21:
[...]
Bovendien is alle hardware die ik gebruik gewoon ondersteund (de X58 chipset + de SATA controllers, iig).

Da's in elk geval goed nieuws. Controleer wel even goed of je de aanbevolen driverversie en firmwareversie(s) gebruikt. Daar roept VMWare vaak ook nog wel wat over.

[ Voor 22% gewijzigd door Question Mark op 28-07-2016 10:19 ]

[HyperBart]

Oh zeker, maar ik had even schrik dat het in de richting ging gaan van "tja, je draait enterprise grade hardware op stuff die niet HCL'ed is, dan krijg je dit soort dingen". Helemaal eens met je post verder.

@TS: Heb je eigenlijk al acties of bezigheden kunnen correleren met de crashes? Misschien doe je iets uitzonderlijker of iets wat een VM aanroept wat anders niet gebeurt of bv. met SL niet gebeurt maar ESXi wel doet.

[FireDrunk]

Dingen die je zou kunnen proberen:

Zet alle powersaving opties uit in het BIOS. (C-States en P-States willen nog wel eens apart lockup gedrag vertonen omdat ESXi vind dat de CPU er te lang over doet om uit slaapstand te komen).

Verwijder zo veel mogelijk hardware (extra kaarten, extra USB devices)

Controleer je temperaturen (ook die je niet ziet in je BIOS, dus kijk of controllers/chipsets niet extreem warm worden)

Doe eens een clean install van de laatste versie van ESXi op een USB stick, en importeer je VM, en laat dat een poosje draaien.

[albatross]

HyperBart schreef op donderdag 28 juli 2016 @ 09:37:

Ik doe maar een balletje opgooien, maar heb je toevallig een zelfde socket CPU liggen of kan je zoiets goedkoop scoren op V&A ofzo? Ik zou het dan zo eens mbv uitsluiting proberen te testen. Heel jammer en ook wel wat raar dat SL geen fouten genereerde

Ik denk dat ik nu zowel geheugen als CPU uit kan sluiten. Wat ik ook over deze TLB PSOD vind, het lijkt heel veel oorzaken te kunnen hebben. Niets eenduidig, iig. IRQ errors, geheugen, I/O, en als laatste ook de CPU (maar dat schijnt erg zelden te wezen; wat ik al vermoedde).

HyperBart schreef op donderdag 28 juli 2016 @ 10:20:

@TS: Heb je eigenlijk al acties of bezigheden kunnen correleren met de crashes? Misschien doe je iets uitzonderlijker of iets wat een VM aanroept wat anders niet gebeurt of bv. met SL niet gebeurt maar ESXi wel doet.

Het enige wat ik voornamelijk doe op die machine is renderen (VapourSynth + x264). Dat veroorzaakt een 100% CPU belasting (net als wanneer ik buiten ESXi draai). Maar daar zou ie gewoon tegen moeten kunnen. Er is ook een iSCSI drive gedefinieerd op XPenology, waar de Windows 10 VM naar verwijst.

Het systeem heeft zo maanden goed gedraaid, en nu ineens niet meer. Nu ik zowel geheugen als CPU zo goed als uit kan sluiten, denk ik voorzichtig toch aan iets I/O-achtigs. De Marvell SATA wellicht? Die controllers zitten onboard, dus daar zal ik dan een nieuwe controller voor moeten kopen.

Ik ga iig eerst een proberen het zaakje te draaien zonder 100% CPU belasting. Kijken of het ueberhaupt blijft draaien zo. Ik zou dadelijk ook eens de DSM log van Synology kunnen bekijken (als die er is); wellicht dat die een I/O error waarneemt ergens.

Bedankt iig allemaal voor het meedenken!

[albatross]

Question Mark schreef op donderdag 28 juli 2016 @ 10:14:
[...]

Ik reageerde alleen even op het fout dat er gemeld werd dat VMWare geen support levert. Dat klopt niet. De support bij VMware is meer dan uitstekend, alleen niet in dit geval. En dat is begrijpelijk.

In een supported omgeving had TS gewoon de logfiles kunnen verzamelen en die op kunnen sturen naar VMWare. Dan had VMWare de oorzaak wel achterhaald.

Uiteraard. Had alleen stiekum gehoopt dat de Vmware community er ook iets over wist. Maar die weten het waarschijnlijk ook gewoon niet zelf (en sturen dit soort issues dan gewoon een Vmware toe).

[albatross]

FireDrunk schreef op donderdag 28 juli 2016 @ 10:26:
Dingen die je zou kunnen proberen:

Zet alle powersaving opties uit in het BIOS. (C-States en P-States willen nog wel eens apart lockup gedrag vertonen omdat ESXi vind dat de CPU er te lang over doet om uit slaapstand te komen).

Verwijder zo veel mogelijk hardware (extra kaarten, extra USB devices)

Ik heb het systeem weer gestart. Ik heb er twee kaarten uitgehaald die niets (meer) deden: een Ethernet kaart en een 2-poorts SATA3 kaartje waar geen disk aan zat. Denk niet dat het echt uit gaat maken, maar wie weet. Heb ook Speedstep en zo even uitgezet, en onboard Firewire controller.

P.S. Kan iemand hier ook nog iets zinnigs over zeggen?

"Ik heb die Windows machine 4000 shares gegeven, overigens (= 'high'). Een vriend van mij zei dat daardoor de lockup kon ontstaan. Lijkt me toch sterk; ten eerste omdat het geven van shares gewoon 100% supported is, en ten tweede omdat mijn machine het hiervoor ook gewoon maanden goed gedaan heeft."

'High' shares zou toch gewoon moeten kunnen?!

[Question Mark]

Tuurlijk kan dat... Shares betekent de relatieve prioriteit die een systeem krijgt tov een ander systeem op dezelfde host.

[albatross]

Question Mark schreef op donderdag 28 juli 2016 @ 19:51:
Tuurlijk kan dat... Shares betekent de relatieve prioriteit die een systeem krijgt tov een ander systeem op dezelfde host.

Bedankt. Ja, daar ging ik ook van uit. Denk dat mijn vriend het verwarde met, zeg, de process priority in Windows (of Unix). Daar kun je normaliter idd beter vanaf blijven. Maar zoals ik ESXi shares begreep, is dat gewoon een pool met een max, die je na believen kunt verdelen.

Maar goed, dat ook uitgesloten.

[albatross]

Als ik nog eens even de beide crash dumps bekijk, dam zie ik identieke (adressen?):

2016-07-22T17:10:23.890Z cpu6:33031)pcpu:11 world:1604637 name:"vmm5:Windows_10_x64" (V)
2016-07-22T17:10:23.890Z cpu6:33031)@BlueScreen: PCPU 1 locked up. Failed to ack TLB invalidate (total of 2 locked up, PCPU(s): 0,1).
2016-07-22T17:10:23.890Z cpu6:33031)Code start: 0x418008000000 VMK uptime: 44:09:34:31.713
2016-07-22T17:10:23.890Z cpu6:33031)0x4390c839bbd0:[0x418008077afa]PanicvPanicInt@vmkernel#nover+0x37e stack: 0x4390c839bc68
2016-07-22T17:10:23.890Z cpu6:33031)0x4390c839bc60:[0x418008077dc5]Panic_NoSave@vmkernel#nover+0x4d stack: 0x4390c839bcc0
2016-07-22T17:10:23.890Z cpu6:33031)0x4390c839bcc0:[0x41800808be15]TLBGetLockedCPUBacktraces@vmkernel#nover+0x25d stack: 0x9
2016-07-22T17:10:23.890Z cpu6:33031)0x4390c839be80:[0x41800808c106]TLBDoInvalidate@vmkernel#nover+0x21a stack: 0x4390c99a7000
2016-07-22T17:10:23.891Z cpu6:33031)0x4390c839bed0:[0x4180085d0f30]UserMem_CartelFlush@<None>#<None>+0xc0 stack: 0x0
2016-07-22T17:10:23.891Z cpu6:33031)0x4390c839bf50:[0x418008640e26]UserMemTouchedEstimationLoop@<None>#<None>+0x1d2 stack: 0x2d88092c2a
2016-07-22T17:10:23.891Z cpu6:33031)0x4390c839bfd0:[0x418008214a3e]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0

En:

2016-07-25T17:55:44.536Z cpu8:33031)@BlueScreen: PCPU 11 locked up. Failed to ack TLB invalidate (total of 2 locked up, PCPU(s): 10,11).
2016-07-25T17:55:44.536Z cpu8:33031)Code start: 0x418012800000 VMK uptime: 2:23:17:11.353
2016-07-25T17:55:44.537Z cpu8:33031)0x4390c839bbd0:[0x418012877afa]PanicvPanicInt@vmkernel#nover+0x37e stack: 0x4390c839bc68
2016-07-25T17:55:44.537Z cpu8:33031)0x4390c839bc60:[0x418012877dc5]Panic_NoSave@vmkernel#nover+0x4d stack: 0x4390c839bcc0
2016-07-25T17:55:44.537Z cpu8:33031)0x4390c839bcc0:[0x41801288be15]TLBGetLockedCPUBacktraces@vmkernel#nover+0x25d stack: 0x9
2016-07-25T17:55:44.537Z cpu8:33031)0x4390c839be80:[0x41801288c106]TLBDoInvalidate@vmkernel#nover+0x21a stack: 0x4390c99a7000
2016-07-25T17:55:44.537Z cpu8:33031)0x4390c839bed0:[0x418012dd0f30]UserMem_CartelFlush@<None>#<None>+0xc0 stack: 0x0
2016-07-25T17:55:44.537Z cpu8:33031)0x4390c839bf50:[0x418012e40e26]UserMemTouchedEstimationLoop@<None>#<None>+0x1d2 stack: 0x30bc4a367a
2016-07-25T17:55:44.537Z cpu8:33031)0x4390c839bfd0:[0x418012a14a3e]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0

Zou dat nog ergens op kunnen duiden? Die getallen zijn wel wat hoog om geheugen adressen te wezen.

[albatross]

Ik verdenk ook de iSCI setup een beetje (mijn Windows VM wijst naar een iSCI disk gedefinieerd op de XPenology VM). Zie veel fouten als:

[7m2016-07-22T17:05:08.569Z cpu3:33028)WARNING: LinScsi: SCSILinuxAbortCommand:2024: The driver failed to call done from itsabort handler and yet it returned SUCCESS[0m
[7m2016-07-22T17:05:08.569Z cpu3:33028)WARNING: LinScsi: SCSILinuxAbortCommands:1891: Failed, Driver ahci, for vmhba40[0m
[7m2016-07-22T17:05:08.569Z cpu3:33028)WARNING: ScsiPath: 7154: Set retry timeout for failed TaskMgmt abort for CmdSN 0x0, status Failure, path vmhba40:C0:T0:L0[0m
2016-07-22T17:05:08.569Z cpu9:33256)<3>ata10: exception Emask 0x1 SAct 0x0 SErr 0x0 action 0x0 t4
2016-07-22T17:05:08.569Z cpu9:33256)<3>ata10: irq_stat 0x40000001
2016-07-22T17:05:08.569Z cpu9:33256)<6>ata10: EH complete
2016-07-22T17:05:08.569Z cpu1:33148)ScsiPath: 4429: Command 0x12 (cmdSN 0x0, World 0) to path vmhba40:C0:T0:L0 timed out: expiry time occurs 114ms in the past
[7m2016-07-22T17:05:08.569Z cpu1:33148)WARNING: ScsiPath: 4718: Failed to issue command 0x12 (cmdSN 0x0) on path vmhba40:C0:T0:L0: Timeout[0m
2016-07-22T17:05:09.601Z cpu1:33140)ScsiScan: 1173: Path 'vmhba40:C0:T0:L0': Vendor: 'Marvell ' Model: '91xx Config ' Rev: '1.01'
2016-07-22T17:05:09.601Z cpu1:33140)ScsiScan: 1176: Path 'vmhba40:C0:T0:L0': Type: 0x3, ANSI rev: 5, TPGS: 0 (none)

Ook lees ik (google) dat iSCSI icm ESXi niet altijd vlekkeloos verloopt.

[EdwinB]

iSCSI op ESXi is natuurlijk niets mis mee. De halve wereld draait op iSCSI met ESXi (en wij ook @work)

Waar wel van alles mis mee is is iSCSI op Synology. Je zou eens kunnen testen met een NFS datastore die je ook via XPenology kan aanbieden aan je host en daar je VM(s) op draaien die nu op je iSCSI datastore staan. Wel even de iSCSI meuk weghalen daarna

[albatross]

EdwinB schreef op vrijdag 29 juli 2016 @ 20:40:
iSCSI op ESXi is natuurlijk niets mis mee. De halve wereld draait op iSCSI met ESXi (en wij ook @work)

Waar wel van alles mis mee is is iSCSI op Synology. Je zou eens kunnen testen met een NFS datastore die je ook via XPenology kan aanbieden aan je host en daar je VM(s) op draaien die nu op je iSCSI datastore staan. Wel even de iSCSI meuk weghalen daarna

Ga ik zeker proberen. Bedankt! Vond ook dit: https://gathering.tweaker...message/45028521#45028521

Die iSCSI moet er maar eens tussenuit.

EDIT: Wat bedoel je precies met 'Wel even de iSCSI meuk weghalen daarna :)'? De iSCSI weghalen op Synology, bedoel je?

[ Voor 8% gewijzigd door albatross op 29-07-2016 20:53 ]

[johnkeates]

Er is trouwens op de X58 een errata van toepassing op IO virtuaisation. VT-d is eigenlijk niet supported op die chipset. Xen schakelt VT-d in elk geval by default uit, en Linux+KVM doet hetzelfde. Ik heb geen idee of VMware hetzelfde doet. Zo niet; dan kan het dus zijn dat je tegen een X58 issue aan loopt. (het X58 probleem heet met Interrupt Remapping te maken wat allerlei problemen met zich meebrengt, o.a. storage I/O en netwerk I/O)

Dit was in 2009 ergens bij VMWare ook al gepost, een X58 bord met een i7-9xx. In oudere ESX versies kon je de installatie dan niet eens voltooien.

[albatross]

johnkeates schreef op vrijdag 29 juli 2016 @ 20:59:
Er is trouwens op de X58 een errata van toepassing op IO virtuaisation. VT-d is eigenlijk niet supported op die chipset. Xen schakelt VT-d in elk geval by default uit, en Linux+KVM doet hetzelfde. Ik heb geen idee of VMware hetzelfde doet. Zo niet; dan kan het dus zijn dat je tegen een X58 issue aan loopt. (het X58 probleem heet met Interrupt Remapping te maken wat allerlei problemen met zich meebrengt, o.a. storage I/O en netwerk I/O)

Dit was in 2009 ergens bij VMWare ook al gepost, een X58 bord met een i7-9xx. In oudere ESX versies kon je de installatie dan niet eens voltooien.

Hmmm, dat is nieuw voor mij. Was juist blij dat mijn X58 chipset VT-d ondersteunt. Dat gaat lastig worden met mijn XPenology dan, qua pass-thru controllers (die nu pass-thru staan, via VT-d dus). Dan zal ik de schijven maar individueel aan de XPenology VM moeten geven (als dat gaat). Ik ondervind inderdaad veel I/O en/of netwerk problemen (zwaar inzakkende, 'onverklaarbare' doorvoer en zo).

Bedankt iig voor de info.

[johnkeates]

albatross schreef op vrijdag 29 juli 2016 @ 21:12:
[...]


Hmmm, dat is nieuw voor mij. Was juist blij dat mijn X58 chipset VT-d ondersteunt. Dat gaat lastig worden met mijn XPenology dan, qua pass-thru controllers (die nu pass-thru staan, via VT-d dus). Dan zal ik de schijven maar individueel aan de XPenology VM moeten geven (als dat gaat). Ik ondervind inderdaad veel I/O en/of netwerk problemen (zwaar inzakkende, 'onverklaarbare' doorvoer en zo).

Bedankt iig voor de info.

Met Xen zou het wel moeten kunnen, daar kan je devices per stuk doorgeven, dat werkt zelfs met ZFS nog goed. Er wordt dan gebruik gemaakt van blkback/blkfont, wat de IO 1:1 mapt, maar dan zonder VT-d (VT is dan wel nog steeds nodig).

[albatross]

EdwinB schreef op vrijdag 29 juli 2016 @ 20:40:
iSCSI op ESXi is natuurlijk niets mis mee. De halve wereld draait op iSCSI met ESXi (en wij ook @work)

Waar wel van alles mis mee is is iSCSI op Synology. Je zou eens kunnen testen met een NFS datastore die je ook via XPenology kan aanbieden aan je host en daar je VM(s) op draaien die nu op je iSCSI datastore staan. Wel even de iSCSI meuk weghalen daarna

Ik heb de hele iSCSI zooi er maar afgegooid. Dat was op XPenology nog wat lastiger dan ik dacht, want je krijgt niet zo maar je gereserveerde data space terug.

Ik heb nu een NFS share gedefinieerd. Die is sowieso een stuk sneller, moet ik zeggen, en een veel mindere CPU 'hog' dan SMB (geen last van op mijn desktop machine, uiteraard, maar op mijn Synology VM kon het tot 50% CPU oplopen).

Nu maar hopen dat het blijft draaien.

[albatross]

Heb een paar dagen geleden weer dezelfde PSOD gehad. Het lag dus niet aan de iSCSI (hoe brak die ook moge wezen op Synology).

Heeft iemand wellicht ervaring met de DeLock 70137 op ESXi 6? Deze dus:

http://www.informatique.n...NiDzv7c2M4CFROeGwodWjAHSA

We kwamen gisteren tot de conclusie dat het niet aan de ICHR10 kon liggen (aangezien die pass-thru staat, en dus ESXi niet direct beinvloedt).