Het grote ESXi/vSphere Topic

[citruspers]

Als je er niet via de webinterface, console of SSH bij kan houd het inderdaad op

Ik heb zelf wel eens gehad dat de webinterface bleef hangen op het login gedeelte, dat werd keurig opgelost door de management agents/daemons te herstarten via de console, dus vandaar.

[ Voor 4% gewijzigd door citruspers op 04-12-2020 19:06 ]

[tMb]

En het werkt weer na een reboot

Ik heb nog als actiepuntje staan om een klein toetsenbord en schermpje aan te schaffen voor in de meterkast of een dummy HDMI plug zodat ik er via Intel vPro AMT KVM bij kan. Dat laatste werkt helaas niet als je de machine opstart zonder monitor erin.

[ Voor 0% gewijzigd door tMb op 04-12-2020 19:25 . Reden: typo ]

[|sWORDs|]

tMb schreef op vrijdag 4 december 2020 @ 19:25:
En het werkt weer na een reboot

Ik heb nog als actiepuntje staan om een klein toetsenbord en schermpje aan te schaffen voor in de meterkast of een dummy HDMI plug zodat ik er via Intel vPro AMT KVM bij kan. Dat laatste werkt helaas niet als je de machine opstart zonder monitor erin.

Vreemd, de keren dat ik AMT gebruikt heb werkte dat zonder monitor.

[tMb]

Beetje off topic: ik gebruik meshcommander om de host op afstand te benaderen via AMT. Het is een Dell Optiplex desktop die ik als server gebruik, mogelijk heeft het daar mee te maken.

Ik vond onderstaande uitleg op een Intel forum:

The issues with Mesh Commander going to a Black Screen during reboot is related to Headless systems.

If the AMT device is headless, the GPU will power down if no requests are occuring from the OS. In this case when the device is power cycled or booted to the BIOS, the BIOS detects no attached monitor and powers down the GPU.

The solution is to get a HDMI emulator and plug it into the server. This will allow for normal AMT KVM usage

[|sWORDs|]

tMb schreef op vrijdag 4 december 2020 @ 19:53:
Beetje off topic: ik gebruik meshcommander om te host op afstand te benaderen via AMT. Het is een Dell Optiplex desktop die ik als server gebruik, mogelijk heeft het daar mee te maken.

Ik vond onderstaande uitleg op een Intel forum:

[...]

Bij mij was het een Asrock bord.

[TomGear]

Zwelgje schreef op dinsdag 18 augustus 2020 @ 13:52:
[...]


esxcli system settings kernel set -s vga -v FALSE

dat lost het op. ik had ook met mijn AMD gpu. schijnt dat de kernel/console die kaart exclusief claimed en dat het daarom fout gaat.

nadeel van deze methode is dat je nu geen fysieke console/monitor meer kan gebruiken op die machine. maar ach je doet toch dingen via ssh

Oke dit werkt maar na een reboot zit ik vast in het scherm
shutting down firmware services relocating modules

ik had dan esxi opnieuw gemaakt en dit was gefixt, vandaag dacht ik ik zet het nog eens aan en ja hoor, terug hetzelfde ?

maar nu wil ik het graag oplossen ipv esxi te herinstalleren

enig idee ?

[Red devil]

Beste ESXi-toppers

Op mijn 1e Gen8 machientje heb ESXI draaien waar ik verschillende VMs draai, werkt perfect.
Op mijn 2e Gen8 machientje wilde ik Truenas/DSM gaan testen met schijven in passthrough via een HP P410 RAID controller. Uiteindelijk wil ik dan mijn backup schijven (3TB, 14TB en 2TB) overzetten naar mijn Gen8 machine.

Echter, zoals jullie kunnen lezen in het HP topic krijg ik de 3 discen niet te zien. Ik heb de HP P410 raid controller actief op passthrough staan en toegevoegd. Heb bij opstarten 3x1TB disc via RAID controller geconfigureerd, simpele instelling, gewoon 3x simpele volume. Bij truenas zie ik de HP P410 raid controller bij de devices, alleen de 3 schijven zie ik niet. Moet ik hiervoor nog iets doen bij ESXi? Ik ging er vanuit dat alles wat je aan die RAID controller zou hangen automatisch zichtbaar zou moeten zijn voor de ESXi VM die de RAID controller doorgestuurd krijgt.

[Cookiezzz]

Red devil schreef op zaterdag 19 december 2020 @ 15:58:
Beste ESXi-toppers

Op mijn 1e Gen8 machientje heb ESXI draaien waar ik verschillende VMs draai, werkt perfect.
Op mijn 2e Gen8 machientje wilde ik Truenas/DSM gaan testen met schijven in passthrough via een HP P410 RAID controller. Uiteindelijk wil ik dan mijn backup schijven (3TB, 14TB en 2TB) overzetten naar mijn Gen8 machine.

Echter, zoals jullie kunnen lezen in het HP topic krijg ik de 3 discen niet te zien. Ik heb de HP P410 raid controller actief op passthrough staan en toegevoegd. Heb bij opstarten 3x1TB disc via RAID controller geconfigureerd, simpele instelling, gewoon 3x simpele volume. Bij truenas zie ik de HP P410 raid controller bij de devices, alleen de 3 schijven zie ik niet. Moet ik hiervoor nog iets doen bij ESXi? Ik ging er vanuit dat alles wat je aan die RAID controller zou hangen automatisch zichtbaar zou moeten zijn voor de ESXi VM die de RAID controller doorgestuurd krijgt.

Dit gaat volgens mij al eerder aan die P410 liggen en niet aan ESXi.
Die P410 is een RAID controller en voor ZFS/TrueNAS gebruik je best een HBA.
Je mag dan een simpel volume per disk maken, het is nog altijd geen direct access voor je TrueNAS VM.

Ik heb in mijne TrueNAS VM een Dell Perc H310 zitten die naar IT mode is geflasht.
Werkt hier al jaren zonder problemen. (Wel is die volgens mij nu niet meer supported in ESXi 7.0 maar ik zit nog op 6.7).

Nog een voorbeeld.

[ Voor 6% gewijzigd door Cookiezzz op 19-12-2020 18:49 ]

[Red devil]

Cookiezzz schreef op zaterdag 19 december 2020 @ 18:45:
[...]


Dit gaat volgens mij al eerder aan die P410 liggen en niet aan ESXi.
Die P410 is een RAID controller en voor ZFS/TrueNAS gebruik je best een HBA.
Je mag dan een simpel volume per disk maken, het is nog altijd geen direct access voor je TrueNAS VM.

Ik heb in mijne TrueNAS VM een Dell Perc H310 zitten die naar IT mode is geflasht.
Werkt hier al jaren zonder problemen. (Wel is die volgens mij nu niet meer supported in ESXi 7.0 maar ik zit nog op 6.7).

Nog een voorbeeld.

Dank, misschien moet ik dan maar proberen om hele discen te RDM-en? Vond deze guide en iemand in HP thread gaf deze tip ook al.

Daar nog nadelen aan verbonden?

Ik zou dan altijd nog in ESXi datastores kunnen maken op dit HP P410 raid controller, is het gewoon een extra setje SATA connectors. Oh wacht, dan worden dan SSDs, kan zo'n oude controller wel overweg met TRIM en SSDs? Mmmm volgende probleem

[jwvdst]

ik heb een server met esxi 7.0 u1 in de meterkast staan. Aan de andere kant van de muur bij de meterkast heb ik mn tv staan met een htpc computer waar windows 10 op draait. Nu had ik het idee om mijn oude bare metal htpc te vervangen door een vm op de esxi server maar hoe kan ik het beste de beeld en geluid op de tv krijgen? Eerste idee was om een simpele grafische kaart die ik nog heb om die in de server te zetten en dan middels passthrough aan de vm te geven maar na wat lezen en zoeken op het internet is mij wel duidelijk dat dat niet gaat werken.
Mijn 2e ingeving was om een usb to hdmi adapter te gebruiken al dan niet met een usb3.x kaart in pass through. Hier kan ik weinig over vinden of dit gaat werken. misschien iemand met kennis van zaken die hier uitsluitsel over kan geven?
Als er nog andere (werkende)opties zijn hoor ik dat ook graag

[|sWORDs|]

jwvdst schreef op zondag 27 december 2020 @ 20:46:
ik heb een server met esxi 7.0 u1 in de meterkast staan. Aan de andere kant van de muur bij de meterkast heb ik mn tv staan met een htpc computer waar windows 10 op draait. Nu had ik het idee om mijn oude bare metal htpc te vervangen door een vm op de esxi server maar hoe kan ik het beste de beeld en geluid op de tv krijgen? Eerste idee was om een simpele grafische kaart die ik nog heb om die in de server te zetten en dan middels passthrough aan de vm te geven maar na wat lezen en zoeken op het internet is mij wel duidelijk dat dat niet gaat werken.
Mijn 2e ingeving was om een usb to hdmi adapter te gebruiken al dan niet met een usb3.x kaart in pass through. Hier kan ik weinig over vinden of dit gaat werken. misschien iemand met kennis van zaken die hier uitsluitsel over kan geven?
Als er nog andere (werkende)opties zijn hoor ik dat ook graag

Ik zou voor een NVIDIA Shield gaan en anders toch voor de 1e ingeving.

[jwvdst]

|sWORDs| schreef op zondag 27 december 2020 @ 23:43:
[...]

Ik zou voor een NVIDIA Shield gaan en anders toch voor de 1e ingeving.

bedoel jij voor de grafische kaart of de usb to hdmi adapter?

[FireDrunk]

@jwvdst serie: Shield
Een losse HTPC, stukken makkelijker..

[|sWORDs|]

jwvdst schreef op maandag 28 december 2020 @ 01:06:
[...]

bedoel jij voor de grafische kaart of de usb to hdmi adapter?

USB naar HDMI is een extreem slecht idee op heel veel vlakken, plus dat het mogelijk niet werkt.
Ik kan ze alleen niet specifiek benoemen zonder interne werking vrij te geven waarvan ik niet denk dat het public knowledge is. Beetje high over: iets met hypervisor en guest level. Plus software decoding en framerate sync.
Videokaart is te doen, maar een Shield zou mijn keuze zijn (ook ipv HTPC).

[ Voor 48% gewijzigd door |sWORDs| op 28-12-2020 12:48 ]

[Dennisweb]

Zeg nooit nooit, @jwvdst. Ik heb een Nvidia Quadro K2200 gekocht een paar jaar geleden. Die draait op ESXi 6.5 prima. ESXi 7.0 heb ik niet omdat mijn pa er een antieke Delta 1010 geluidskaart via passthrough in heeft zitten.

Maar de Nvidia Quadro K2200 staat in zijn geheel op PCI Passthrough. Op betreffende VM (Windows 10, 20H2) heb ik de Display Adapter van VMWare uitgeschakeld nadat ik AnyDesk had geïnstalleerd met een beeldscherm op de Quadro. In matter of fact ben ik nu met OBS een stream aan het encoden. 2.1 GHz CPU verbruik.

Ik heb weinig verstand van HTPC, maar een GPU passthrough is op ESXi lang niet altijd hopeloos.

[Red devil]

Dennisweb schreef op maandag 4 januari 2021 @ 00:29:
Ik heb weinig verstand van HTPC, maar een GPU passthrough is op ESXi lang niet altijd hopeloos.

HTPC op een VM valt bij mij onder het kopje zelf-kastijding. Oftewel, je moet het leuk vinden om te doen. Wil je geen gedoe, koop gewoon zo;n Shield stick

[Dennisweb]

Red devil schreef op maandag 4 januari 2021 @ 12:19:
[...]


HTPC op een VM valt bij mij onder het kopje zelf-kastijding. Oftewel, je moet het leuk vinden om te doen. Wil je geen gedoe, koop gewoon zo;n Shield stick

Het is de makkelijkste weg, maar dat zegt niet dat GPU passthrough onmogelijk is. Zeker met wat uithoudingsvermogen zijn er mooie dingen mee te doen.

[Red devil]

Dennisweb schreef op maandag 4 januari 2021 @ 20:15:
[...]

Het is de makkelijkste weg, maar dat zegt niet dat GPU passthrough onmogelijk is. Zeker met wat uithoudingsvermogen zijn er mooie dingen mee te doen.

Klopt! Draai zelf native SATA controllers op een HP machine op pass-through zodat DSM software de harde schijven goed kan zien. Dus het concept vind ik echt fantastisch. Maar het is wel veel gedonder voor een HTPC lijkt me, of je moet het zien als een uitdaging. Ik ga iig met films kijken niet meer klooien, hop een Raspberry met Kodi/OpenELEC erop of een Shield.

[ThinkPad]

Ik heb een Lenovo i5 desktop waar ik ESXi op draai (7.0.1 update 1). Dit werkt prima, als datastore heb ik er een SSD in zitten (Samsung 850 via SATA).

Ik was benieuwd naar de gezondheid van de SSD. Met esxcli heb ik wel wat op kunnen vragen, maar ik begrijp dat die tellers gereset worden als het systeem herstart wordt. Ook zit daar bijv. de 'Terabytes written' niet tussen.

In oudere blogs lees ik smartctl die SMART gegevens kan uitlezen, maar die is niet aanwezig in ESXi 7. Ik zie zo 123 ook geen instructies voor hoe je deze op ESXi 7 kunt installeren.

Iemand tips?

Gewoon maar geprobeerd, deze tutorial werkt met ESXi 7 ook nog steeds prima (smartctl-6.6-4321.x86_64.vib).

