12
ESXi 7 Hauptspeicher nicht erreichbar
Moin Moin,
ich habe im Moment ein großes Problem.
Wie es scheint, ist meine SSD (neu ca. 1 Monat alt) welche nur als Boot Medium des Host dient, nicht mehr erreichbar.
Um die SSD in Richtung TBW zu schonen, nutze ich diese nur zum Booten oder um mal eine ISO zu speichern, aber nur wenn der Platz auf andern Platten langsam knapp wird oder die andere SSD mit den VM's gerade zu stark belastet wird.
Die SSD für den Host hat auch einen Datenspeicher (datastore1), darauf liegt wie oben beschrieben eigentlich nichts, vielleicht 2 GB von ca. 330 GB und ein paar zwequetschte.
Ich wollte gerade eben auf eine der wenigen Windows Maschinen, welche auf einer anderen SSD liegt, zugreifen.
Die VM reagierte langsam, bis hin zu gar nicht, also wollte ich diese Neustarten.
Nach dem Neustart blieb die RDP Sitzung schwarz, erst nach knapp 15 Minuten baute sich langsam Windows auf und ich bekam ein Bild, jedoch konnte ich nur den Task-Manager öffnen, nicht einmal der Windows-Explorer ging.
Also wollte ich direkt über den Host per VMware Remote Console auf die VM gucken, jedoch kam es nach ca. 10 Minuten zu einer Zeitüberschreitung und an der Config des Host konnte ich auch nichts ändern, bzw. aufrufen.
[bild 1]
Also habe ich in die Überwachung -> Ereignisse geguckt und sehe da:
Danach kam noch eine Meldung:
Davor und danach ist alles in Ordnung, also in den Ereignissen.
Jedoch denke ich, dass es nur eine Frage der Zeit ist, bis der Host mir den Pinken Bildschirm mit einer Fehlermeldung anzeigt und alle VM's abstürzen.
Ich habe gerade versucht eine VM anzuhalten, das funktioniert jedoch nicht mehr.....
Er sagt gestartet, aber die VM ist noch über SSH erreichbar und arbeitet, im Log steht unter Gestartet "aN.aN.NaN aN:aN:aN" was sehr beruhigend ist.
[bild 4]
Ich habe jetzt nach ca. 10 Minuten angefangen die VM's per SSH ordnungsgemäß herunterzufahren, auf der Seite des ESXi laufen sie angeblich noch.
Ich werde den Host gleich herunterfahren und die Kontakte der PCIE SSD mal vorsichtig mit einem Tuch "berühren" und sie danach wieder einbauen.
Er lief jetzt 4 Tage am stück, davor hatte ich einen Standard SATA Controller eingebaut mit mehreren Festplatten, wie man an der Speichergröße des FileShares sehen kann. (Sie wurden direkt eingebunden, ohne datastore etc.)
Kennt jemand das Problem und kann mir sagen woran das lag?
Liebe Grüße
// Nachtrag
Die Bilder verschieben sich leider, Sorry
So der host wurde neugestartet und scheint erstmal wieder zu laufen.
Die Windows VM rennt auch wieder.
Die SSD mit den VM's hatte/hat noch 103 GB Frei, RAM waren auch noch so 8GB von 80GB frei, Prozessor war so zu 60-70 % ausgelastet, was aber normal ist.
Die SSH Console des Hosts nimmt jetzt auch wieder befehle entgegen.
Achso und nein, der Host hat keine VM angehalten, die zwei Windows Maschinen sind hart weggeknallt
Warte mal, ich nutze "vmkfstools" um die Festplatten hart mit der VM zu verbinden.
Also in SSH "vmkfstools -z /vmfs/devices/disks/t10.ATA_____Festplatten_______ID /vmfs/volumes/datastore1/vmdk/Festplatten_ID.vmdk", diese zeigt ja auf die datastore1 SSD, also die vom Host Boot SSD.
Werden alle Bytes einmal auf die vom Host SSD und dann auf die richtige Fesplatte geschrieben?
Wenn ja, habe ich das problem gefunden....
Werde das ganze mal auf eine andere SSD verschieben.
ich habe im Moment ein großes Problem.
Wie es scheint, ist meine SSD (neu ca. 1 Monat alt) welche nur als Boot Medium des Host dient, nicht mehr erreichbar.
Um die SSD in Richtung TBW zu schonen, nutze ich diese nur zum Booten oder um mal eine ISO zu speichern, aber nur wenn der Platz auf andern Platten langsam knapp wird oder die andere SSD mit den VM's gerade zu stark belastet wird.
Die SSD für den Host hat auch einen Datenspeicher (datastore1), darauf liegt wie oben beschrieben eigentlich nichts, vielleicht 2 GB von ca. 330 GB und ein paar zwequetschte.
Ich wollte gerade eben auf eine der wenigen Windows Maschinen, welche auf einer anderen SSD liegt, zugreifen.
Die VM reagierte langsam, bis hin zu gar nicht, also wollte ich diese Neustarten.
Nach dem Neustart blieb die RDP Sitzung schwarz, erst nach knapp 15 Minuten baute sich langsam Windows auf und ich bekam ein Bild, jedoch konnte ich nur den Task-Manager öffnen, nicht einmal der Windows-Explorer ging.
Also wollte ich direkt über den Host per VMware Remote Console auf die VM gucken, jedoch kam es nach ca. 10 Minuten zu einer Zeitüberschreitung und an der Config des Host konnte ich auch nichts ändern, bzw. aufrufen.
[bild 1]
Also habe ich in die Überwachung -> Ereignisse geguckt und sehe da:
Wegen Konnektivitätsproblemen kann nicht mehr auf Volume 63505146-84f4f092-2e0f-a85e4556b1fb (datastore1) zugegriffen werden. Es wird versucht, eine Wiederherstellung durchzuführen. Das Ergebnis liegt demnächst vor.
Typ Warnung
Uhrzeit Dienstag, 08. November 2022, 16:08:54 +0100
Knowledgebase Klicken Sie hier, um die VMware.com-Online-Knowledgebase zu diesem Ereignis zu durchsuchen
[bild 2]Danach kam noch eine Meldung:
Das Protokollieren auf Speichermedien ist fehlgeschlagen. Protokolldateien werden nicht mehr lokal auf diesem Host gespeichert.
Typ Warnung
Uhrzeit Dienstag, 08. November 2022, 18:01:01 +0100
Knowledgebase Klicken Sie hier, um die VMware.com-Online-Knowledgebase zu diesem Ereignis zu durchsuchen
[bild 3]Davor und danach ist alles in Ordnung, also in den Ereignissen.
Jedoch denke ich, dass es nur eine Frage der Zeit ist, bis der Host mir den Pinken Bildschirm mit einer Fehlermeldung anzeigt und alle VM's abstürzen.
Ich habe gerade versucht eine VM anzuhalten, das funktioniert jedoch nicht mehr.....
Er sagt gestartet, aber die VM ist noch über SSH erreichbar und arbeitet, im Log steht unter Gestartet "aN.aN.NaN aN:aN:aN" was sehr beruhigend ist.
[bild 4]
Ich habe jetzt nach ca. 10 Minuten angefangen die VM's per SSH ordnungsgemäß herunterzufahren, auf der Seite des ESXi laufen sie angeblich noch.
Ich werde den Host gleich herunterfahren und die Kontakte der PCIE SSD mal vorsichtig mit einem Tuch "berühren" und sie danach wieder einbauen.
Er lief jetzt 4 Tage am stück, davor hatte ich einen Standard SATA Controller eingebaut mit mehreren Festplatten, wie man an der Speichergröße des FileShares sehen kann. (Sie wurden direkt eingebunden, ohne datastore etc.)
Kennt jemand das Problem und kann mir sagen woran das lag?
Liebe Grüße
// Nachtrag
Die Bilder verschieben sich leider, Sorry
So der host wurde neugestartet und scheint erstmal wieder zu laufen.
Die Windows VM rennt auch wieder.
Die SSD mit den VM's hatte/hat noch 103 GB Frei, RAM waren auch noch so 8GB von 80GB frei, Prozessor war so zu 60-70 % ausgelastet, was aber normal ist.
Die SSH Console des Hosts nimmt jetzt auch wieder befehle entgegen.
Achso und nein, der Host hat keine VM angehalten, die zwei Windows Maschinen sind hart weggeknallt
Warte mal, ich nutze "vmkfstools" um die Festplatten hart mit der VM zu verbinden.
Also in SSH "vmkfstools -z /vmfs/devices/disks/t10.ATA_____Festplatten_______ID /vmfs/volumes/datastore1/vmdk/Festplatten_ID.vmdk", diese zeigt ja auf die datastore1 SSD, also die vom Host Boot SSD.
Werden alle Bytes einmal auf die vom Host SSD und dann auf die richtige Fesplatte geschrieben?
Wenn ja, habe ich das problem gefunden....
Werde das ganze mal auf eine andere SSD verschieben.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4565191304
Url: https://administrator.de/forum/esxi-7-hauptspeicher-nicht-erreichbar-4565191304.html
Ausgedruckt am: 22.12.2024 um 09:12 Uhr
12 Kommentare
Neuester Kommentar
Moin,
ESXi, genau wie Windows, hyper-V, Linux, etc, ist empfindlich was die Storages angeht.
Wenn ein Storage nicht mehr sauber funktioniert kommt es zu all den von Dir beschriebenen Symptomen.
Das kann sowohl an SSD/HDD, Kabeln, Mainboard, BIOS, Netzteil liegen.
Auch eine neue SSD kann nach 1 Tag kaputt gehen.
Dafür gibt es RAID oder Ersaztmodelle.
Ich verwende bei kleinen Kunden WD Green 120GB M2 SATA SSDs für ESXi zum booten.
Darauf passiert ja nichts. Früher viel mit USB Sticks oder SD-Karten. Damit hatte ich nie Probleme.
Außerdem gibt es Backups wenn mal was kaputt geht.
Austauschen, ggf. Backup einspielen, fertig.
Wenn Du Zeit hast, kannst Du den Fehler ja suchen gehen.
Stefan
ESXi, genau wie Windows, hyper-V, Linux, etc, ist empfindlich was die Storages angeht.
Wenn ein Storage nicht mehr sauber funktioniert kommt es zu all den von Dir beschriebenen Symptomen.
Das kann sowohl an SSD/HDD, Kabeln, Mainboard, BIOS, Netzteil liegen.
Auch eine neue SSD kann nach 1 Tag kaputt gehen.
Dafür gibt es RAID oder Ersaztmodelle.
Ich verwende bei kleinen Kunden WD Green 120GB M2 SATA SSDs für ESXi zum booten.
Darauf passiert ja nichts. Früher viel mit USB Sticks oder SD-Karten. Damit hatte ich nie Probleme.
Außerdem gibt es Backups wenn mal was kaputt geht.
Austauschen, ggf. Backup einspielen, fertig.
Wenn Du Zeit hast, kannst Du den Fehler ja suchen gehen.
Stefan
Grade ESXi macht ja kaum was auf dem eigenen Storage, es reicht also ein wirklich schlichtes, kleines, und auch langsames Storage, es sollten aber natürlich keine VMs drauf liegen.
Du schreibst aber gar nichts zur Hardware, welche SSD? Was ist das für ein Server? Reden wir hier über einen Eigenbau oder was mit Kompatibilitätslisten oder eventuell Hardware Support?
Du schreibst aber gar nichts zur Hardware, welche SSD? Was ist das für ein Server? Reden wir hier über einen Eigenbau oder was mit Kompatibilitätslisten oder eventuell Hardware Support?
Die Bilder verschieben sich leider, Sorry
Nein. Du hast es leider versäumt die FAQs zu lesen! Ansonsten wäre dir nicht entgangen bei eingebetteten Bilder das „+“ zu klicken an der Stelle im Kontext wo die Bilder hinsollen.So werden sie lediglich am Ende des Threads ohne jeden Textbezug angefügt.
Aber du hast ja immer den „Bearbeiten“ Knopf um diesen Fauxpas auch nachträglich noch zu korrigieren. 😉
Moin Moin Stefan,
okay, ja ich hoffe nicht das mir die SSD kaputt gegangen ist.
Ja, von einem Hardware-Raid schaue ich im moment wieder ab, da ich zur Configuration den Host neustarten müsste.
Ich mache mir lieber ein Software Raid mit ZFS. (Auf dem Linux FileShare)
Okay, klar beim OS vom Host wäre es villeicht noch sinnvoll, aber zur not habe ich ein Backup der Config und die VM's auf anderen Platten. (Backups von den VM's auch nochmals auf anderen Medien, welche nicht immer Online sind. Falls Hackerangriff, Virus, Bedienerfehler etc.)
Ich habe schon gemerkt das ESXi's sehr anfällig für Festplatten oder RAM Fehler sind, hatte dieses Jahr schon so viele purple screen of death.
Okay, ja von USB-A Sticks bin ich weg, da mir diese nach ein paar Jahren (glaube 5) dann abgehauen sind.
Ich habe mit Festplatten ein besseres gefühl, da kann ich mir wenigstens noch die SMART Daten ausgeben lassen.
Ich werde beim nächsten Shutdown des host mal die SSD in eine Linux machine tun und die SMART Daten auslesen, hoffe aber das er erstmal wieder läuft.
Ja genau, Backups sind immer gut!
Falls der Fehler nochmals auftritt, werde ich der Sache mal auf den Grund gehen.
Liebe Grüße
Zitat von @StefanKittel:
ESXi, genau wie Windows, hyper-V, Linux, etc, ist empfindlich was die Storages angeht.
Wenn ein Storage nicht mehr sauber funktioniert kommt es zu all den von Dir beschriebenen Symptomen.
ESXi, genau wie Windows, hyper-V, Linux, etc, ist empfindlich was die Storages angeht.
Wenn ein Storage nicht mehr sauber funktioniert kommt es zu all den von Dir beschriebenen Symptomen.
Auch eine neue SSD kann nach 1 Tag kaputt gehen.
Dafür gibt es RAID oder Ersaztmodelle.
Dafür gibt es RAID oder Ersaztmodelle.
okay, ja ich hoffe nicht das mir die SSD kaputt gegangen ist.
Ja, von einem Hardware-Raid schaue ich im moment wieder ab, da ich zur Configuration den Host neustarten müsste.
Ich mache mir lieber ein Software Raid mit ZFS. (Auf dem Linux FileShare)
Okay, klar beim OS vom Host wäre es villeicht noch sinnvoll, aber zur not habe ich ein Backup der Config und die VM's auf anderen Platten. (Backups von den VM's auch nochmals auf anderen Medien, welche nicht immer Online sind. Falls Hackerangriff, Virus, Bedienerfehler etc.)
Ich habe schon gemerkt das ESXi's sehr anfällig für Festplatten oder RAM Fehler sind, hatte dieses Jahr schon so viele purple screen of death.
Ich verwende bei kleinen Kunden WD Green 120GB M2 SATA SSDs für ESXi zum booten.
Darauf passiert ja nichts. Früher viel mit USB Sticks oder SD-Karten. Damit hatte ich nie Probleme.
Darauf passiert ja nichts. Früher viel mit USB Sticks oder SD-Karten. Damit hatte ich nie Probleme.
Okay, ja von USB-A Sticks bin ich weg, da mir diese nach ein paar Jahren (glaube 5) dann abgehauen sind.
Ich habe mit Festplatten ein besseres gefühl, da kann ich mir wenigstens noch die SMART Daten ausgeben lassen.
Ich werde beim nächsten Shutdown des host mal die SSD in eine Linux machine tun und die SMART Daten auslesen, hoffe aber das er erstmal wieder läuft.
Außerdem gibt es Backups wenn mal was kaputt geht.
Austauschen, ggf. Backup einspielen, fertig.
Wenn Du Zeit hast, kannst Du den Fehler ja suchen gehen.
Austauschen, ggf. Backup einspielen, fertig.
Wenn Du Zeit hast, kannst Du den Fehler ja suchen gehen.
Ja genau, Backups sind immer gut!
Falls der Fehler nochmals auftritt, werde ich der Sache mal auf den Grund gehen.
Liebe Grüße
Moin Moin,
alles klar.
Ja, ne, hatte dazu wenig geschrieben, da sich sonst die meisten gedacht hätten, dass dat eh nicht funktionieren kann, da es selbstbau ist.
CPU: AMD Ryzen 7 2700X - Stabil Übertaktet auf 4,20 GHz (läuft knapp ein Jahr, auch dauer benchmark kein Problem)
RAM: 2x Corsair DIMM 32GB 3600 MHz 2x Corsair DIMM 8GB 3600 MHz
SSD vom Host: Samsung 980 PCIe M.2 SSD - 500 GB
HDD's die virtuell auf der SSD vom Host waren durch "vmkfstools -z" und dann auf die Linux FileShare VM hard eingebunden wurden: 2x Seagate Exos X10 ST10000NM0016 10TB Enterprise 7.2K 256MB 3.5
(Es gibt noch mehr HDD's aber das würde hier den Rahmen sprengen)
Mainboard: ASUS ROG STRIX B450-F GAMING Gen 1
Netzteil: 700 W Thermaltake
Grafikkarte: ASUS NVIDIA GeForce GT710 (Man ist die Teuer geworden, hatte die damals MEINE ICH für 70€ bekommen, kann ich mir aber iwi nicht mehr vorstellen)
Liebe Grüße
Zitat von @ukulele-7:
Grade ESXi macht ja kaum was auf dem eigenen Storage, es reicht also ein wirklich schlichtes, kleines, und auch langsames Storage, es sollten aber natürlich keine VMs drauf liegen.
Grade ESXi macht ja kaum was auf dem eigenen Storage, es reicht also ein wirklich schlichtes, kleines, und auch langsames Storage, es sollten aber natürlich keine VMs drauf liegen.
alles klar.
Du schreibst aber gar nichts zur Hardware, welche SSD? Was ist das für ein Server? Reden wir hier über einen Eigenbau oder was mit Kompatibilitätslisten oder eventuell Hardware Support?
Ja, ne, hatte dazu wenig geschrieben, da sich sonst die meisten gedacht hätten, dass dat eh nicht funktionieren kann, da es selbstbau ist.
CPU: AMD Ryzen 7 2700X - Stabil Übertaktet auf 4,20 GHz (läuft knapp ein Jahr, auch dauer benchmark kein Problem)
RAM: 2x Corsair DIMM 32GB 3600 MHz 2x Corsair DIMM 8GB 3600 MHz
SSD vom Host: Samsung 980 PCIe M.2 SSD - 500 GB
HDD's die virtuell auf der SSD vom Host waren durch "vmkfstools -z" und dann auf die Linux FileShare VM hard eingebunden wurden: 2x Seagate Exos X10 ST10000NM0016 10TB Enterprise 7.2K 256MB 3.5
(Es gibt noch mehr HDD's aber das würde hier den Rahmen sprengen)
Mainboard: ASUS ROG STRIX B450-F GAMING Gen 1
Netzteil: 700 W Thermaltake
Grafikkarte: ASUS NVIDIA GeForce GT710 (Man ist die Teuer geworden, hatte die damals MEINE ICH für 70€ bekommen, kann ich mir aber iwi nicht mehr vorstellen)
Liebe Grüße
Moin Moin,
Ja, das stimmt.
Ich muss zu meiner Verteidigung sagen, dass ich den Link dahinter gepackt habe, also "[bild 4] domain.tld/images/....." wie es unten beim Posten einer Nachricht stand.
Alles klar, werde mir mal die FAQs durchlesen und sie beim nächsten Post benutzen, ich gebe mein bestes.
Liebe Grüße
Zitat von @aqui:
So werden sie lediglich am Ende des Threads ohne jeden Textbezug angefügt.
Aber du hast ja immer den „Bearbeiten“ Knopf um diesen Fauxpas auch nachträglich noch zu korrigieren. 😉
Die Bilder verschieben sich leider, Sorry
Nein. Du hast es leider versäumt die FAQs zu lesen! Ansonsten wäre dir nicht entgangen bei eingebetteten Bilder das „+“ zu klicken an der Stelle im Kontext wo die Bilder hinsollen.So werden sie lediglich am Ende des Threads ohne jeden Textbezug angefügt.
Aber du hast ja immer den „Bearbeiten“ Knopf um diesen Fauxpas auch nachträglich noch zu korrigieren. 😉
Ja, das stimmt.
Ich muss zu meiner Verteidigung sagen, dass ich den Link dahinter gepackt habe, also "[bild 4] domain.tld/images/....." wie es unten beim Posten einer Nachricht stand.
Alles klar, werde mir mal die FAQs durchlesen und sie beim nächsten Post benutzen, ich gebe mein bestes.
Liebe Grüße
Zitat von @ButterBot:
Ich habe schon gemerkt das ESXi's sehr anfällig für Festplatten oder RAM Fehler sind, hatte dieses Jahr schon so viele purple screen of death.
? Ich nutze schon seit über 10 Jahren ESXi auf Fujitsu Severn, Workstations und normalen PCs.Ich habe schon gemerkt das ESXi's sehr anfällig für Festplatten oder RAM Fehler sind, hatte dieses Jahr schon so viele purple screen of death.
Ich hatte orginal 3 purple screen of death.
2 wegen eines defekten RAM Moduls kurz hintereinander (was das IPMI schon angezeigt hatte) und 1 mal aus unbekannten Gründen. Grundsätzlich läuft ESXi viel stabiler als Windows. Nur die Linux-Web-Server sind vergleichbar.
Ach ja, ESXi ist ja im Prinzip ein Linux
Ich habe hier bei einem exKunden einen uralten ESXi (ca. 9 Jahre alt). Aktuelle Laufzeit 1.250 Tage seit dem letzten Reboot.
Moin Moin,
Bei mir hatte es sich auf den Speziellen Host bezogen, da dies ein selbstgebautes System ist, welches weder von VMWare noch von Seiten des Herstellers dafür vorgesehen war.
Ich habe 3600 MHz Ram verbaut, jedoch läuft er standardmäßig mit 2400 MHz und jetzt übertatet auf 2755Mhz oder so.
Er lief mal für knapp eine Woche mit 2800MHz, danach ist er aber immer abgestürzt, also genau nach einer Woche.
Kann ich nicht nachvollziehen aber mit 2755 MHz oder so läuft er.
Davor hatte ich eine defekte Platte, welche sich verabschiedet hatte, also sie konnte Daten nicht mehr ordnungsgemäß speichern.
Die SMART Daten waren auch sehr schlecht.
(Monate davor)
Dann hatte ich versucht eine Virtuelle macOS Maschine auf einem AMD Prozessor in betrieb zu nehmen, da fand er das tiefe eingreifen in ESXi durch verschiedenste Patcher nicht lustig.
Da macOS normalerweise auf Intel Prozessoren läuft. (Ja jetzt auch auf ARM)
Da ich dann den Host eh neuinstallierten musste, dachte mir, komm probiere ich mal ESXi 8 aus.
ESXi 8 war aber doch noch zu neu, so das mir der Host alle paar Tage wieder abgeschmiert ist.
Ich konnte nicht einmal die Config eines Hostel öffnen......
Ja, dann hatte er noch Probleme mit einem BIOS Update, da lief er beim Booten immer wieder auf Fehler. (Kein purple screen of death aber erzähle trotzdem mal davon)
Nach ein bisschen Recherche hatte ich gelesen, das es etwas mit dem Secure Boot und TPM Aufsich hat, leider waren die Einstellungen aber alle richtig und hatte keine Zeit mehr investiert und bin einfach eine BIOS Version zurück gegangen.
War am Ende immer noch ein Upgrade, da dass BIOS vor der ganzen Aktion noch den Auslieferungszustand hatte, von 2017 meine ich.
Sonst noch so Kleinigkeiten neben bei, die einem den Kopf explodieren lassen. (Fehlerhafte NIC von Intel ....)
Ja, das ESXi prinzipiell Linux ist, habe ich auch schon bei der SSH Verbindung zum host gemerkt.
Da kann man dann schöne Sachen Skripten.
Bei meinen Linux VM's hatte ich bisher noch keine Probleme, empfand die bisher um längen stabiler als Windows.
IPMI, IDRAC oder IMM hat das ASUS Mainboard leider nicht, da es für solche zwecke nicht entworfen wurde.
Ich habe auf dem System ESXi installiert, da der Rechner noch bei mir rumflog und ich so in meinem Büro einen Host habe, der mit Wasser Kühlung leise läuft, weniger Stromverbraucht und ich dafür wieder einen nutzen habe.
Aber bei meinen Rack Servern wird mir das auch rechtzeitig durch IMM angezeigt, habe sogar noch einen ganz alten IBM Server.
Das ist erstaunlich, auch im Hinblick auf Stromausfälle.
[Etwas nutzlos die Info aber:]
Der Host läuft jetzt erstmal wieder, stolze 3,9 Tage.
Denke dass die NVME SSD vielleicht nicht richtigen Kontakt hatte, fett, staub.... wer weiß das schon.
Beim nächsten Fail schaue ich mir aber trotzdem die SMART Daten an.
Liebe Grüße
Zitat von @StefanKittel:
? Ich nutze schon seit über 10 Jahren ESXi auf Fujitsu Severn, Workstations und normalen PCs.
Ich hatte orginal 3 purple screen of death.
? Ich nutze schon seit über 10 Jahren ESXi auf Fujitsu Severn, Workstations und normalen PCs.
Ich hatte orginal 3 purple screen of death.
Bei mir hatte es sich auf den Speziellen Host bezogen, da dies ein selbstgebautes System ist, welches weder von VMWare noch von Seiten des Herstellers dafür vorgesehen war.
Ich habe 3600 MHz Ram verbaut, jedoch läuft er standardmäßig mit 2400 MHz und jetzt übertatet auf 2755Mhz oder so.
Er lief mal für knapp eine Woche mit 2800MHz, danach ist er aber immer abgestürzt, also genau nach einer Woche.
Kann ich nicht nachvollziehen aber mit 2755 MHz oder so läuft er.
Davor hatte ich eine defekte Platte, welche sich verabschiedet hatte, also sie konnte Daten nicht mehr ordnungsgemäß speichern.
Die SMART Daten waren auch sehr schlecht.
(Monate davor)
Dann hatte ich versucht eine Virtuelle macOS Maschine auf einem AMD Prozessor in betrieb zu nehmen, da fand er das tiefe eingreifen in ESXi durch verschiedenste Patcher nicht lustig.
Da macOS normalerweise auf Intel Prozessoren läuft. (Ja jetzt auch auf ARM)
Da ich dann den Host eh neuinstallierten musste, dachte mir, komm probiere ich mal ESXi 8 aus.
ESXi 8 war aber doch noch zu neu, so das mir der Host alle paar Tage wieder abgeschmiert ist.
Ich konnte nicht einmal die Config eines Hostel öffnen......
Ja, dann hatte er noch Probleme mit einem BIOS Update, da lief er beim Booten immer wieder auf Fehler. (Kein purple screen of death aber erzähle trotzdem mal davon)
Nach ein bisschen Recherche hatte ich gelesen, das es etwas mit dem Secure Boot und TPM Aufsich hat, leider waren die Einstellungen aber alle richtig und hatte keine Zeit mehr investiert und bin einfach eine BIOS Version zurück gegangen.
War am Ende immer noch ein Upgrade, da dass BIOS vor der ganzen Aktion noch den Auslieferungszustand hatte, von 2017 meine ich.
Sonst noch so Kleinigkeiten neben bei, die einem den Kopf explodieren lassen. (Fehlerhafte NIC von Intel ....)
2 wegen eines defekten RAM Moduls kurz hintereinander (was das IPMI schon angezeigt hatte) und 1 mal aus unbekannten Gründen. Grundsätzlich läuft ESXi viel stabiler als Windows. Nur die Linux-Web-Server sind vergleichbar.
Ach ja, ESXi ist ja im Prinzip ein Linux
Ach ja, ESXi ist ja im Prinzip ein Linux
Ja, das ESXi prinzipiell Linux ist, habe ich auch schon bei der SSH Verbindung zum host gemerkt.
Da kann man dann schöne Sachen Skripten.
Bei meinen Linux VM's hatte ich bisher noch keine Probleme, empfand die bisher um längen stabiler als Windows.
IPMI, IDRAC oder IMM hat das ASUS Mainboard leider nicht, da es für solche zwecke nicht entworfen wurde.
Ich habe auf dem System ESXi installiert, da der Rechner noch bei mir rumflog und ich so in meinem Büro einen Host habe, der mit Wasser Kühlung leise läuft, weniger Stromverbraucht und ich dafür wieder einen nutzen habe.
Aber bei meinen Rack Servern wird mir das auch rechtzeitig durch IMM angezeigt, habe sogar noch einen ganz alten IBM Server.
Ich habe hier bei einem exKunden einen uralten ESXi (ca. 9 Jahre alt). Aktuelle Laufzeit 1.250 Tage seit dem letzten Reboot.
Das ist erstaunlich, auch im Hinblick auf Stromausfälle.
[Etwas nutzlos die Info aber:]
Der Host läuft jetzt erstmal wieder, stolze 3,9 Tage.
Denke dass die NVME SSD vielleicht nicht richtigen Kontakt hatte, fett, staub.... wer weiß das schon.
Beim nächsten Fail schaue ich mir aber trotzdem die SMART Daten an.
Liebe Grüße
Also Dinge wie übertakten würde ich bei einem Serversystem nicht machen wollen aber ich denke hier liegt das Problem wirklich eher am Speicher selbst oder am Controller. Also auf jeden Fall Firmware aktuell machen und ggf. einfach mal einen anderen Speicher als Boot Laufwerk probieren, so wählerisch ist ESXi nicht.
1
Moin
Ja, ich weiß, das ist auch der einziger Server den ich Übertakte.
Nachdem ich den Host runtergefahren und die SSD erneut sauber eingebaut habe, von den Physikalischen Festplatten die Virtuelle .vmdk für die harte Einbindung auf einer anderen Platte erstellt habe, läuft er jetzt wieder problemlos.
Fast 10 Tage ohne Fehler.
Ich hätte noch eine kleine Frage:
Ich habe einen Festplatten Controller wo ich manche Platten nur kurzzeitig für Backups anschließe.
Also wird eine Festplatte für knapp zwei Tage angeschlossen, wieder hard an eine VM angebunden, Backup draufgespielt und danach wieder alles getrennt.
Ist das für VMware ESXi ein Problem?
Da ich immer eine Warnung bekomme, dass die Platte nicht mehr erreichbar ist und danach die Meldung das sie anscheinend entfernt wurde.
Sonst müsste ich mir eine alternative suchen, einen kleinen Pi mit USB Festplatten Dock etc. für HOT-Swap Backups. So dass ich auch Offline Backups habe....
Dann würde ich das einfach vom FileShare über SSH oder gleich mit rsync die Daten übertragen.
Liebe Grüße
Zitat von @ukulele-7:
Also Dinge wie übertakten würde ich bei einem Serversystem nicht machen wollen aber ich denke hier liegt das Problem wirklich eher am Speicher selbst oder am Controller. Also auf jeden Fall Firmware aktuell machen und ggf. einfach mal einen anderen Speicher als Boot Laufwerk probieren, so wählerisch ist ESXi nicht.
Also Dinge wie übertakten würde ich bei einem Serversystem nicht machen wollen aber ich denke hier liegt das Problem wirklich eher am Speicher selbst oder am Controller. Also auf jeden Fall Firmware aktuell machen und ggf. einfach mal einen anderen Speicher als Boot Laufwerk probieren, so wählerisch ist ESXi nicht.
Ja, ich weiß, das ist auch der einziger Server den ich Übertakte.
Nachdem ich den Host runtergefahren und die SSD erneut sauber eingebaut habe, von den Physikalischen Festplatten die Virtuelle .vmdk für die harte Einbindung auf einer anderen Platte erstellt habe, läuft er jetzt wieder problemlos.
Fast 10 Tage ohne Fehler.
Ich hätte noch eine kleine Frage:
Ich habe einen Festplatten Controller wo ich manche Platten nur kurzzeitig für Backups anschließe.
Also wird eine Festplatte für knapp zwei Tage angeschlossen, wieder hard an eine VM angebunden, Backup draufgespielt und danach wieder alles getrennt.
Ist das für VMware ESXi ein Problem?
Da ich immer eine Warnung bekomme, dass die Platte nicht mehr erreichbar ist und danach die Meldung das sie anscheinend entfernt wurde.
Gerät t10.ATA_____ST4000DM0042D2U9104__________________________________ZTT5C9Z4 wurde entfernt oder es ist dauerhaft kein Zugriff darauf möglich. Betroffene Datenspeicher (sofern zutreffend): Unknown.Sonst müsste ich mir eine alternative suchen, einen kleinen Pi mit USB Festplatten Dock etc. für HOT-Swap Backups. So dass ich auch Offline Backups habe....
Dann würde ich das einfach vom FileShare über SSH oder gleich mit rsync die Daten übertragen.
Liebe Grüße
Also Erfahrung habe ich da keine aber außer Fehlermeldungen glaube ich nicht das ESXi ein Problem damit hat.
Hast du die VMware Tools in der VM eingerichtet? Es gibt einen Parameter devices.hotplug in der Config der VM unter
Erweitert \ Konfigurationsparameter \ Konfiguration bearbeiten \ Konfigurationsparameter hinzufügen
Ich weiß nur das mir unter Win 2012R2 die HDDs immer zum Auswurf angeboten wurden, daher habe ich den auf FALSE stehen Eventuell kannst du Hotplug mit dem Controller in die VM weiter reichen...
Hast du die VMware Tools in der VM eingerichtet? Es gibt einen Parameter devices.hotplug in der Config der VM unter
Erweitert \ Konfigurationsparameter \ Konfiguration bearbeiten \ Konfigurationsparameter hinzufügen
Ich weiß nur das mir unter Win 2012R2 die HDDs immer zum Auswurf angeboten wurden, daher habe ich den auf FALSE stehen
Eventuell kannst du Hotplug mit dem Controller in die VM weiter reichen...
Hallo,
wenn eine USB HDD reicht, wäre das viel einfacher.
Du kannst ja USB Geräte im ESXi einer VM zuweisen.
Aber ein echtes Problem ist diese Meldung nicht.
Stefan
wenn eine USB HDD reicht, wäre das viel einfacher.
Du kannst ja USB Geräte im ESXi einer VM zuweisen.
Aber ein echtes Problem ist diese Meldung nicht.
Stefan
