5
ESXI 5U1 - gruseliges Phänomen - Bei Euch nachstellbar?
--Edit: Wie sich herausstellte, liegt am Client (Quelle der kopierten Dateien) offenbar ein Hardwaredefekt vor. --
Grüß' Euch, Kollegen!
Ich bin seit anderthalb Jahren (Version 4.1) zufriedener ESXI-Nutzer. Mitterweile ESXI 5U1 und bis heute war alles toll.
Nun sollte auf einem (VM-)Testserver der SQL Server 2012 installiert werden und dabei fiel Erschreckendes auf.
Vorgehen:
-SQL 2012 Trial runtergeladen auf meinen eigenen Client und dann auf dem VMServer von meinem Client via Netzwerk lokal auf den Server kopiert - 3 Dateien, zusammen 2,4 GB.
-Sofort nach Abschluss des Kopierens das Setup gestartet - Resultat: Setup schlägt fehl: "Fehler beim Entpacken"
-Dateien nochmal kopiert, Setup sofort gestartet - Fehler beim Entpacken
-Setup auf meinem eigenen Rechner gestartet - kein Problem
-Dateien ein 3. Mal kopiert, Setup sofort gestartet - Fehler beim Entpacken!
-...eine Runde nachgedacht...
-Dateien ein letztes Mal kopiert, diesmal 2 minuten gewartet - geht!
Ergo: Ich vermute, dass ESXI der VM irgendwas als bereits auf die Platte kopiert angibt, obwohl das noch gar nicht der Fall ist. Die 2 Minuten Warten brachten auch in den Folgeversuchen Erfolg. Ebenso konnte das Problem mit einem anderen Setup (Office 2010, ca. 1 GB) reproduziert werden. Zu allem Überfluss verhielt es sich auf anderen VMs nicht anders!
Meine Frage: Kann es wohl sein, dass der Unterbau von ESXI ein Dateisystem hat (es ist VMFS5 http://en.wikipedia.org/wiki/VMware_VMFS ), das solche Probleme hat? Ext4 nutzt ja auch RAM zur Beschleunigung.
Habt Ihr sowas schonmal gehört/erlebt? Hat jemand Lust und Zeit dies nachzustellen?
PS: die Datenübertragung zum ESXI ist bei mir schnell, etwa 900MBit/s. Der Server ist neu und gesund, die Hardware ist von VMWare empfohlen.
PSPS: Hintergrund der Frage ist nicht nur Neugierde. Natürlich kann das vermutete "Feature" auch zu weitaus schlimmerem Ärger führen, denke ich.
Grüß' Euch, Kollegen!
Ich bin seit anderthalb Jahren (Version 4.1) zufriedener ESXI-Nutzer. Mitterweile ESXI 5U1 und bis heute war alles toll.
Nun sollte auf einem (VM-)Testserver der SQL Server 2012 installiert werden und dabei fiel Erschreckendes auf.
Vorgehen:
-SQL 2012 Trial runtergeladen auf meinen eigenen Client und dann auf dem VMServer von meinem Client via Netzwerk lokal auf den Server kopiert - 3 Dateien, zusammen 2,4 GB.
-Sofort nach Abschluss des Kopierens das Setup gestartet - Resultat: Setup schlägt fehl: "Fehler beim Entpacken"
-Dateien nochmal kopiert, Setup sofort gestartet - Fehler beim Entpacken
-Setup auf meinem eigenen Rechner gestartet - kein Problem
-Dateien ein 3. Mal kopiert, Setup sofort gestartet - Fehler beim Entpacken!
-...eine Runde nachgedacht...
-Dateien ein letztes Mal kopiert, diesmal 2 minuten gewartet - geht!
Ergo: Ich vermute, dass ESXI der VM irgendwas als bereits auf die Platte kopiert angibt, obwohl das noch gar nicht der Fall ist. Die 2 Minuten Warten brachten auch in den Folgeversuchen Erfolg. Ebenso konnte das Problem mit einem anderen Setup (Office 2010, ca. 1 GB) reproduziert werden. Zu allem Überfluss verhielt es sich auf anderen VMs nicht anders!
Meine Frage: Kann es wohl sein, dass der Unterbau von ESXI ein Dateisystem hat (es ist VMFS5 http://en.wikipedia.org/wiki/VMware_VMFS ), das solche Probleme hat? Ext4 nutzt ja auch RAM zur Beschleunigung.
Habt Ihr sowas schonmal gehört/erlebt? Hat jemand Lust und Zeit dies nachzustellen?
PS: die Datenübertragung zum ESXI ist bei mir schnell, etwa 900MBit/s. Der Server ist neu und gesund, die Hardware ist von VMWare empfohlen.
PSPS: Hintergrund der Frage ist nicht nur Neugierde. Natürlich kann das vermutete "Feature" auch zu weitaus schlimmerem Ärger führen, denke ich.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 190327
Url: https://administrator.de/forum/esxi-5u1-gruseliges-phaenomen-bei-euch-nachstellbar-190327.html
Ausgedruckt am: 14.04.2025 um 12:04 Uhr
5 Kommentare
Neuester Kommentar
Wie sich herausstellte, liegt am Client (Quelle der kopierten Dateien) offenbar ein Hardwaredefekt vor. Ich beschreib das Morgen mal in Ruhe, muss jetzt los.
Es bleibt seehr rätselhaft.
Nach vielem Rumprobieren war gestern ein Reboot des Clients die Lösung. Seitdem ist das Problem auf's Verrecken nicht mehr reproduzierbar. Gestern konnte ich bei dem kopieretn Setup auch inkorrekte Checksummen nachweisen (jedesmal eine andere), heute immer korrekt.
Speicher des Clients wurde ausgiebig geprüft - kein Befund. Mal sehen, wenn noch was nachkommt, melde ich das. Sieht jedenfalls nicht nach einem Problem von ESXI aus.
Dass das Warten zur Lösung geführt hat, war jedenfalls nur Zufall - ich hab es zwar 3 Mal mindestens so gemacht und Erfolg gehabt, beim 4. Mal jedoch war das Entacken auch dann nicht möglich. Dann habe ich mal vom Server zum Client kopiert - Checksummen immer korrekt. So kam ich auf ein clientseitiges Problem.
Nach vielem Rumprobieren war gestern ein Reboot des Clients die Lösung. Seitdem ist das Problem auf's Verrecken nicht mehr reproduzierbar. Gestern konnte ich bei dem kopieretn Setup auch inkorrekte Checksummen nachweisen (jedesmal eine andere), heute immer korrekt.
Speicher des Clients wurde ausgiebig geprüft - kein Befund. Mal sehen, wenn noch was nachkommt, melde ich das. Sieht jedenfalls nicht nach einem Problem von ESXI aus.
Dass das Warten zur Lösung geführt hat, war jedenfalls nur Zufall - ich hab es zwar 3 Mal mindestens so gemacht und Erfolg gehabt, beim 4. Mal jedoch war das Entacken auch dann nicht möglich. Dann habe ich mal vom Server zum Client kopiert - Checksummen immer korrekt. So kam ich auf ein clientseitiges Problem.
Wäre aber auch frech von dir gewesen, meine schöne heile VMware-Welt aus den Angeln zu reißen!
Vielleicht hat dein NIC-Treiber nicht sauber gearbeitet, wer weiß :/
Vielleicht hat dein NIC-Treiber nicht sauber gearbeitet, wer weiß :/
Ja. Ist bis dato nicht mehr aufgetreten - meine SMB-Serverkomponente hatte wohl einen schlechten Tag.
So, ist restlos aufgeklärt: die Netzwerkkarte war defekt und arbeitete unzuverlässig.