[ Voor 35% gewijzigd door ThinkPad op 13-01-2021 11:17 ]

[trebor.ed]

ThinkPadd schreef op woensdag 13 januari 2021 @ 10:42:
Ik heb een Lenovo i5 desktop waar ik ESXi op draai (7.0.1 update 1). Dit werkt prima, als datastore heb ik er een SSD in zitten (Samsung 850 via SATA).

Ik was benieuwd naar de gezondheid van de SSD. Met esxcli heb ik wel wat op kunnen vragen, maar ik begrijp dat die tellers gereset worden als het systeem herstart wordt. Ook zit daar bijv. de 'Terabytes written' niet tussen.

In oudere blogs lees ik smartctl die SMART gegevens kan uitlezen, maar die is niet aanwezig in ESXi 7. Ik zie zo 123 ook geen instructies voor hoe je deze op ESXi 7 kunt installeren.

Iemand tips?

Gewoon maar geprobeerd, deze tutorial werkt met ESXi 7 ook nog steeds prima (smartctl-6.6-4321.x86_64.vib).

Nieuwsgierig geworden heb ik ook even gekeken naar een nieuwere versie van smartctl voor esxi. Je kunt na installatie van de vib de smartctl executable vervangen door de linux versie en dan heb je meteen de laatste versie draaien (v7.3).

Vervelend genoeg krijg ik met mijn disken niet ID 241 te zien, dat maakt het bepalen van de TBW erg lastig. Wordt vervolgt.

[BlackShadow]

Draai al een hele tijd ESXi 7.0.0 (Build 16324942) op een NUC7i5BNK zonder problemen.
Onlangs geheugen uitgebreid naar 32GB om wat meer VMs te gaan draaien.

Nu merk ik dat met een stuk meer VMs en een vrij hoog memory gebruik (75%) na een tijdje de CPU naar 100% gaat, daar blijft en enkele minuten laten wordt ESXi onbeheerbaar, geen SSH of webgui meer.

Betreft voornamelijk gemigreerde ESXi 6.7 VMs alsook vCenter.
Ik verdacht eerst vCenter van hoge CPU, deze heb ik beperkt in CPU gebruik, maar nog steeds reageert de gehele ESXi omgeving niet meer.

Mijn stappenplan zou als volgt zijn:
- ESXi uit vCenter halen en vCenter VM voorlopig weg
- VM per VM overzetten met 24u wachttijd om eventueel te achterhalen welke VM de oorzaak is, als dit al het geval kan zijn?

Iemand een idee hoe ik dit best kan gaan debuggen?
Als de hoge CPU begint moet ik namelijk heel snel zijn of hij hangt volledig.

[|sWORDs|]

BlackShadow schreef op dinsdag 9 februari 2021 @ 09:05:
Draai al een hele tijd ESXi 7.0.0 (Build 16324942) op een NUC7i5BNK zonder problemen.
Onlangs geheugen uitgebreid naar 32GB om wat meer VMs te gaan draaien.

Nu merk ik dat met een stuk meer VMs en een vrij hoog memory gebruik (75%) na een tijdje de CPU naar 100% gaat, daar blijft en enkele minuten laten wordt ESXi onbeheerbaar, geen SSH of webgui meer.

Betreft voornamelijk gemigreerde ESXi 6.7 VMs alsook vCenter.
Ik verdacht eerst vCenter van hoge CPU, deze heb ik beperkt in CPU gebruik, maar nog steeds reageert de gehele ESXi omgeving niet meer.

Mijn stappenplan zou als volgt zijn:
- ESXi uit vCenter halen en vCenter VM voorlopig weg
- VM per VM overzetten met 24u wachttijd om eventueel te achterhalen welke VM de oorzaak is, als dit al het geval kan zijn?

Iemand een idee hoe ik dit best kan gaan debuggen?
Als de hoge CPU begint moet ik namelijk heel snel zijn of hij hangt volledig.

Maak eerst eens eens een lijstje van je VMs en hun configuratie, zoals:
DC 2 cores 4GB
vCenter 4 cores 8GB
etc.

Dan kunnen we schatten waar het mogelijk misgaat. Wat voor disk gebruik je, welke mitigations staan aan, waarom draai je niet de laatste ESXi, heb je vmware tools appinfo uitgezet op je Windows VMs (of nog beter OSOT+de optimizing guide gebruikt)?

[Aschtra]

Mannen ik kom er niet uit.
Ik wil graag upgraden van 6.7 naar 7.0. Ik heb de ISO gedownload van 7.0.1-17491101.
Hier voer ik de installer.exe uit van VCSA-ui-installer win32.

Ik doorloop het proces. Installeren van de nieuwe Vcenter 7.0 gaat prima. Echter de upgrade / migratie mislukt telkens op hetzelfde punt:


Ja.. Source VCenter staat uit, dat heb je zelf gedaan in de upgrade.





Ik kan alleen nergens terugvinden waarom het maken van die groep dan zou mislukken. Als ik zelf via SSH inlog kan ik gewoon die groep maken zonder errors. Google geeft bar weinig info over deze specifieke fout.

Iemand een idee? Waar zou ik kunnen kijken voor meer info?

Mijn source VCenter draait op 6.7.0.46000

[ Voor 5% gewijzigd door Aschtra op 09-02-2021 18:11 ]

[BlackShadow]

|sWORDs| schreef op dinsdag 9 februari 2021 @ 11:30:
[...]

Maak eerst eens eens een lijstje van je VMs en hun configuratie, zoals:
DC 2 cores 4GB
vCenter 4 cores 8GB
etc.

Dan kunnen we schatten waar het mogelijk misgaat. Wat voor disk gebruik je, welke mitigations staan aan, waarom draai je niet de laatste ESXi, heb je vmware tools appinfo uitgezet op je Windows VMs (of nog beter OSOT+de optimizing guide gebruikt)?

Bedankt voor de tips

ESXi heb ik ondertussen geupgrade naar 7.0 Update 1

CPU zie ik nog steeds na een tijdje plots naar 90% gaan, ESXi blijft nu wel beheerbaar, maar wordt uiteraard traag.
Geen enkele VM heeft een hoge CPU, max 4% CPU

De 4 cores gaan elk naar 44%.
"Package 0" heeft dan constant 80-90% CPU

3 x Ubuntu host met docker containers (hier krijgt 1VM een Zigbee USB stick van de host)
1 x Ubuntu host met Home Assistant
1 x Ubuntu host met wireguard

Elke VM heeft 4CPU.
Op een VM na, allemaal ESXi 6.7 compat. (VM version 14)
Al deze hosts draaien al meerdere maanden op een ESXi 6.7 host zonder enig probleem.
Windows machine's en vCenter heb ik momenteel niet op de host.
Alles draait op een Intel 500GB NVME.

Qua mitigations aan of uit heb ik geen informatie of kennis.

EDIT:
uitvoeren van "services.sh restart" brengt geen verbetering, zodra alle services terug draaien schiet de CPU terug omhoog.
Alle VMs uitgeschakeld blijft de CPU schommelen tussen 60-80%

[ Voor 12% gewijzigd door BlackShadow op 10-02-2021 21:31 ]

[|sWORDs|]

Je zou eigenlijk maar 2vCPU per VM moeten toewijzen met jouw CPU.

Hoeveel geheugen heb je en hoeveel wijs je toe per VM?

[BlackShadow]

|sWORDs| schreef op donderdag 11 februari 2021 @ 03:29:
Je zou eigenlijk maar 2vCPU per VM moeten toewijzen met jouw CPU.

Hoeveel geheugen heb je en hoeveel wijs je toe per VM?

Omdat ik voorheen een vrij hoge reservatie memory had, heb ik dit teruggeschroefd afhankelijk van wat effectief verbruikt werd:

Docker VMs: 2GB, 4GB, 2GB,
Wireguard: 1GB
Home Assistant: 4GB

Samen dus 13GB toegewezen op het moment van de recentste problemen.
In totaal is er 32GB aanwezig in het systeem.

CPU zal ik nog wijzigen naar max 2 vCPU
Maar is het dan niet vreemd dat als ik alle VMs shutdown, de hoge CPU blijft tot ik de ESXi host herstart?
Die VMs staan echt niets te doen, nooit hoge CPU.

[ Voor 6% gewijzigd door BlackShadow op 11-02-2021 07:57 ]

[|sWORDs|]

BlackShadow schreef op donderdag 11 februari 2021 @ 07:54:
[...]


Omdat ik voorheen een vrij hoge reservatie memory had, heb ik dit teruggeschroefd afhankelijk van wat effectief verbruikt werd:

Docker VMs: 2GB, 4GB, 2GB,
Wireguard: 1GB
Home Assistant: 4GB

Samen dus 13GB toegewezen op het moment van de recentste problemen.
In totaal is er 32GB aanwezig in het systeem.

CPU zal ik nog wijzigen naar max 2 vCPU
Maar is het dan niet vreemd dat als ik alle VMs shutdown, de hoge CPU blijft tot ik de ESXi host herstart?
Die VMs staan echt niets te doen, nooit hoge CPU.

Dat is de volgende stap, kijken wat er gebeurd. Maar stats uitlezen is een stuk simpeler als alles staat zoals verwacht.

Zet ssh eens aan en ssh naar de host terwijl er geen VMs draaien en de CPU hoog is. Start esxtop en kijk welke GID hoge CPU usage heeft. Druk dan op e, type het nummer en druk op enter. Paste hier de output eens.

[Aschtra]

Aschtra schreef op dinsdag 9 februari 2021 @ 16:23:
Mannen ik kom er niet uit.
Ik wil graag upgraden van 6.7 naar 7.0. Ik heb de ISO gedownload van 7.0.1-17491101.
Hier voer ik de installer.exe uit van VCSA-ui-installer win32.

Ik doorloop het proces. Installeren van de nieuwe Vcenter 7.0 gaat prima. Echter de upgrade / migratie mislukt telkens op hetzelfde punt:

[Afbeelding]
Ja.. Source VCenter staat uit, dat heb je zelf gedaan in de upgrade.

[Afbeelding]

[Afbeelding]

Ik kan alleen nergens terugvinden waarom het maken van die groep dan zou mislukken. Als ik zelf via SSH inlog kan ik gewoon die groep maken zonder errors. Google geeft bar weinig info over deze specifieke fout.

Iemand een idee? Waar zou ik kunnen kijken voor meer info?

Mijn source VCenter draait op 6.7.0.46000

Niemand een idee?

[Aschtra]

Zelfs met een nieuwe installatie krijg ik dezelfde melding

Ik heb exact dit;

https://kb.vmware.com/s/article/2147264

maar dan met een nieuwe install ook

[ Voor 45% gewijzigd door Aschtra op 18-02-2021 12:24 ]

[BlackShadow]

|sWORDs| schreef op donderdag 11 februari 2021 @ 10:59:
[...]

Dat is de volgende stap, kijken wat er gebeurd. Maar stats uitlezen is een stuk simpeler als alles staat zoals verwacht.

Zet ssh eens aan en ssh naar de host terwijl er geen VMs draaien en de CPU hoog is. Start esxtop en kijk welke GID hoge CPU usage heeft. Druk dan op e, type het nummer en druk op enter. Paste hier de output eens.

Het heeft even geduurd, maar deze ochtend was het opnieuw.
Wel met 4 VMs draaiende, de volgende output:

code:

 8:59:05am up 4 days 17:03, 585 worlds, 4 VMs, 12 vCPUs; CPU load average: 8.32, 8.81, 8.83
PCPU USED(%):  44  44  43  44 NUMA:  44 AVG:  44
PCPU UTIL(%):  99  99  97 100 NUMA:  99 AVG:  99
CORE UTIL(%): 100     100     NUMA: 100 AVG: 100

        ID        GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT
         1          1 system            285  107.32  202.85    0.00 27118.75       -  400.00    0.00   12.59    0.00    0.00    0.00
     22887      22887 vFileserver-new    12   18.25   49.73    0.01  809.87   14.02  233.64    0.00    8.62  142.42    0.00    0.00
     19935      19935 vHomeassistant     12   18.22   64.09    0.01  778.78    0.41  353.71   59.33   15.92   34.40    0.00    0.00
     15318      15318 vDocker            10   14.14   34.33    0.01  759.03    0.00  263.79    0.90    1.99   28.72    0.00    0.00
      8748       8748 hostd.526046       32    4.73   13.42    0.00 3200.00       -   22.56    0.00    0.02    0.00    0.00    0.00
     22905      22905 vWin10-new         11    3.35   13.36    0.01  992.11    0.29  122.41   99.15    3.86    0.00    0.00    0.00
    264810     264810 esxtop.569935       1    2.91    6.53    0.00   89.77       -    6.28    0.00    0.89    0.00    0.00    0.00
     11042      11042 vpxa.526333        38    2.86    9.95    0.00 3800.00       -   20.97    0.00    3.10    0.00    0.00    0.00
      2082       2082 net-lacp.525205     3    1.65    2.66    0.00  286.00       -   19.14    0.00    0.00    0.00    0.00    0.00
    264639     264639 sshd.569869         1    1.13    1.81    0.00  100.00       -    0.01    0.00    0.00    0.00    0.00    0.00
     20025      20025 hostd-probe.527     8    1.10    1.78    0.00  800.00       -   15.97    0.00    0.00    0.00    0.00    0.00
      6980       6980 rhttpproxy.5258    19    1.10    1.77    0.00 1900.00       -    1.77    0.00    0.00    0.00    0.00    0.00
       997        997 vmsyslogd.52460     6    0.57    0.96    0.00  600.00       -    0.06    0.00    0.03    0.00    0.00    0.00
      9827       9827 nscd.526188         6    0.55    0.89    0.00  600.00       -    0.89    0.00    0.00    0.00    0.00    0.00
      6278       6278 hostdCgiServer.    12    0.01    0.02    0.00 1200.00       -    8.10    0.00    0.00    0.00    0.00    0.00
        10         10 drivers            12    0.00    0.01    0.00 1200.00       -   31.37    0.00    0.00    0.00    0.00    0.00
      9962       9962 dcbd.526208         1    0.00    0.00    0.00   92.28       -   10.23    0.00    0.00    0.00    0.00    0.00
     10853      10853 settingsd.52631     2    0.00    0.00    0.00  200.00       -    3.54    0.00    0.00    0.00    0.00    0.00
      4467       4467 ioFilterVPServe     2    0.00    0.00    0.00  200.00       -    0.89    0.00    0.00    0.00    0.00    0.00
      2386       2386 busybox.525270      1    0.00    0.00    0.00  100.00       -    0.88    0.00    0.00    0.00    0.00    0.00

Alleen krijg ik na "e" "1" niet gesorteerd op %Used.

code:

 8:53:57am up 4 days 16:57, 585 worlds, 4 VMs, 12 vCPUs; CPU load average: 8.83, 8.77, 8.95
PCPU USED(%):  42  42  46  46 NUMA:  44 AVG:  44
PCPU UTIL(%):  97  99  99  99 NUMA:  98 AVG:  98
CORE UTIL(%): 100     100     NUMA: 100 AVG: 100

        ID        GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT
    524289          1 idle1               1    0.00    0.79    0.00    0.00       -   98.15    0.00    0.00    0.00    0.00    0.00
    524290          1 idle2               1    0.00    0.07    0.00    0.00       -   98.87    0.00    0.00    0.00    0.00    0.00
    524291          1 idle3               1    0.00    0.53    0.00    0.00       -   98.41    0.00    0.00    0.00    0.00    0.00
    524292          1 vmkEventAsyncMs     1    0.00    0.00    0.00   98.94       -    0.00    0.00    0.00    0.00    0.00    0.00
    524293          1 fastslab            1    0.00    0.00    0.00   72.07       -   26.87    0.00    0.00    0.00    0.00    0.00
    524294          1 debugtermlivedu     1    0.00    0.00    0.00   98.94       -    0.00    0.00    0.00    0.00    0.00    0.00
    524295          1 logSysAlert         1    0.00    0.00    0.00   98.94       -    0.00    0.00    0.00    0.00    0.00    0.00
    524296          1 serialLogger        1    0.00    0.00    0.00   98.94       -    0.00    0.00    0.00    0.00    0.00    0.00

De enige waarden die ik zie met meer dan 0% used(, maar er zijn meer rijen dan ik zichtbaar heb):

    524303          1 netCoalesce2Wor     1    1.68    2.70    0.00   85.46       -    8.83    0.00    0.00    0.00    0.00    0.00
    524378          1 retireWld.0000      1    5.34    8.60    0.00   87.39       -    3.70    0.00    0.00    0.00    0.00    0.00
    524379          1 retireWld.0001      1    4.23    6.76    0.00   85.55       -    7.39    0.00    0.00    0.00    0.00    0.00
    524380          1 retireWld.0002      1    6.24   11.71    0.00   83.65       -    4.33    0.00    0.00    0.00    0.00    0.00
    524381          1 retireWld.0003      1    5.72   10.15    0.00   84.62       -    4.92    0.00    0.00    0.00    0.00    0.00
    524382          1 itRebalance         1   10.84   21.47    0.00   63.43       -   14.79    0.00    0.00    0.00    0.00    0.00
    524383          1 memschedRealloc     1    0.00    0.00    0.00   99.69       -    0.00    0.00    0.00    0.00    0.00    0.00
    524384          1 memschedRealloc     1    1.16    3.02    0.00   96.64       -    0.03    0.00    0.00    0.00    0.00    0.00

[ Voor 40% gewijzigd door BlackShadow op 19-02-2021 09:59 ]

[|sWORDs|]

BlackShadow schreef op vrijdag 19 februari 2021 @ 09:55:
[...]


Het heeft even geduurd, maar deze ochtend was het opnieuw.
Wel met 4 VMs draaiende, de volgende output:

code:

 8:59:05am up 4 days 17:03, 585 worlds, 4 VMs, 12 vCPUs; CPU load average: 8.32, 8.81, 8.83
PCPU USED(%):  44  44  43  44 NUMA:  44 AVG:  44
PCPU UTIL(%):  99  99  97 100 NUMA:  99 AVG:  99
CORE UTIL(%): 100     100     NUMA: 100 AVG: 100

        ID        GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT
         1          1 system            285  107.32  202.85    0.00 27118.75       -  400.00    0.00   12.59    0.00    0.00    0.00
     22887      22887 vFileserver-new    12   18.25   49.73    0.01  809.87   14.02  233.64    0.00    8.62  142.42    0.00    0.00
     19935      19935 vHomeassistant     12   18.22   64.09    0.01  778.78    0.41  353.71   59.33   15.92   34.40    0.00    0.00
     15318      15318 vDocker            10   14.14   34.33    0.01  759.03    0.00  263.79    0.90    1.99   28.72    0.00    0.00
      8748       8748 hostd.526046       32    4.73   13.42    0.00 3200.00       -   22.56    0.00    0.02    0.00    0.00    0.00
     22905      22905 vWin10-new         11    3.35   13.36    0.01  992.11    0.29  122.41   99.15    3.86    0.00    0.00    0.00
    264810     264810 esxtop.569935       1    2.91    6.53    0.00   89.77       -    6.28    0.00    0.89    0.00    0.00    0.00
     11042      11042 vpxa.526333        38    2.86    9.95    0.00 3800.00       -   20.97    0.00    3.10    0.00    0.00    0.00
      2082       2082 net-lacp.525205     3    1.65    2.66    0.00  286.00       -   19.14    0.00    0.00    0.00    0.00    0.00
    264639     264639 sshd.569869         1    1.13    1.81    0.00  100.00       -    0.01    0.00    0.00    0.00    0.00    0.00
     20025      20025 hostd-probe.527     8    1.10    1.78    0.00  800.00       -   15.97    0.00    0.00    0.00    0.00    0.00
      6980       6980 rhttpproxy.5258    19    1.10    1.77    0.00 1900.00       -    1.77    0.00    0.00    0.00    0.00    0.00
       997        997 vmsyslogd.52460     6    0.57    0.96    0.00  600.00       -    0.06    0.00    0.03    0.00    0.00    0.00
      9827       9827 nscd.526188         6    0.55    0.89    0.00  600.00       -    0.89    0.00    0.00    0.00    0.00    0.00
      6278       6278 hostdCgiServer.    12    0.01    0.02    0.00 1200.00       -    8.10    0.00    0.00    0.00    0.00    0.00
        10         10 drivers            12    0.00    0.01    0.00 1200.00       -   31.37    0.00    0.00    0.00    0.00    0.00
      9962       9962 dcbd.526208         1    0.00    0.00    0.00   92.28       -   10.23    0.00    0.00    0.00    0.00    0.00
     10853      10853 settingsd.52631     2    0.00    0.00    0.00  200.00       -    3.54    0.00    0.00    0.00    0.00    0.00
      4467       4467 ioFilterVPServe     2    0.00    0.00    0.00  200.00       -    0.89    0.00    0.00    0.00    0.00    0.00
      2386       2386 busybox.525270      1    0.00    0.00    0.00  100.00       -    0.88    0.00    0.00    0.00    0.00    0.00

Alleen krijg ik na "e" "1" niet gesorteerd op %Used.

code:

 8:53:57am up 4 days 16:57, 585 worlds, 4 VMs, 12 vCPUs; CPU load average: 8.83, 8.77, 8.95
PCPU USED(%):  42  42  46  46 NUMA:  44 AVG:  44
PCPU UTIL(%):  97  99  99  99 NUMA:  98 AVG:  98
CORE UTIL(%): 100     100     NUMA: 100 AVG: 100

        ID        GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT
    524289          1 idle1               1    0.00    0.79    0.00    0.00       -   98.15    0.00    0.00    0.00    0.00    0.00
    524290          1 idle2               1    0.00    0.07    0.00    0.00       -   98.87    0.00    0.00    0.00    0.00    0.00
    524291          1 idle3               1    0.00    0.53    0.00    0.00       -   98.41    0.00    0.00    0.00    0.00    0.00
    524292          1 vmkEventAsyncMs     1    0.00    0.00    0.00   98.94       -    0.00    0.00    0.00    0.00    0.00    0.00
    524293          1 fastslab            1    0.00    0.00    0.00   72.07       -   26.87    0.00    0.00    0.00    0.00    0.00
    524294          1 debugtermlivedu     1    0.00    0.00    0.00   98.94       -    0.00    0.00    0.00    0.00    0.00    0.00
    524295          1 logSysAlert         1    0.00    0.00    0.00   98.94       -    0.00    0.00    0.00    0.00    0.00    0.00
    524296          1 serialLogger        1    0.00    0.00    0.00   98.94       -    0.00    0.00    0.00    0.00    0.00    0.00

De enige waarden die ik zie met meer dan 0% used(, maar er zijn meer rijen dan ik zichtbaar heb):

    524303          1 netCoalesce2Wor     1    1.68    2.70    0.00   85.46       -    8.83    0.00    0.00    0.00    0.00    0.00
    524378          1 retireWld.0000      1    5.34    8.60    0.00   87.39       -    3.70    0.00    0.00    0.00    0.00    0.00
    524379          1 retireWld.0001      1    4.23    6.76    0.00   85.55       -    7.39    0.00    0.00    0.00    0.00    0.00
    524380          1 retireWld.0002      1    6.24   11.71    0.00   83.65       -    4.33    0.00    0.00    0.00    0.00    0.00
    524381          1 retireWld.0003      1    5.72   10.15    0.00   84.62       -    4.92    0.00    0.00    0.00    0.00    0.00
    524382          1 itRebalance         1   10.84   21.47    0.00   63.43       -   14.79    0.00    0.00    0.00    0.00    0.00
    524383          1 memschedRealloc     1    0.00    0.00    0.00   99.69       -    0.00    0.00    0.00    0.00    0.00    0.00
    524384          1 memschedRealloc     1    1.16    3.02    0.00   96.64       -    0.03    0.00    0.00    0.00    0.00    0.00

Je hebt met 4 VMs 12vCPU, dat zou met jouw CPU maximaal 8vCPU moeten zijn. Niet meer vCPU per VM dan fysieke cores, dus mogelijk minder dan 8 als je ook single vCPU VMs hebt.

Sowieso is een lijstje met vCPU per VM nodig en heb je iets met power modes gedaan? (TDP down, of energy efficiency modes)

Met de huidige waardes kun je niet heel veel zonder lijstje met vCPU en met verkeerde vCPU config, maar goed: Je kunt zien aan de overlap, costop en met wat aannames (vCPU onbekend) ready dat de boel overloaded is. Mogelijk heeft het toewijzen van hyper threads als echte cores hier wat mee van doen en/of het wachten op IO van de fileserver (wederom niet veel over te zeggen zonder vCPU te weten).
System usage is hoog, maar een gedeelte daarvan is overlap van andere worlds (VMs) en die is ook hoger dan verwacht.

BlackShadow schreef op woensdag 10 februari 2021 @ 19:30:
[...]
ESXi heb ik ondertussen geupgrade naar 7.0 Update 1

Wat gebruik je als bootdrive? En kun je niet eens een clean install doen?
BIOS van de NUC en firmware van de Intel drive up to date?

[ Voor 5% gewijzigd door |sWORDs| op 19-02-2021 11:59 ]

[BlackShadow]

|sWORDs| schreef op vrijdag 19 februari 2021 @ 11:17:
[...]

Je hebt met 4 VMs 12vCPU, dat zou met jouw CPU maximaal 8vCPU moeten zijn. Niet meer vCPU per VM dan fysieke cores, dus mogelijk minder dan 8 als je ook single vCPU VMs hebt.

Sowieso is een lijstje met vCPU per VM nodig en heb je iets met power modes gedaan? (TDP down, of energy efficiency modes)

Met de huidige waardes kun je niet heel veel zonder lijstje met vCPU en met verkeerde vCPU config, maar goed: Je kunt zien aan de overlap, costop en met wat aannames (vCPU onbekend) ready dat de boel overloaded is. Mogelijk heeft het toewijzen van hyper threads als echte cores hier wat mee van doen en/of het wachten op IO van de fileserver (wederom niet veel over te zeggen zonder vCPU te weten).
System usage is hoog, maar een gedeelte daarvan is overlap van andere worlds (VMs) en die is ook hoger dan verwacht.


[...]

Wat gebruik je als bootdrive? En kun je niet eens een clean install doen?
BIOS van de NUC en firmware van de Intel drive up to date?

Klopt inderdaad, ik had nog andere machines gemigreerd van een 12core machine.
Ik heb het aangepast en gereboot.



Telkens 2vCPU, 1 socket
vDocker en vHomeassistant zijn Ubuntu machines, vWin10 en vFileserver zijn Windows 10
Boot vanaf USB Disk en datastore is Intel 500GB NVME.
Laatste BIOS update en verder geen gekke zaken in de BIOS.
Mogelijk wel enkele power states aangezet voor low power, maar dat weet ik niet meer uit het hoofd.

Mijn USB stick is geen gloednieuwe, die zou ik eventueel kunnen vervangen als test.
Maar ik dacht dat ESXi volledig in memory draaide zodra geboot, dan zou dat niet mogen uitmaken?

Clean install is geen probleem, kan ik proberen.
Ik heb een andere ESXi host waar de machines even naartoe kunnen.

[ Voor 19% gewijzigd door BlackShadow op 19-02-2021 14:20 ]

[|sWORDs|]

BlackShadow schreef op vrijdag 19 februari 2021 @ 13:23:
[...]


Klopt inderdaad, ik had nog andere machines gemigreerd van een 12core machine.
Ik heb het aangepast en gereboot.

[Afbeelding]

Dat ziet er correct uit, nu nog een keer esxtop. Een keer terwijl alles prima is en een keer tijdens problemen.

BlackShadow schreef op vrijdag 19 februari 2021 @ 13:23:
[...]

Boot vanaf USB Disk

Ik heb vmsyslogd wel eens hoog zien zijn als er iets mis is met de scratch disk config.

BlackShadow schreef op vrijdag 19 februari 2021 @ 13:23:
[...]
Mogelijk wel enkele power states aangezet voor low power, maar dat weet ik niet meer uit het hoofd.

Kun je de Power Management setting in ESXi laten zien? Zo wel Technology als Active Policy.

BlackShadow schreef op vrijdag 19 februari 2021 @ 13:23:
[...]

Clean install is geen probleem, kan ik proberen.

Zeker de moeite waard, je zou ook als test even de NVMe drive ook als boot kunnen gebruiken, dan is de scratch ook gelijk correct.

[BlackShadow]

|sWORDs| schreef op vrijdag 19 februari 2021 @ 14:28:
[...]

Dat ziet er correct uit, nu nog een keer esxtop. Een keer terwijl alles prima is en een keer tijdens problemen.

code:

 2:07:04pm up  3:21, 577 worlds, 4 VMs, 7 vCPUs; CPU load average: 0.36, 0.29, 0.29
PCPU USED(%):  10  11 9.8 9.2 NUMA:  10 AVG:  10
PCPU UTIL(%):  15  15  13  12 NUMA:  14 AVG:  14
CORE UTIL(%):  27      23     NUMA:  25 AVG:  25

        ID        GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT
     18558      18558 vDocker            10   14.61   18.00    0.10  979.85    0.10    1.99  180.38    0.08    0.00    0.00    0.00
     26964      26964 vHomeassistant      9   12.41   14.50    0.02  886.68    0.00    0.83   85.91    0.03    0.00    0.00    0.00
     15336      15336 vFileserver-new    10    9.63   13.09    0.09  987.54    4.38    1.99  181.37    0.12    0.00    0.00    0.00
     32481      32481 esxtop.529358       1    2.49    2.95    0.00   97.32       -    0.00    0.00    0.00    0.00    0.00    0.00
      8766       8766 hostd.526048       28    1.52    1.69    0.07 2800.00       -    0.46    0.00    0.00    0.00    0.00    0.00
     19935      19935 vWin10-new         11    1.01    1.28    0.03 1098.39    0.26    0.39  198.14    0.02    0.00    0.00    0.00
         1          1 system            287    0.87  348.18    0.00 28299.63       -   56.21    0.00    0.88    0.00    0.00    0.00
     11060      11060 vpxa.526335        38    0.36    0.47    0.00 3800.00       -    0.25    0.00    0.00    0.00    0.00    0.00
      7295       7295 rhttpproxy.5258    18    0.28    0.37    0.01 1800.00       -    0.20    0.00    0.00    0.00    0.00    0.00
       997        997 vmsyslogd.52460     6    0.09    0.13    0.00  599.69       -    0.07    0.00    0.00    0.00    0.00    0.00
     32346      32346 sshd.529343         1    0.03    0.03    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
     20007      20007 hostd-probe.527     8    0.01    0.01    0.00  800.00       -    0.01    0.00    0.00    0.00    0.00    0.00
      6197       6197 hostdCgiServer.    12    0.01    0.02    0.00 1200.00       -    0.02    0.00    0.00    0.00    0.00    0.00
      2088       2088 net-lacp.525197     3    0.01    0.01    0.00  299.82       -    0.01    0.00    0.00    0.00    0.00    0.00
        10         10 drivers            12    0.00    0.01    0.00 1200.00       -    0.03    0.00    0.00    0.00    0.00    0.00
      9791       9791 nscd.526185         6    0.00    0.00    0.00  600.00       -    0.00    0.00    0.00    0.00    0.00    0.00
      4809       4809 vmware-usbarbit     1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
      9926       9926 dcbd.526200         1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
      2394       2394 busybox.525271      1    0.00    0.00    0.00   99.99       -    0.00    0.00    0.00    0.00    0.00    0.00
      6683       6683 net-lbt.525773      1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
     10871      10871 settingsd.52631     2    0.00    0.00    0.00  200.00       -    0.00    0.00    0.00    0.00    0.00    0.00
      4494       4494 ioFilterVPServe     2    0.00    0.00    0.00  200.00       -    0.00    0.00    0.00    0.00    0.00    0.00
      6062       6062 storageRM.52570     1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
      4107       4107 swapobjd.525471     1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
        11         11 ft                  1    0.00    0.00    0.00  100.00       -    0.01    0.00    0.00    0.00    0.00    0.00
      2168       2168 busybox.525230      1    0.00    0.00    0.00   99.98       -    0.00    0.00    0.00    0.00    0.00    0.00
      9089       9089 slpd.526105         1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
        12         12 vmotion             1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
       484        484 init.524559         1    0.00    0.00    0.00  100.00       -    0.00    0.00    0.00    0.00    0.00    0.00
       988        988 vmsyslogd.52460     1    0.00    0.00    0.00   99.99       -    0.00    0.00    0.00    0.00    0.00    0.00
      1069       1069 sh.524618           1    0.00    0.00    0.00   99.98       -    0.00    0.00    0.00    0.00    0.00    0.00
      1150       1150 vobd.524627        23    0.00    0.00    0.00 2299.39       -    0.00    0.00    0.00    0.00    0.00    0.00
      1477       1477 sh.524705           1    0.00    0.00    0.00   99.96       -    0.00    0.00    0.00    0.00    0.00    0.00
      1578       1578 vmkeventd.52471     1    0.00    0.00    0.00   99.95       -    0.00    0.00    0.00    0.00    0.00    0.00
      1806       1806 vmkdevmgr.52481     1    0.00    0.00    0.00   99.95       -    0.00    0.00    0.00    0.00    0.00    0.00
      1998       1998 sh.525187           1    0.00    0.00    0.00   99.95       -    0.00    0.00    0.00    0.00    0.00    0.00
      2111       2111 dhclient-uw.525     1    0.00    0.00    0.00   99.96       -    0.00    0.00    0.00    0.00    0.00    0.00

|sWORDs| schreef op vrijdag 19 februari 2021 @ 14:28:
Kun je de Power Management setting in ESXi laten zien? Zo wel Technology als Active Policy.

|sWORDs| schreef op vrijdag 19 februari 2021 @ 14:28:
Zeker de moeite waard, je zou ook als test even de NVMe drive ook als boot kunnen gebruiken, dan is de scratch ook gelijk correct.

Ik ga een herinstall doen op een gloednieuwe USB stick.

[|sWORDs|]

Ik zou shift O drukken tijdens de install en systemMediaSize=min toevoegen aan de commandline en vervolgens installeren op de NVMe drive. Dan krijg je een OS disk van 25GB en de rest als datastore. Ik ga morgen wat moederborden wisselen, herinstalleren en ook over van 16GB Sandisk UltraFit naar een partitie op een NVMe drive op al mijn servers.

Mocht je toch perse een USB drive willen, neem er dan eentje van 32GB van een goed merk.

Ook zou ik de power mode op high performance zetten en pas weer naar low power of balanced kijken als de problemen weg zijn. Met high performance is er trouwens geen single core turbo, maar altijd de maximale all core turbo frequency.

[ Voor 43% gewijzigd door |sWORDs| op 19-02-2021 20:09 ]

[BlackShadow]

|sWORDs| schreef op vrijdag 19 februari 2021 @ 19:57:
Ik zou shift O drukken tijdens de install en systemMediaSize=min toevoegen aan de commandline en vervolgens installeren op de NVMe drive. Dan krijg je een OS disk van 25GB en de rest als datastore. Ik ga morgen wat moederborden wisselen, herinstalleren en ook over van 16GB Sandisk UltraFit naar een partitie op een NVMe drive op al mijn servers.

Mocht je toch perse een USB drive willen, neem er dan eentje van 32GB van een goed merk.

Ook zou ik de power mode op high performance zetten en pas weer naar low power of balanced kijken als de problemen weg zijn. Met high performance is er trouwens geen single core turbo, maar altijd de maximale all core turbo frequency.

Thx, heb de partitionering vanavond getest met een andere host.
Ik ga het zo ook uitvoeren op de NUC.

Power mode is ook aangepast, maar morgen herinstall.

[tuxie6]

Hallo allemaal

Zijn er hier succesverhalen met het doorgeven aan een VM voor Plex o.i.d van de Intel(R) Core(TM) i3-10100 GPU Intel® UHD Graphics 630
ik lees er veel positieve verhalen over bij ESXI-6.7 echter bij ESXI-7** is het veel minder succesvol.
klachten zijn dat het na reboot van de VM weer niet werkt, (code43) of dat de VM crasht. ook na plaatsing van een extra grafische kaart zodat de console daarop word weergegeven.


Ik heb het topic doorgespit en sWORDs zegt in

|sWORDs| schreef op zondag 21 januari 2018 @ 15:33:
[...]

Alles vanaf Haswell zou moeten lukken, zolang de CPU graphics heeft, de chipset graphics support en de console niet op de IGP draait, maar vanaf Skylake heb je ook HEVC 8-bit decoding en 10-bit vanaf Kaby Lake.
|sWORDs| in "Zuinige ESXi Server"

dat is omstreeks de tijd van ESXI6-7? met een i3-8100? die ook een Intel® UHD Graphics 630 heeft.

ik las ook:

wjjkoevoets schreef op maandag 8 juni 2020 @ 22:47:
[...]

Mocht iemand hetzelfde probleem hebben: ESXi 6.7 U3 vers geïnstalleerd en het probleem was weg.

Is ESXI-7** echt zo slecht in het doorgeven van de intel GPU?
Terug naar ESXI-6.7 gaat natuurlijk niet zo gemakkelijk omdat deze noop ;-( geen rekening heeft gehouden met backwards compatibility aangaande de hardware en storage versie`s.

[wjjkoevoets]

tuxie6 schreef op dinsdag 23 februari 2021 @ 10:06:
Hallo allemaal

Zijn er hier succesverhalen met het doorgeven aan een VM voor Plex o.i.d van de Intel(R) Core(TM) i3-10100 GPU Intel® UHD Graphics 630
ik lees er veel positieve verhalen over bij ESXI-6.7 echter bij ESXI-7** is het veel minder succesvol.
klachten zijn dat het na reboot van de VM weer niet werkt, (code43) of dat de VM crasht. ook na plaatsing van een extra grafische kaart zodat de console daarop word weergegeven.


Ik heb het topic doorgespit en sWORDs zegt in

[...]


dat is omstreeks de tijd van ESXI6-7? met een i3-8100? die ook een Intel® UHD Graphics 630 heeft.

ik las ook:

[...]


Is ESXI-7** echt zo slecht in het doorgeven van de intel GPU?
Terug naar ESXI-6.7 gaat natuurlijk niet zo gemakkelijk omdat deze noop ;-( geen rekening heeft gehouden met backwards compatibility aangaande de hardware en storage versie`s.

Ik heb het naderhand nooit meer geprobeerd met 7.0. Ik gebruik nog altijd 6.7.0 Update 3 (Build 17167734). Is je hardware zo exotisch dat het niet op 6.7 werkt?

[tuxie6]

Hallo wjjkoevoets.

Het gaat om de Virtuele hardware versie`s die zoals ik het interpreteer niet niet met oudere ESXI versie`s samenwerken.

Ik had dit gelezen https://kb.vmware.com/s/article/1003746
waarin staat:
Note: If a virtual machine is created on a VMware product that supports a given virtual hardware version and is then migrated to a VMware product that does not support this level of virtual hardware, it does not power on. Consult the chart above. Virtual machines created by VMware products and versions located higher up in the chart cannot be powered on by products lower on the chart.

ESXi 6.7 U2 = Virtual Hardware Version 15
ESXi 7.0 U1 (7.0.1) = Virtual Hardware Version 18

[|sWORDs|]

tuxie6 schreef op dinsdag 23 februari 2021 @ 10:54:
Hallo wjjkoevoets.

Het gaat om de Virtuele hardware versie`s die zoals ik het interpreteer niet niet met oudere ESXI versie`s samenwerken.

Ik had dit gelezen https://kb.vmware.com/s/article/1003746
waarin staat:
Note: If a virtual machine is created on a VMware product that supports a given virtual hardware version and is then migrated to a VMware product that does not support this level of virtual hardware, it does not power on. Consult the chart above. Virtual machines created by VMware products and versions located higher up in the chart cannot be powered on by products lower on the chart.

ESXi 6.7 U2 = Virtual Hardware Version 15
ESXi 7.0 U1 (7.0.1) = Virtual Hardware Version 18

6.7 voor U? had een probleem waarbij een custom passthrough list niet werkte. Dit heb ik aan laten passen.
Tussen 7 en 6.7 met update zou geen verschil moeten zitten.
VM hw level kun je zo in de VMX aanpassen, of gewoon een nieuwe VM met lagere hardware level maken en de oude disk gebruiken.

[wjjkoevoets]

tuxie6 schreef op dinsdag 23 februari 2021 @ 10:54:
Hallo wjjkoevoets.

Het gaat om de Virtuele hardware versie`s die zoals ik het interpreteer niet niet met oudere ESXI versie`s samenwerken.

Ik had dit gelezen https://kb.vmware.com/s/article/1003746
waarin staat:
Note: If a virtual machine is created on a VMware product that supports a given virtual hardware version and is then migrated to a VMware product that does not support this level of virtual hardware, it does not power on. Consult the chart above. Virtual machines created by VMware products and versions located higher up in the chart cannot be powered on by products lower on the chart.

ESXi 6.7 U2 = Virtual Hardware Version 15
ESXi 7.0 U1 (7.0.1) = Virtual Hardware Version 18

Zoals |sWORDs| aangeeft, is dit vrij eenvoudig op te lossen. Als je 6.7 installeert kan je de 7.0 VM verwijderen (exclusief de disks natuurlijk), een nieuwe VM maken en de disks koppelen aan deze nieuwe VM.

Edit: Je kan dit zelfs al testen op 7.0 door een nieuwe VM aan te maken met een oudere hardware versie en vervolgens je disks te koppelen aan deze VM.

[ Voor 7% gewijzigd door wjjkoevoets op 23-02-2021 15:51 ]

[tuxie6]

Betreft GPU passtrough Van een I3-10100 Intel® UHD Graphics 630 en een H470 Chipset

Helaas geeft ESXi-6.7.0-20210204001 hetzelfde resultaat als ESXi_7.0D .1-0.30.17551050.
misschien van het weekend nog ESXI6-7U3 uitproberen.

In het geval dat esxcli system settings kernel set -s vga -v FALSE niet afdoende werkte. Console stopte wel bij Shutting down firmware services...
Heb ik er al een extra grafische kaart in gestopt om de console af te vangen (nu valt hij niet meer onder
Zuinige ESXI server)

Ik gebruik Windows 10.
Intel drivers gedownload en geïnstalleerd.
pcihole.start 2048
SVGA present is FALSE

Ik ervaar nog steeds een code 43 na opstarten van Windows. De Code 43 verdwijnt meestal na een disable / enable van de intel gpu in windows.


Kan het een reset fout zijn bij het overgeven naar de VM misschien?
Vergeet ik iets in de \etc\vmware\passtru.map of een andere belangrijke configuratie file.

[|sWORDs|]

tuxie6 schreef op woensdag 24 februari 2021 @ 21:50:
[...]
Helaas geeft ESXi-6.7.0-20210204001 hetzelfde resultaat als ESXi_7.0D .1-0.30.17551050.
misschien van het weekend nog ESXI6-7U3 uitproberen.
[...]

|sWORDs| schreef op dinsdag 23 februari 2021 @ 11:38:
[...]
Tussen 7 en 6.7 met update zou geen verschil moeten zitten.
[...]

Enige wat echt anders werkt is 6.5 en 6.7 zonder updates (daar werkt het enablen van passthrough via de .map niet).

Sinds 6.7 zijn er grote aanpassingen in passthrough, in de eerste versie werkt de .map niet op devices zonder function-level-reset. Dit heb ik aan laten passen in één van de eerste grote updates, U1 of U2. Sindsdien zijn er volgens mij niet of nauwelijks wijzigingen geweest aan passthrough zelf.
Het vrijgeven van de console zou wel anders kunnen zijn, omdat 7 geen linux subdriver stack (vertaallaag tussen niet linux OS en linux drivers) meer heeft en alleen nog native drivers.

Edit: Mailbox ingedoken, aanpassing was voor 6.7 U1. Dus:

• 6.5 en eerder, oude passthrough, VMKLinux
• 6.7.0, nieuwe passthrough met bug, VMKLinux
• 6.7.0 U1+, nieuwe passthrough zonder bug, VMKLinux
• 7.0+, nieuwe passthrough zonder bug, geen VMKLinux

[ Voor 49% gewijzigd door |sWORDs| op 25-02-2021 12:59 ]

[Zwelgje]

tuxie6 schreef op woensdag 24 februari 2021 @ 21:50:
Betreft GPU passtrough Van een I3-10100 Intel® UHD Graphics 630 en een H470 Chipset

Helaas geeft ESXi-6.7.0-20210204001 hetzelfde resultaat als ESXi_7.0D .1-0.30.17551050.
misschien van het weekend nog ESXI6-7U3 uitproberen.

In het geval dat esxcli system settings kernel set -s vga -v FALSE niet afdoende werkte. Console stopte wel bij Shutting down firmware services...
Heb ik er al een extra grafische kaart in gestopt om de console af te vangen (nu valt hij niet meer onder
Zuinige ESXI server)

Ik gebruik Windows 10.
Intel drivers gedownload en geïnstalleerd.
pcihole.start 2048
SVGA present is FALSE

Ik ervaar nog steeds een code 43 na opstarten van Windows. De Code 43 verdwijnt meestal na een disable / enable van de intel gpu in windows.


Kan het een reset fout zijn bij het overgeven naar de VM misschien?
Vergeet ik iets in de \etc\vmware\passtru.map of een andere belangrijke configuratie file.

hier moet ik dit als advanced property zetten op de VM om mijn AMD door te lussen

hypervisor.cpuid.v0 = "FALSE"

try

[|sWORDs|]

Zwelgje schreef op donderdag 25 februari 2021 @ 20:53:
[...]


hier moet ik dit als advanced property zetten op de VM om mijn AMD door te lussen

hypervisor.cpuid.v0 = "FALSE"

try

Dat zou alleen maar bij NVIDIA consumer GPUs moeten hoeven.

[BlackShadow]

BlackShadow schreef op zaterdag 20 februari 2021 @ 22:18:
[...]


Thx, heb de partitionering vanavond getest met een andere host.
Ik ga het zo ook uitvoeren op de NUC.

Power mode is ook aangepast, maar morgen herinstall.

Helaas het probleem is niet opgelost na nieuwe installatie op partitie op de NVME.
Ik heb een 2e host klaar gemaakt en alle VMs daar naartoe gebracht, ik ga afwachten of het daar stabieler draait.

[|sWORDs|]

BlackShadow schreef op zaterdag 27 februari 2021 @ 12:28:
[...]


Helaas het probleem is niet opgelost na nieuwe installatie op partitie op de NVME.
Ik heb een 2e host klaar gemaakt en alle VMs daar naartoe gebracht, ik ga afwachten of het daar stabieler draait.

En de output?

[Zwelgje]

|sWORDs| schreef op donderdag 25 februari 2021 @ 23:02:
[...]

Dat zou alleen maar bij NVIDIA consumer GPUs moeten hoeven.

ja hier voor een AMD RX Vega (ingebakken in een Intel nuc8i7HVK)

[BlackShadow]

|sWORDs| schreef op zaterdag 27 februari 2021 @ 12:36:
[...]

En de output?

Deze morgen opnieuw hetzelfde probleem, ESXi gaat terug helemaal onderuit sinds de nieuwe installatie: niet te pingen, geen ssh, geen web gui... Harde reboot was de enige oplossing.

Dit is het laatste CPU gebruik volgens vCenter (draaide op een andere host), daaruit blijkt geen hoge CPU:


Memory is 20GB van de 32GB voorzien voor VMs.
Elke VM heeft max 2vCPU
Alle VMs zijn intussen geupgrade naar HW versie 18.
Performance op High Performance
Fresh install op partitie NVME disk, de rest is datastore.

[ Voor 79% gewijzigd door BlackShadow op 28-02-2021 09:43 ]

[nelizmastr]

|sWORDs| schreef op donderdag 25 februari 2021 @ 23:02:
[...]

Dat zou alleen maar bij NVIDIA consumer GPUs moeten hoeven.

Had ik ook nodig voor mijn Quadro P620 en die valt officieel niet onder consumer GPU’s

Mijn Plex is dan wel weer een Linux bak. Windows werkte bij mij überhaupt niet dus die missie is opgegeven. Linux draait wel een stuk zuiniger met RAM, scheelt weer een paar gig

[|sWORDs|]

nelizmastr schreef op zondag 28 februari 2021 @ 10:10:
[...]


Had ik ook nodig voor mijn Quadro P620 en die valt officieel niet onder consumer GPU’s

Mijn Plex is dan wel weer een Linux bak. Windows werkte bij mij überhaupt niet dus die missie is opgegeven. Linux draait wel een stuk zuiniger met RAM, scheelt weer een paar gig

Quadro P620 valt in deze context ook onder consumer grade. NVIDIA blokkeert het starten van de firmware als er een hypervisor gezien wordt.

[ Voor 8% gewijzigd door |sWORDs| op 28-02-2021 10:41 ]

[|sWORDs|]

BlackShadow schreef op zondag 28 februari 2021 @ 08:15:
[...]


Deze morgen opnieuw hetzelfde probleem, ESXi gaat terug helemaal onderuit sinds de nieuwe installatie: niet te pingen, geen ssh, geen web gui... Harde reboot was de enige oplossing.

Dit is het laatste CPU gebruik volgens vCenter (draaide op een andere host), daaruit blijkt geen hoge CPU:
[Afbeelding]

Memory is 20GB van de 32GB voorzien voor VMs.
Elke VM heeft max 2vCPU
Alle VMs zijn intussen geupgrade naar HW versie 18.
Performance op High Performance
Fresh install op partitie NVME disk, de rest is datastore.

Lijkt dus het meeste op een probleem met de NIC. Ik heb een nieuwere unsigned driver voor je die je zou kunnen proberen. Wat laat ie eigenlijk zien op een monitor zodra ie niet meer reageert?

[ Voor 8% gewijzigd door |sWORDs| op 28-02-2021 10:46 ]

[BlackShadow]

|sWORDs| schreef op zondag 28 februari 2021 @ 10:40:
[...]

Lijkt dus het meeste op een probleem met de NIC. Ik heb een nieuwere unsigned driver voor je die je zou kunnen proberen. Wat laat ie eigenlijk zien op een monitor zodra ie niet meer reageert?

Hij staat momenteel in de meterkast, ik kan hem eens verplaatsen naar mijn bureau.
Een nieuwere driver wil ik altijd proberen, ik zou ook de Fling USB NIC drivers kunnen proberen met een USB nic dan: https://flings.vmware.com/usb-network-native-driver-for-esxi

[|sWORDs|]

BlackShadow schreef op zondag 28 februari 2021 @ 16:19:
[...]


Hij staat momenteel in de meterkast, ik kan hem eens verplaatsen naar mijn bureau.
Een nieuwere driver wil ik altijd proberen, ik zou ook de Fling USB NIC drivers kunnen proberen met een USB nic dan: https://flings.vmware.com/usb-network-native-driver-for-esxi

Ik zou eerst wel eens willen zien wat ie op het scherm doet of dat ie nog op een toetsenbord reageert.

[BlackShadow]

|sWORDs| schreef op zondag 28 februari 2021 @ 19:25:
[...]

Ik zou eerst wel eens willen zien wat ie op het scherm doet of dat ie nog op een toetsenbord reageert.

Voorlopig is het probleem niet meer voorgekomen.
Ik heb nu mijn belangrijkste VMs op een andere ESXi hots draaien.

Het lijkt erop dat een van deze VMs de problemen veroorzaakt, maar blijkbaar niet op de andere host.
De andere host is een i7-7700 CPU met 32GB RAM, qua CPU iets krachtiger en meer cores. Zelfde ESXi versie.

[ComTech]

Ik heb een nieuwe SSD toegevoegd aan mijn ESXi server en heb alle VM's overgezet, alles draait weer prima.
Nu wil ik de oude SSD eruit halen maar bij het unmounten krijg ik steeds een error.

Failed - The resource 'Datastore Name: DataStoreA VMFS uuid: 5e0f715a-2ae857a6-0846-00d861a7e83c' is in use.
Errors
Cannot unmount volume 'Datastore Name: DataStoreA VMFS uuid: 5e0f715a-2ae857a6-0846-00d861a7e83c' because file system is busy. Correct the problem and retry the operation.

Er staan geen VM's meer op of andere zaken.
Er staan alleen 2 mappen op genaamd .sdd.sf en .locker
Hoe krijg ik die datastore nu verwijderd van het systeem?

[RudolfR]

@ComTech Moet 'm niet eerst deleten voordat je 'm kunt unmounten?

Misschien wordt deze nog gebruikt voor logging?
https://bobcares.com/blog...e-the-resource-is-in-use/

[ComTech]

RudolfR schreef op zondag 14 maart 2021 @ 14:23:
@ComTech Moet 'm niet eerst deleten voordat je 'm kunt unmounten?

Misschien wordt deze nog gebruikt voor logging?
https://bobcares.com/blog...e-the-resource-is-in-use/

Ik heb het gevonden de optie ScratchConfig.CurrentScratchLocation stond nog een verwijzing naar de oude datastore.
Deze veranderd toen een restart gedaan.
En toen kon ik eerst het volume unmounten en toen verwijderen.

[BlackShadow]

|sWORDs| schreef op zondag 28 februari 2021 @ 19:25:
[...]

Ik zou eerst wel eens willen zien wat ie op het scherm doet of dat ie nog op een toetsenbord reageert.

Zonet terug zeer hoge CPU, ESXi bleef wel bereikbaar, blijft gewoon reageren.
Geen enkele VM heeft op dat moment hoge CPU.

Wat me wel opvalt is dat de CPU grafiek de HDD grafiek volgt, dus als de HDD load hoog is, gaat de CPU ook mee omhoog. Dat lijkt me toch vreemd.

[g1n0]

Misschien is het IoWait?

[jadjong]

BlackShadow schreef op zondag 21 maart 2021 @ 20:46:
[...]


Zonet terug zeer hoge CPU, ESXi bleef wel bereikbaar, blijft gewoon reageren.
Geen enkele VM heeft op dat moment hoge CPU.

Wat me wel opvalt is dat de CPU grafiek de HDD grafiek volgt, dus als de HDD load hoog is, gaat de CPU ook mee omhoog. Dat lijkt me toch vreemd.

Rotte kabel waardoor de cpu crc errors te verduren krijgt?

[BlackShadow]

Ik heb gisterenavond nog 1 VM gemoved naar een andere ESXI host, dat is nog gelukt.
Daarna is ESXi volledig gecrashed, resterende VMs down, geen ping meer naar de ESXi host, geen web gui,...
Op een monitor rechtstreeks aangesloten is er nog beeld (grij idle scherm), maar geen reactie op toetsen als F12 of enter.

g1n0 schreef op zondag 21 maart 2021 @ 21:08:
Misschien is het IoWait?

Ik heb weinig tot geen debug kennis van ESXi, onderstaande screen is genomen tijdens de problemen, voor de crash.
Toen was er zeer grote vertraging merkbaar op alle VMs en hoge CPU op de host zelf.
Geen enkele VM had hoge CPU op dat moment, volgens mij ook geen hoge load.
Systeem is een Intel NUC i5 (7th gen) met 32GB RAM en 500GB NVME als boot en datastore disk.

jadjong schreef op zondag 21 maart 2021 @ 21:08:
[...]

Rotte kabel waardoor de cpu crc errors te verduren krijgt?

Betreft een onboard NVME (M2)

[|sWORDs|]

BlackShadow schreef op maandag 22 maart 2021 @ 07:33:
Ik heb gisterenavond nog 1 VM gemoved naar een andere ESXI host, dat is nog gelukt.
Daarna is ESXi volledig gecrashed, resterende VMs down, geen ping meer naar de ESXi host, geen web gui,...
Op een monitor rechtstreeks aangesloten is er nog beeld (grij idle scherm), maar geen reactie op toetsen als F12 of enter.


[...]


Ik heb weinig tot geen debug kennis van ESXi, onderstaande screen is genomen tijdens de problemen, voor de crash.
Toen was er zeer grote vertraging merkbaar op alle VMs en hoge CPU op de host zelf.
Geen enkele VM had hoge CPU op dat moment, volgens mij ook geen hoge load.
Systeem is een Intel NUC i5 (7th gen) met 32GB RAM en 500GB NVME als boot en datastore disk.

[Afbeelding]


[...]


Betreft een onboard NVME (M2)

1. vHomeassistent had 2 vCPU
2. vWin10-new had 2 vCPU

Dan heb je hier waarschijnlijk twee met 1 vCPU en 2 met 2 vCPU, want 10-4=6 wat is wat?

1. vWireguard
2. vWin10 heeft waarschijnlijk 2 vCPU gezien identiek ready time
3. docker-nuc
4. vDockerExt heeft waarschijnlijk 2 vCPU gezien costop

Met de aanname hierboven:
vHomeassistent heeft 10,64% ready time per CPU, dit is tijd waarop de machine wacht met taken uitvoeren door CPU krapte, iets hoog. Ook zien we flink wachten op system services, dit lijkt te wachten op een kernel actie, hoogstwaarschijnlijk storage. Maar we hebben de stats van een VM nodig (om alleen de vCPU worlds te bekijken) en de storage metrics om het zeker te weten.

Andere VMs laten ongeveer hetzelfde zien, zowel ietsje te veel CPU wachttijd als waarschijnlijk flink te veel wachten op vmkernel.

• Hitte een probleem met M.2? Firmware bug? Rotte SSD?
• 1:5 ratio op een zwakke dual core CPU is mogelijk ook iets te veel van het goede, afhankelijk van de VMs, zijn die Win10 VMs wel optimized?

Wat voor Intel is het en welke firmware versie? Je zegt steeds Intel 500GB NVMe, maar die bestaan niet in M.2, alleen 512GB als 600p, 6000p en 660p, 760p, p3100 en H10. Power modus nog steeds op max? Komt wel vaker voor dat PCIe drives het niet goed trekken om te switchen.

[ Voor 12% gewijzigd door |sWORDs| op 22-03-2021 10:04 ]

[BlackShadow]

|sWORDs| schreef op maandag 22 maart 2021 @ 09:45:
[...]

1. vHomeassistent had 2 vCPU
2. vWin10-new had 2 vCPU

Dan heb je hier waarschijnlijk twee met 1 vCPU en 2 met 2 vCPU, want 10-4=6 wat is wat?

1. vWireguard
2. vWin10 heeft waarschijnlijk 2 vCPU gezien identiek ready time
3. docker-nuc
4. vDockerExt heeft waarschijnlijk 2 vCPU gezien costop

Met de aanname hierboven:
vHomeassistent heeft 10,64% ready time per CPU, dit is tijd waarop de machine wacht met taken uitvoeren door CPU krapte, iets hoog. Ook zien we flink wachten op system services, dit lijkt te wachten op een kernel actie, hoogstwaarschijnlijk storage. Maar we hebben de stats van een VM nodig (om alleen de vCPU worlds te bekijken) en de storage metrics om het zeker te weten.

Andere VMs laten ongeveer hetzelfde zien, zowel ietsje te veel CPU wachttijd als waarschijnlijk flink te veel wachten op vmkernel.

• Hitte een probleem met M.2? Firmware bug? Rotte SSD?
• 1:5 ratio op een zwakke dual core CPU is mogelijk ook iets te veel van het goede, afhankelijk van de VMs, zijn die Win10 VMs wel optimized?

Wat voor Intel is het en welke firmware versie? Je zegt steeds Intel 500GB NVMe, maar die bestaan niet in M.2, alleen 512GB als 600p, 6000p en 660p, 760p, p3100 en H10. Power modus nog steeds op max? Komt wel vaker voor dat PCIe drives het niet goed trekken om te switchen.

Alles heeft 20 dagen gedraaid tot ik vHomeassistant naar deze host heb gemoved, deze heeft nu 1 vCPU (heb ik inderdaad verminderd, was eerder 2 vCPU).
De problemen zijn dus pas begonnen zodra vHomeassistant gemigreerd werd naar deze host (niet meteen, maar toch opvallend).
vWireguard 1 vCPU, de rest heeft 2 vCPU.

Win10 VMs zijn niet optimized, deze heb ik nu shutdowned en vHomeAssistant terug op de host draaien (als test om te kijken of de problemen zo ook terug opduiken).
512GB Intel 600P (SSDPEKKW51) fw versie kan ik zo niet meteen bepalen.
Ik zie dat de nieuwste firmware 3.0.10 op 7/20/2020 is verschenen, dan zal deze disk hoogstwaarschijnlijk niet de laatste firmware draaien.
Ik ga de firmware upgraden met mijn Windows desktop en de disk checken.
Power settings nog steeds op High performance.

[|sWORDs|]

BlackShadow schreef op maandag 22 maart 2021 @ 13:07:
[...]


Alles heeft 20 dagen gedraaid tot ik vHomeassistant naar deze host heb gemoved, deze heeft nu 1 vCPU (heb ik inderdaad verminderd, was eerder 2 vCPU).
De problemen zijn dus pas begonnen zodra vHomeassistant gemigreerd werd naar deze host (niet meteen, maar toch opvallend).
vWireguard 1 vCPU, de rest heeft 2 vCPU.

Win10 VMs zijn niet optimized, deze heb ik nu shutdowned en vHomeAssistant terug op de host draaien (als test om te kijken of de problemen zo ook terug opduiken).
512GB Intel 600P (SSDPEKKW51) fw versie kan ik zo niet meteen bepalen.
Ik zie dat de nieuwste firmware 3.0.10 op 7/20/2020 is verschenen, dan zal deze disk hoogstwaarschijnlijk niet de laatste firmware draaien.
Ik ga de firmware upgraden met mijn Windows desktop en de disk checken.
Power settings nog steeds op High performance.

Er zijn best wel wat mensen met temperatuur problemen icm 600p. Bekijk de smart waardes eens zodra de problemen beginnen, daar staat de temperatuur bij, dit zou ver onder de 70 graden moeten zijn, in het ideale geval zo'n 40 graden onder langdurige full load.

[BlackShadow]

|sWORDs| schreef op maandag 22 maart 2021 @ 13:44:
[...]

Er zijn best wel wat mensen met temperatuur problemen icm 600p. Bekijk de smart waardes eens zodra de problemen beginnen, daar staat de temperatuur bij, dit zou ver onder de 70 graden moeten zijn, in het ideale geval zo'n 40 graden onder langdurige full load.

[root@esxi-nuc:~] esxcli storage core device smart get -d eui.0000000001000000e4d25c5629944d01
Parameter Value Threshold Worst Raw
------------------------ ----- --------- ----- ---
Health Status OK N/A N/A N/A
Power-on Hours 25639 N/A N/A N/A
Power Cycle Count 782 N/A N/A N/A
Reallocated Sector Count 0 90 N/A N/A
Drive Temperature 21 70 N/A N/A

Lijkt me sterk dat die zomaar naar 70°C zou gaan onder load.
Ik kan wel de active cooling van de NUC wat hoger zetten.
Geen idee waar die nu op staat, vermoedelijk standaard, maar ik hoor wel continu een fan draaien.

[|sWORDs|]

BlackShadow schreef op maandag 22 maart 2021 @ 13:51:
[...]


[root@esxi-nuc:~] esxcli storage core device smart get -d eui.0000000001000000e4d25c5629944d01
Parameter Value Threshold Worst Raw
------------------------ ----- --------- ----- ---
Health Status OK N/A N/A N/A
Power-on Hours 25639 N/A N/A N/A
Power Cycle Count 782 N/A N/A N/A
Reallocated Sector Count 0 90 N/A N/A
Drive Temperature 21 70 N/A N/A

Lijkt me sterk dat die zomaar naar 70°C zou gaan onder load.
Ik kan wel de active cooling van de NUC wat hoger zetten.
Geen idee waar die nu op staat, vermoedelijk standaard, maar ik hoor wel continu een fan draaien.

Erg makkelijk te testen, knal je w10 VMs eens aan en start op beide een random write test met meerdere threads en hogere QD in bijvoorbeeld crystal disk mark met een groot aantal GB. Eventueel ook nog even CPUID Powermax SSE workload om de CPU ook mee laten verwarmen.

Zelfs met thermal pads gaat het blijkbaar mis in een NUC met een enkele desktop workload:
https://community.intel.c...s/Overheating/td-p/512558
https://ipcamtalk.com/thr...aphics.37768/#post-350864
https://communities.vmwar...FS-partition/td-p/2259201
https://community.intel.c...-AT-70-Degree/td-p/354565

"My Intel NUC would overheat on the NVMe drive and crash unless I set the fan to unacceptable levels."

"INTEL 600P 1TB Temperature AT 70 Degree
pc drop nvme partition when large data is transferring...
when idle just 39"

"i have a experience on 70 degree
after installing a small heatsink ,the maximum temperature <50"

'Over the past two months we have noticed a few NUCS overheating on their M2 Intel 600p series drives and use the thermal pads included in the pc to keep them cool. Is Intel aware of the issue and if so, what if anything can we do to fix this other than going the third party route and slapping heatsinks on every single m2 drive setup we sell?"

[ Voor 32% gewijzigd door |sWORDs| op 22-03-2021 14:09 ]

[BlackShadow]

|sWORDs| schreef op maandag 22 maart 2021 @ 13:54:
[...]

Erg makkelijk te testen, knal je w10 VMs eens aan en start op beide een random write test met meerdere threads en hogere QD in bijvoorbeeld crystal disk mark met een groot aantal GB. Eventueel ook nog even CPUID Powermax SSE workload om de CPU ook mee laten verwarmen.

Zelfs met thermal pads gaat het blijkbaar mis in een NUC met een enkele desktop workload:
https://community.intel.c...s/Overheating/td-p/512558
https://ipcamtalk.com/thr...aphics.37768/#post-350864
https://communities.vmwar...FS-partition/td-p/2259201
https://community.intel.c...-AT-70-Degree/td-p/354565

"My Intel NUC would overheat on the NVMe drive and crash unless I set the fan to unacceptable levels."

"INTEL 600P 1TB Temperature AT 70 Degree
pc drop nvme partition when large data is transferring...
when idle just 39"

"i have a experience on 70 degree
after installing a small heatsink ,the maximum temperature <50"

'Over the past two months we have noticed a few NUCS overheating on their M2 Intel 600p series drives and use the thermal pads included in the pc to keep them cool. Is Intel aware of the issue and if so, what if anything can we do to fix this other than going the third party route and slapping heatsinks on every single m2 drive setup we sell?"

Inderdaad veel issues gemeld, ik zie echter maximaal korte piek 53°C tijdens CPU en disk stress test, meestal blijft hij hangen rond 47°C.
Tussen 2 disk tests zie ik de temperatuur ook meteen terug naar 35-40°C zakken.

Ik kijk even hoe ik de nvme in mijn desktop kan hangen voor fw upgrade + surface test.

EDIT:
De versie die ik eerder terugvond is de versie van de update tool blijkbaar.
Drive bevat fw PSF121C volgens de Intel Memory and Storage Tool, up to date dus.

Volgens CrystalDiskInfo is de drive status goed.

[ Voor 5% gewijzigd door BlackShadow op 22-03-2021 16:10 ]

[|sWORDs|]

BlackShadow schreef op maandag 22 maart 2021 @ 14:13:
[...]


Inderdaad veel issues gemeld, ik zie echter maximaal korte piek 53°C tijdens CPU en disk stress test, meestal blijft hij hangen rond 47°C.
Tussen 2 disk tests zie ik de temperatuur ook meteen terug naar 35-40°C zakken.

Ik kijk even hoe ik de nvme in mijn desktop kan hangen voor fw upgrade + surface test.

EDIT:
De versie die ik eerder terugvond is de versie van de update tool blijkbaar.
Drive bevat fw PSF121C volgens de Intel Memory and Storage Tool, up to date dus.

Volgens CrystalDiskInfo is de drive status goed.

Wat ik bedoel is de drive en CPU 15 minuten maximaal belasten en dan de temperatuur uitlezen.

[BlackShadow]

|sWORDs| schreef op maandag 22 maart 2021 @ 20:01:
[...]

Wat ik bedoel is de drive en CPU 15 minuten maximaal belasten en dan de temperatuur uitlezen.

Heb zonet even een langere test gedaan, powerMAX SSE continu laten lopen samen met CrystalDiskMark 9 runs 16GB file paar keer herstart simultaan met HDDSCAN.
Kom in totaal op ongeveer 20 minuten stress uit op max 58°C, die zakt opnieuw zeer snel zodra de test stopt.

code:

 5:16:32am up 21:05, 598 worlds, 3 VMs, 5 vCPUs; CPU load average: 1.67, 1.61, 1.57

 ADAPTR PATH                 NPTH   CMDS/s  READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd GAVG/cmd QAVG/cmd
 vmhba0 -                       0     0.00     0.00     0.00     0.00     0.00     0.00     0.00     0.00     0.00
 vmhba1 -                       1 37367.75 37363.66     4.10   362.35     0.13     0.29     0.00     0.29     0.00

[|sWORDs|]

BlackShadow schreef op dinsdag 23 maart 2021 @ 13:17:
[...]


Heb zonet even een langere test gedaan, powerMAX SSE continu laten lopen samen met CrystalDiskMark 9 runs 16GB file paar keer herstart simultaan met HDDSCAN.
Kom in totaal op ongeveer 20 minuten stress uit op max 58°C, die zakt opnieuw zeer snel zodra de test stopt.

[Afbeelding]

code:

 5:16:32am up 21:05, 598 worlds, 3 VMs, 5 vCPUs; CPU load average: 1.67, 1.61, 1.57

 ADAPTR PATH                 NPTH   CMDS/s  READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd GAVG/cmd QAVG/cmd
 vmhba0 -                       0     0.00     0.00     0.00     0.00     0.00     0.00     0.00     0.00     0.00
 vmhba1 -                       1 37367.75 37363.66     4.10   362.35     0.13     0.29     0.00     0.29     0.00

Dat lijkt me goed genoeg.

[Tadango]

Een vraagje voor de ESXI kenners hier Ik heb een ESXI 7.0 machine draaien waarin ik graag een GPU wil gebruiken in een Windows VM. Ik krijg de PCI Passthrough alleen niet werkend voor een oude GPU. De realtek netwerk kaart werkt prima met passthrough. Setup:

Asrock B350M Pro 4
Ryzen 1800X
32Gb G.Skill geheugen
Intel CT Desktop ethernet
GT240 om te testen (plan is een GTX1080 oid te gaan gebruiken)

Gezien de passthrough werkt voor de onboard realtek netwerk kaart welke daarna prima werkt in Windows hoopte ik dat het ook zo eenvoudig was voor een GPU. Helaas krijg ik de bekende fout: Failed to register the device pciPassthru0 for xxx due to unavailable hardware or software support. Ik heb de /etc/vmware/passthru.map aangepast naar D3hot voor NVIDIA.

Kan dit liggen aan de oude kaart? Kan ik nog iets anders proberen in het bios?

[|sWORDs|]

Tadango schreef op woensdag 24 maart 2021 @ 10:02:
Een vraagje voor de ESXI kenners hier Ik heb een ESXI 7.0 machine draaien waarin ik graag een GPU wil gebruiken in een Windows VM. Ik krijg de PCI Passthrough alleen niet werkend voor een oude GPU. De realtek netwerk kaart werkt prima met passthrough. Setup:

Asrock B350M Pro 4
Ryzen 1800X
32Gb G.Skill geheugen
Intel CT Desktop ethernet
GT240 om te testen (plan is een GTX1080 oid te gaan gebruiken)

Gezien de passthrough werkt voor de onboard realtek netwerk kaart welke daarna prima werkt in Windows hoopte ik dat het ook zo eenvoudig was voor een GPU. Helaas krijg ik de bekende fout: Failed to register the device pciPassthru0 for xxx due to unavailable hardware or software support. Ik heb de /etc/vmware/passthru.map aangepast naar D3hot voor NVIDIA.

Kan dit liggen aan de oude kaart? Kan ik nog iets anders proberen in het bios?

De mode in de map moet d3d0 zijn en mogelijk heb je disableACSCheck als kernel parameter nodig.
Heb je hypervisor.cpuid.v0 = "FALSE" op de VM gezet en staat "Expose IOMMU to the guest OS" uit?

[Tadango]

|sWORDs| schreef op woensdag 24 maart 2021 @ 10:50:
[...]

De mode in de map moet d3d0 zijn en mogelijk heb je disableACSCheck als kernel parameter nodig.
Heb je hypervisor.cpuid.v0 = "FALSE" op de VM gezet en staat "Expose IOMMU to the guest OS" uit?

d3d0 is de waarde voor D3hot in de mapping file inderdaad. disableACSCheck was al nodig om uberhaupt passthrough werkend te krijgen. Expose IOMMU to the guest OS aan of uit heeft geen invloed.

hypervisor.cpuid.v0 = "FALSE" had ik nog niet, maar heeft ook geen invloed. Was dat niet nodig als je error 43 had in het Guest OS?

Btw, moet je een host reboot doen na het wijzigen van de mapping file?

[ Voor 5% gewijzigd door Tadango op 24-03-2021 10:59 ]

[|sWORDs|]

Tadango schreef op woensdag 24 maart 2021 @ 10:55:
[...]


d3d0 is de waarde voor D3hot in de mapping file inderdaad. disableACSCheck was al nodig om uberhaupt passthrough werkend te krijgen. Expose IOMMU to the guest OS aan of uit heeft geen invloed.

hypervisor.cpuid.v0 = "FALSE" had ik nog niet, maar heeft ook geen invloed. Was dat niet nodig als je error 43 had in het Guest OS?

Btw, moet je een host reboot doen na het wijzigen van de mapping file?

Ja, je moet rebooten en met expose IOMMU aan laat de monitor je de VM niet starten.

Edit: Ik zie nu dat je helemaal geen tweede videokaart hebt? Console vrijgeven kan het probleem zijn, wat zie je als je er een scherm aanhangt? ESXi console?

Edit 2: Ik zie nu ook dat het een oud AMD bord is, de IOMMU groepen zijn daar vaak niet goed.

[ Voor 20% gewijzigd door |sWORDs| op 24-03-2021 11:10 ]

[Tadango]

|sWORDs| schreef op woensdag 24 maart 2021 @ 11:03:
[...]

Ja, je moet rebooten en met expose IOMMU aan laat de monitor je de VM niet starten.

Edit: Ik zie nu dat je helemaal geen tweede videokaart hebt? Console vrijgeven kan het probleem zijn, wat zie je als je er een scherm aanhangt? ESXi console?

Edit 2: Ik zie nu ook dat het een oud AMD bord is, de IOMMU groepen zijn daar vaak niet goed.

Bedankt, een reboot en de VM start wel. Eens kijken of ik daarmee verder kom.

Ik zie inderdaad de console normaal. Console gebruik ik nooit dus hoeft niet te werken. De VM die de kaart gebruikt zal default ook niet starten dus ik verwacht geen problemen en bij een reboot zal deze de console tonen denk ik.

Edit: Helaas de error 43 na het starten van de VM. In device manager uit en inschakelen lijkt te helpen maar nog steeds geen output.

[ Voor 8% gewijzigd door Tadango op 24-03-2021 11:53 ]

[|sWORDs|]

Tadango schreef op woensdag 24 maart 2021 @ 11:38:
[...]


Bedankt, een reboot en de VM start wel. Eens kijken of ik daarmee verder kom.

Ik zie inderdaad de console normaal. Console gebruik ik nooit dus hoeft niet te werken. De VM die de kaart gebruikt zal default ook niet starten dus ik verwacht geen problemen en bij een reboot zal deze de console tonen denk ik.

Edit: Helaas de error 43 na het starten van de VM. In device manager uit en inschakelen lijkt te helpen maar nog steeds geen output.

Je kunt geen device doorgeven die in gebruik is.

[Tadango]

|sWORDs| schreef op woensdag 24 maart 2021 @ 13:53:
[...]

Je kunt geen device doorgeven die in gebruik is.

Ik lees overal dat dat prima kan omdat de VM de kaart afpakt. ESXI doet een reset en geeft de kaart aan de VM. Error 43 is een fout waarbij NVIDIA de boel blokkeert omdat ze niet willen dat je het in een VM draait.

Maar.... als je gelijk hebt kan ik de console uitschakelen en moet het werken.

[BlackShadow]

|sWORDs| schreef op dinsdag 23 maart 2021 @ 13:59:
[...]

Dat lijkt me goed genoeg.

Opnieuw een crash




De grafiek van de VM hierboven is voor alle 4 te zien, CPU time ready but could not get scheduled.
Iets later dus de crash.

Deze keer met beide Win10 machines shutdown, enkel:
docker-nuc 2vcpu / 2GB RAM
vdockerext 2vcpu / 2GB RAM
vhomeassistant 2vcpu / 4GB RAM
vwireguard 1vcpu / 1GB RAM

In totaal 32GB ram aanwezig.
Het idee van de samen hang met HDD activiteit lijkt mij niet te kloppen, de grafiek die de hoogte in gaat is latency wat mij logisch lijkt als de CPU plots niet meer volgt.

Iemand nog een idee hoe er meer inzicht te krijgen is in dit probleem?

[|sWORDs|]

BlackShadow schreef op vrijdag 26 maart 2021 @ 14:32:
[...]


Opnieuw een crash

[Afbeelding]
[Afbeelding]

De grafiek van de VM hierboven is voor alle 4 te zien, CPU time ready but could not get scheduled.
Iets later dus de crash.

Deze keer met beide Win10 machines shutdown, enkel:
docker-nuc 2vcpu / 2GB RAM
vdockerext 2vcpu / 2GB RAM
vhomeassistant 2vcpu / 4GB RAM
vwireguard 1vcpu / 1GB RAM

In totaal 32GB ram aanwezig.
Het idee van de samen hang met HDD activiteit lijkt mij niet te kloppen, de grafiek die de hoogte in gaat is latency wat mij logisch lijkt als de CPU plots niet meer volgt.

Iemand nog een idee hoe er meer inzicht te krijgen is in dit probleem?

Te weinig metrics om een conclusie te kunnen trekken. Idle en wait ontbreken, ook costop en de disk metrics zijn niet te zien.

[BlackShadow]

|sWORDs| schreef op zaterdag 27 maart 2021 @ 10:45:
[...]

Te weinig metrics om een conclusie te kunnen trekken. Idle en wait ontbreken, ook costop en de disk metrics zijn niet te zien.

Ik vrees dat ik deze info na een reboot niet meer kan tevoorschijn halen?
Kan je aangeven hoe deze info op te vragen is na een crash?
Gezien de crash, kan ik enkel nog iets uit vcenter halen.

[tuxie6]

tuxie6 schreef op woensdag 24 februari 2021 @ 21:50:
Betreft GPU passtrough Van een I3-10100 Intel® UHD Graphics 630 en een H470 Chipset

Helaas geeft ESXi-6.7.0-20210204001 hetzelfde resultaat als ESXi_7.0D .1-0.30.17551050.
misschien van het weekend nog ESXI6-7U3 uitproberen.

In het geval dat esxcli system settings kernel set -s vga -v FALSE niet afdoende werkte. Console stopte wel bij Shutting down firmware services...
Heb ik er al een extra grafische kaart in gestopt om de console af te vangen (nu valt hij niet meer onder
Zuinige ESXI server)

Ik gebruik Windows 10.
Intel drivers gedownload en geïnstalleerd.
pcihole.start 2048
SVGA present is FALSE

Ik ervaar nog steeds een code 43 na opstarten van Windows. De Code 43 verdwijnt meestal na een disable / enable van de intel gpu in windows.


Kan het een reset fout zijn bij het overgeven naar de VM misschien?
Vergeet ik iets in de \etc\vmware\passtru.map of een andere belangrijke configuratie file.

Even laten weten wat voor mij werkte.
ik vind het zelf ook fijn om van iemand af te kunnen kijken

Het is gelukt met de volgende settings
ESXI versie 7U1

in /etc/passtru.map
# Intel VGA Passthrough testing
8086 9bc8 flr false #normaal = 3d03 maar dan moest ik de in de vm de Intel® UHD Graphics 630 uitschakelen en weer inschakelen.

Esxi console uit schakelen:
esxcli system settings kernel set -s vga -v FALSE

ik gebruik het met SVGA present voor mijn eigen gemak maar het werkt ook prima met remote desktop en svga present is FALSE
SVGA present is True maar heb 3D uitgeschakeld

nu start de vm betrouwbaar op met
esxi svga als 1e kaart voor 2D
intel® UHD Graphics 630 als 2e kaart. voor 3D
Plex is gelukkig dus ik ook.

[marcel19]

Ik loop tegen een probleem aan met mijn ESXI server.

Versie:

Ik heb er een extra SSD in geplaats van 1TB.
Maar ik krijg deze met geen mogelijkheid als datastore toegevoegd.

Ik heb deze SSD gecleand met Gparted zodat er geen partitions meer op stonden.
Daarna in de server gestoken en daarna loop ik vast.

ik krijg constant deze error:
Operation failed, diagnostics report: Unable to create Filesystem, please see VMkernel log for more details: Failed to create VMFS on device naa.500253885002076e:1

En als ik kijk in het log zie ik:

code:

2021-05-14T08:44:47.812Z cpu3:2097379)WARNING: SCU OSSL scuTaskMgmt: type:0x0  cmdId.serialNumber:0x1c8e
2021-05-14T08:44:47.812Z cpu1:2097697)WARNING: HPP: HppThrottleLogForDevice:1128: Cmd 0x2a (0x45b8c1bdc540, 2099557) to dev "naa.500253885002076e" on path "vmhba1:C2:T0:L0" Failed:
2021-05-14T08:44:47.812Z cpu1:2097697)WARNING: HPP: HppThrottleLogForDevice:1136: Error status H:0x0 D:0x40 P:0x0 . hppAction = 3
2021-05-14T08:44:47.812Z cpu1:2097697)ScsiDeviceIO: 4325: Cmd(0x45b8c1c8f8c0) 0x35, CmdSN 0x1c8e from world 0 to dev "naa.500253885002076e" failed H:0x0 D:0x40 P:0x0
2021-05-14T08:44:47.816Z cpu1:2097697)HPP: HppThrottleLogForDevice:1101: Error status H:0x0 D:0x40 P:0x0 . from device naa.500253885002076e repeated 5 times,  hppAction = 3
2021-05-14T08:44:47.816Z cpu1:2097697)WARNING: HPP: HppThrottleLogForDevice:1128: Cmd 0x2a (0x45b8c1bdc540, 2099557) to dev "naa.500253885002076e" on path "vmhba1:C2:T0:L0" Failed:
2021-05-14T08:44:47.816Z cpu1:2097697)WARNING: HPP: HppThrottleLogForDevice:1136: Error status H:0x2 D:0x0 P:0x0 . hppAction = 3
2021-05-14T08:44:47.816Z cpu1:2097697)ScsiDeviceIO: 4277: Cmd(0x45b8c1cde4c0) 0x35, CmdSN 0x1cbd from world 0 to dev "naa.500253885002076e" failed H:0x2 D:0x0 P:0x0
2021-05-14T08:44:47.816Z cpu1:2097697)ScsiDeviceIO: 4277: Cmd(0x45b901510dc0) 0x35, CmdSN 0x1cbe from world 0 to dev "naa.500253885002076e" failed H:0x2 D:0x0 P:0x0
2021-05-14T08:44:47.817Z cpu19:2097366)ScsiDevice: 979: Could not flush cache of local device naa.500253885002076e. Failure
2021-05-14T08:44:47.829Z cpu3:2097379)WARNING: SCU OSSL scuTaskMgmt: type:0x0  cmdId.serialNumber:0x1a
2021-05-14T08:44:47.831Z cpu18:2097191)ScsiDeviceIO: 4315: Cmd(0x45b8c1bdc540) 0x2a, cmdId.initiator=0x4304eed11240 CmdSN 0x1a from world 2099557 to dev "naa.500253885002076e" failed H:0x5 D:0x0 P:0x0 . Cmd count Active:4 Queued:0
2021-05-14T08:44:47.843Z cpu19:2097697)HPP: HppThrottleLogForDevice:1070: Error status H:0x2 D:0x0 P:0x0 . from device naa.500253885002076e repeated 10 times, hppAction = 3
2021-05-14T08:44:47.851Z cpu11:2100429 opID=b90d385a)LVM: 10778: LVMProbeDevice failed on (3712651296, naa.500253885002076e:1): Device does not contain a logical volume
2021-05-14T08:44:47.851Z cpu11:2100429 opID=b90d385a)FSS: 2401: Failed to create FS on dev [naa.500253885002076e:1] fs [1TB-SSD] type [vmfs6] fbSize 1048576 => Timeout

Iemand een idee?


EDIT:

Het wisselen van SATA poort deed de truuk.

[B2]

Zijn er hier mensen die al eens wat hebben geëxperimenteerd hebben met ESXi op ARM? Als in Raspberry Pi 4? Ik wil eigenlijk wel eens wat spelen met een cluster gemaakt met 2 Pi 4’s.. en daarna het e.e.a met Kubernetes er op.

[vonkkie]

EXSI SERVER
vraag ik heb sinds kort thuis exsi draaien om diverse VM te draaien voor :

Domoticz
unifi controler
piohole
eocortex VMS

dit zodat ik niet bij een probleem met windows alles opnieuw moet instaleren
ik heb een i9 9900 met 64 gb geheugen maar met maar 1 Nic nou geeft EXSi bij de virtuele switch aan dat het handig is om een 2e Nic te hebben

de belasting is maar rond de 50/60mbps is het nodig om die 2e nic te plaatsen

[ Voor 95% gewijzigd door vonkkie op 04-07-2021 20:14 . Reden: fout ]

[g1n0]

vonkkie schreef op zondag 4 juli 2021 @ 20:10:
EXSI SERVER
vraag ik heb sinds kort thuis exsi draaien om diverse VM te draaien voor :

Domoticz
unifi controler
piohole
eocortex VMS

dit zodat ik niet bij een probleem met windows alles opnieuw moet instaleren
ik heb een i9 9900 met 64 gb geheugen maar met maar 1 Nic nou geeft EXSi bij de virtuele switch aan dat het handig is om een 2e Nic te hebben

de belasting is maar rond de 50/60mbps is het nodig om die 2e nic te plaatsen

Gaat hier niet om snelheid, maar om redundantie. Maar aangezien jij je 2e nic waarschijnlijk op dezelfde switch prikt zal dit in jouw geval weinig extra redundantie opleveren, behalve in het geval van een kabelbreuk.

Dus: nee, niet nodig

[Zwelgje]

vonkkie schreef op zondag 4 juli 2021 @ 20:10:
EXSI SERVER
vraag ik heb sinds kort thuis exsi draaien om diverse VM te draaien voor :

Domoticz
unifi controler
piohole
eocortex VMS

dit zodat ik niet bij een probleem met windows alles opnieuw moet instaleren
ik heb een i9 9900 met 64 gb geheugen maar met maar 1 Nic nou geeft EXSi bij de virtuele switch aan dat het handig is om een 2e Nic te hebben

de belasting is maar rond de 50/60mbps is het nodig om die 2e nic te plaatsen

bedrijfsmatig is het altijd slim/noodzakelijk om een 2e nic in te zetten voor redundancy (en dan uiteraard aangesloten op een 2e fysieke switch)

thuis? ik heb het wel maar meer omdat ik die 2e nic ook in het systeem had zitten voor wat jij ermee doet zou ik het laten zoals het is en lekker genieten van jet setupje

[marcel19]

Ik ben van plan om Pfsense/Opnsense te gaan draaien op mijn esxi server.

Nu heb ik daar de volgende netwerkkaart inzitten: pricewatch: Intel Ethernet Server Adapter I350-T4

Ik wil 2 van de poorten gebruiken voor de Pfsense/Opnsense machine. Deze wil ik in passtrough zetten zodat deze worden beheerd door Pfsense/Opnsense. Alleen ik kan niet vinden hoe ik kan zien welke poort op de kaart welke is in ESXI voor passtrough.



Is het overzicht van de kaart in ESXI. Daar zie ik wel verschil in:
0000:02:00.0
0000:02:00.1
0000:02:00.2
0000:02:00.3

Dus er worden 4 poorten gezien, maar hoe weet ik nu welke poort op de netwerkkaart correspondeert met de fysieke poort op de kaart?

[jadjong]

Testen.

[marcel19]

jadjong schreef op zaterdag 10 juli 2021 @ 09:43:
Testen.

Dat is niet wat ik vraag, ik snap dat ik het kan testen. maar ik wil weten en "leren" hoe ik in ESXI kan zien welke poort wat is.

[|sWORDs|]

marcel19 schreef op zaterdag 10 juli 2021 @ 09:45:
[...]


Dat is niet wat ik vraag, ik snap dat ik het kan testen. maar ik wil weten en "leren" hoe ik in ESXI kan zien welke poort wat is.

De telling van poorten kan per OS anders zijn, de hardware IDs zijn wel gelijk. Je hebt de documentatie van de specifieke kaart nodig om er achter te komen welke sub ID welke poort is. Het OS kan niet weten hoe de banen achter de chip fysiek lopen.
Ik test het ook altijd gewoon even, makkelijker dan de documentatie vinden als die er al is.

[g1n0]

Die is er: https://d2pgu9s4sfmw1s.cl...DKKm-3Ve1s6b4eobOtEUNYw__

994 pagina's lang Succes

[3DDude]

Heeft iemand een goed boek voor VMware NSX-T?
Ik zie veel oude shit voorbij komen met versie 2.4 maar we zijn op 3.x inmiddels.

Ik wil een lab bouwen nested (moet wel lukken heb een 16core met 128GB ram)
Maar zoek nog een goed boek over NSX...

Iemand tips?

Let me know

p.s. ja ik heb VMUG Advantage dus kan aan alle relevante vmware spullen komen

[ Voor 13% gewijzigd door 3DDude op 06-08-2021 16:04 ]

[loyske]

Iemand bekend met het volgende?

Intel NUC draait jaren (bijna 5 jaar) stabiel ESXi op een Samsung 960 EVO NVMe SSD.
Sinds vannacht in de SSD echter niet meer beschikbaar als datastore.
In de BIOS zie ik de schijf nog wel. Na een reboot is de schijf weer zichtbaar in ESXi, maar nadat er data gebruikt wordt, verdwijnt hij weer.

Is deze SSD stuk? Kan hij volgelopen zijn doordat ik geen TRIM gebruik?
Tips van zaken die ik nog kan checken?

[FireDrunk]

Wat zeggen de kernel logs?

[loyske]

FireDrunk schreef op dinsdag 24 augustus 2021 @ 12:19:
Wat zeggen de kernel logs?

Die staan helaas op de SSD en zijn dus niet bereikbaar:

code:

cat vmkernel.log
cat: can't open 'vmkernel.log': Input/output error
[root@esx01:/var/log]

[FireDrunk]

Probeer

dmesg

eens

[loyske]

FireDrunk schreef op dinsdag 24 augustus 2021 @ 12:28:
Probeer

dmesg

eens

Geen idee wat je er precies van wil hebben, maar zag deze voorbij komen:

code:

2021-08-24T10:11:25.209Z cpu3:262630)WARNING: NvmeScsi: 140: SCSI opcode 0xff (0x452a40e5dc80) on path vmhba1:C0:T0:L0 to namespace t10.NVMe____Samsung_SSD_960_EVO_250GB_______________C371B2715B382500 failed with NVMe host error status:
2021-08-24T10:11:25.209Z cpu3:262630)WARNING: 0xe translating to SCSI error H:0x1

Gevolgd door deze:

code:

2021-08-24T10:28:47.529Z cpu3:262882)WARNING: HBX: 3679: 'SSD': HB at offset 3751936 - Reclaiming timed out HB failed: No connection:
2021-08-24T10:28:47.529Z cpu3:262882)WARNING:   [HB state abcdef02 offset 3751936 gen 1 stampUS 166305299 uuid 6124c38e-c043d384-e458-1c697a62065f jrnl <FB 0> drv 24.82 lockImpl 3 ip 192.168.10.20]

[FireDrunk]

Reclaiming timeout, klinkt alsof een TRIM operatie te lang duurt...
Je zou de SSD eens met een linux live cd kunnen trimmen, maar het linkt alsof het ding aan het sterven is.

[loyske]

FireDrunk schreef op dinsdag 24 augustus 2021 @ 12:39:
Reclaiming timeout, klinkt alsof een TRIM operatie te lang duurt...
Je zou de SSD eens met een linux live cd kunnen trimmen, maar het linkt alsof het ding aan het sterven is.

Thanks ga het eens checken. Wil het zeker weten voordat ik de SSD RMA.