Jun 23, 2020

5687

VMWare VM sehr langsam, Dateisystem nicht aufrufbar

Guten Abend zusammen,

wir haben bei zwei VMs in einem Cluster bereits Probleme mit den vmdks...
Das Problem zeichnet sich dahingehend aus, dass man das Dateisystem nur sehr langsam durchsuchen kann (als wäre es eine Diskette), oder (so wie heute) gar nicht mehr aufrufen kann und der explorer von Windows abschmiert. Es sind beides Windows Server 2012 R2 VMs. Die Datenträgerverwaltung lies sich auch nicht öffnen..

Als ich dann heute die VM auf ein Snapshot von gestern zurück gesetzt hatte, war alles wieder normal.

Im Einsatz sind drei ESXi Hosts von IBM in einem Cluster mit dem vCenter 5.(4??) (also nicht das aktuellste und noch mit der Standalone Application, nicht die im Browser). Als Speicher ist ein zentraler SAN von IBM im Einsatz.

Was ich schon gemacht/geschaut habe:
- Im IBM SAN ob ich SMART Werte oder irgendwas sehen kann - war leider nicht der Fall.
- Die vmdk auszuhängen und wieder einzuhängen

Hat jemand mal ein selbes Problem gehabt? Bin leider nicht der VMWare Typ und weiß nicht wie ich technisch weiterfahren soll, außer jetzt den Support von IBM und VMWare zu kontaktieren.

Ich freue mich über eure Antworten und Ideen!

Viele Grüße
Adrian Rodriguez

Please also mark the comments that contributed to the solution of the article

Content-Key: 581336

Url: https://administrator.de/contentid/581336

Printed on: April 26, 2024 at 09:04 o'clock

12 Comments

Latest comment

Hi,

Du könntest mal in die Logs schauen, ob dort irgendwelche detaillierteren Fehler/Warnungen auftauchen. Ohne detailliertere Angaben kann man da nur ins blaue raten, auf einem Produktivsystem eher ungünstig und außerdem bringt Dich das dann auch nicht weiter. Da Du aber ehrlicherweise gesagt hast, dass Du Dich mit VMWare nicht so gut auskennst, würde ich doch eher empfehlen, den IBM und/oder VMWare-Support hinzuzuziehen. Einen Supportvertrag habt ihr ja sicherlich.

Gruß

cykes

Vielen Dank für deine Antwort.
Einen Supportvertrag haben wir leider nicht, da wir alles andere mit Hyper-V machen..

Ich werde mir mal die Logs anschauen..

Zitat von @ADRNEX:
Vielen Dank für deine Antwort.
Einen Supportvertrag haben wir leider nicht, da wir alles andere mit Hyper-V machen..

Dann wird das aber teuer. Warum setzt ihr für die VMs dann noch VMWare ein? Ich würde den Supportaufwand vielleicht mal mit einer Hyper-V-Migration gegenrechnen. Persönlich bevorzuge ich allerdings VMWare, aber eine Mischumgebung ist eher kontraproduktiv, auch aus Wartungssicht, wie man ja an der veralteten Version sieht. Ggf. ist es da einfach effektiver, wenn man VMWare abschafft.

Ich werde mir mal die Logs anschauen..

Kannst auch Auffälligkeiten gern hier posten, aber eine Fernanalyse ist eher schwierig. Kann auch durch ein Treiberupdate (Netzwerkkarte, Controller usw.) hervorgerufen worden sin, oder es liegen zu viele Snapshots bei den VMs- bitte aber jetzt nicht blindlinks irgendwas machen und vor allem nicht ohne jemanden, der sich damit auskennt.

Gruß

cykes

Also an sich kann ich damit umgehen (mit VMWare) und verstehe das Grundlegende. Snapshots waren nur zwei da (einer zum Glück von gestern). Das Ganze ist auch zum Glück keine Mischumgebung. Diese VMWare Installation ist eine eigenständige Umgebung.

Das Problem wird leider das Geld sein für den Umzug... In den Logs habe ich aber nichts auffälliges gefunden, außer dass er meckert dass die VMWare Tools nicht installiert sind (obwohl sie es sind).

Ich habe einfach nach "error" gesucht und nichts gefunden..

Die Frage die ich mir halt stelle ist: Warum war das letztens bei der einen Exchange VM so und nun bei dem FileServer?
Obwohl wir bei der Exchange VM die Dateien noch durchsuchen konnten.

Und am Rande zum Exchange:
Da war nur eine vmdk betroffen, auf der die edb lag. Wir haben dann eine neue vmdk erstellt und diese eingebunden und dann die edb verschoben. Danach funktionierte der Exchange wieder. Bei dem FileServer wäre das bei ca. 3TB nicht so schnell möglich gewesen...

Ich finde das Verhalten irgendwie komisch und für mich fühlt es sich an wie eine kaputte Festplatte im RAID, aber in der SAN Oberfläche kann man keine Health-Werte einsehen.

Im Einsatz ist übrigens ein IBM storwize v3700.

Langfristig kommen da hoffentlich neue Bleche hin, die ich dann direkt auf Hyper-V aufbaue...

Zitat von @ADRNEX:

Also an sich kann ich damit umgehen (mit VMWare) und verstehe das Grundlegende. Snapshots waren nur zwei da (einer zum Glück von gestern). Das Ganze ist auch zum Glück keine Mischumgebung. Diese VMWare Installation ist eine eigenständige Umgebung.

Troubleshooting ist schon etwas komplexer und das übt man nicht an einer Produktivkiste, im schlimmsten Fall geht nachher gar nichts mehr.

Warum war denn da ein Snapshot auf der Kiste, hat vielleicht irgendwer etwas verändert? Habt ihr kein Backup? Falls doch, dann einfach mal ne komplett neue VM aus dem Backup erstellen. Ist auch gleich ein guter DR-Test.

Das Problem wird leider das Geld sein für den Umzug...

Ich glaube fast, dass Du keine Vorstellung von den Supportpreisen bei VMWare und/oder IBM hast. Deine Arbeitszeit kommt auch noch hinzu und wenn das zum 2nd/3rd Level weitergereicht werden muss, darfst Du nochmal $$$$ einwerfen.So ein Anlage ohne Suppertverträge zu betreiben, ist schon fast fahrlässig.

Wurde denn wenigtens das Storage mal gewartet? Hast Du mal dort in die Logs geschaut. Ist der CIM-Provider dafür unter VMWare installiert?
Vgl. https://www.ibm.com/support/knowledgecenter/STVLF4_8.2.1/spectrum.virtua ... und auch die Warnung hier: https://www.ibm.com/support/pages/what-data-should-you-collect-problem-s ...

Auch hier: nich einfach mal loslegen und dann später im Desaster enden.

In den Logs habe ich aber nichts auffälliges gefunden, außer dass er meckert dass die VMWare Tools nicht installiert sind (obwohl sie es sind).

Das würde ich aber schon als auffällig bezeichnen, laufen die Tools auch? Das ist schon mal ein Ansatzpunkt für eine Recherche.

Ich habe einfach nach "error" gesucht und nichts gefunden..

Das ist zu oberflächlich, das Problem liegt vermutlich tiefer und ist - wiederum vermutlich - ein Folgeproblem. Irgendwas passiert und in der Folge kommen die Zugriffsprobleme. Könnte bspw. auch der path zum Storage abschmieren, was wiederuim unterschiedliche Gründe haben kann.

Die Frage die ich mir halt stelle ist: Warum war das letztens bei der einen Exchange VM so und nun bei dem FileServer?
Obwohl wir bei der Exchange VM die Dateien noch durchsuchen konnten.

Dann noch die Gemeinsamkeiten herausfinden.
usw. usf. - da gehen schon für Deine Suche $$$$ drauf

Und am Rande zum Exchange:
Da war nur eine vmdk betroffen, auf der die edb lag. Wir haben dann eine neue vmdk erstellt und diese eingebunden und dann die edb verschoben. Danach funktionierte der Exchange wieder. Bei dem FileServer wäre das bei ca. 3TB nicht so schnell möglich gewesen...

Mal Kabel zum Storage checken, vielleicht spinnt auch ein Switch - vielleicht usw. usf. (und schon ist das nächste Woichende draufgegangen)

Ich finde das Verhalten irgendwie komisch und für mich fühlt es sich an wie eine kaputte Festplatte im RAID, aber in der SAN Oberfläche kann man keine Health-Werte einsehen.

Aber ganz sicher weitere Logfiles.

Langfristig kommen da hoffentlich neue Bleche hin, die ich dann direkt auf Hyper-V aufbaue...

Ich würde eher kurzfristig schätzen

Gruß

cykes

Moin,

Da war nur eine vmdk betroffen, auf der die edb lag. Wir haben dann eine neue vmdk erstellt und diese eingebunden und dann die edb verschoben. Danach funktionierte der Exchange wieder. Bei dem FileServer wäre das bei ca. 3TB nicht so schnell möglich gewesen...

hört sich für mich so an, als wäre entweder die Anbindung zwischen Server und Storage nicht ganz lupenrein. Ist der VMware Datastore, auf dem die VMDK Dateien des Exchange Servers liegen, via iSCSI an die Hosts angebunden? NFS ist nämlich nach wie vor unsupportet.

Alternativ einmal die Counter für Packetloss auf den Switches prüfen, ob dieser sich stündlich/täglich evtl. ändert. So könnte z.B. ein defektes Kabel oder Port die Ursache sein.

Parallel dazu mache einen Performance Support Case bei IBM. Somit hast die Gegenprobe zur Weboberfläche, ob wirklich alles in Ordnung ist.

Langfristig kommen da hoffentlich neue Bleche hin, die ich dann direkt auf Hyper-V aufbaue...

Dann bin ich gespannt, woher du den Support zauberst, wenn dort ein Fehler durch Windows Updates oder einfach im Betrieb auftaucht. Zudem ist das SCCM (für Cluster unausweilich) kein Schnäppchen, auch nicht einfach zu verstehen und umständlicher wie VMware VSCA.

Dann wird das aber teuer.

Davor muss erst einmal umfangreiche Aktualisierungen durchgeführt werden. Denn Support beginnt aktuell erst bei Version 6.5. Das wird vermutlich an der HCL scheitern...

Gruß,
Dani

Moin,

Schreibe mal bitte etwas mehr zur Hardware!

Welcher IBM Server genau? X3650 M4?
Den kannst du auch mit ESXi 6.5 laufen lassen.

Storage ist ja eine V3700. per se laufen die - trotz des Alters - gut.
Was für Platten sind verbaut?
Ein Update dürfte aufgrund fehlender Wartung nicht gelingen (dir fehlt der Zugang zur Datei).

Welches Protokoll läuft zwischen SAN und ESXi? FC oder iSCSI?

Und snapshots, die zu lange aktiv sind, können auch mächtig bremsen...

Gruß
em-pie

Servus,

check doch am besten mal die Statistikwerte ob sich die Storage-Latenz extrem verändert hat bzw. welche Werte das vCenter da so ausspuckt. Falls ja bzw. hohe Latenz hat es vermutlich was mit der Verbindung zum Storage zu tun. Danach mal checken ob es auf dem HBA bzw. Switch viele CRC-Error gibt ( defektes Kabel, GBIC). Bei defekter Hardware gibt VMware auch manchmal nur "Information" als Meldung aus.

Grüße
Pfiff

Danke für die zahlreichen Antworten!

Ich hatte zwar schon eine Antwort geschrieben, aber wohl nicht abgesendet.
Es handelt sich um 3x IBM X3650 M2
Die Hardware wurde gebraucht gekauft. Wir haben diese Infrastruktur einfach nur übernommen und sind gerade dabei erstmal aufzuräumen, weil auf allen VMs irgendwas läuft und keiner weiß was..

Jetzt halt dieses Problem.. Ich schaue mir auf jeden Fall mal die Latenzen an und auch die beiden Switche an denen das SAN hängt.

Ein Port scheint die ganze Zeit down und wieder up zu gehen. Dies ist aber nur ein Kupferkabel.. Trotzdem schon mal gut zu wissen, dann kann man das austauschen...

Die Latenzen zum Speicher liegen zwischen 0ms und 4ms, Durschnitt: 0,8ms

Ich habe sonst das Gefühl dass die Backupsoftware (NovaBackup), die auf einem Uralt Server läuft dort Probleme macht.
Die erstellt ja die Snapshots um diese dann zu sichern. Das Backup funktioniert vorne und hinten nicht und meist hatte ich kein Backup wenn eine VM mal abgeschmiert ist.
Was ist eure Meinung dazu?

Achso das SAN ist per FC verbunden

Nabend,

Zitat von @ADRNEX:
Ein Port scheint die ganze Zeit down und wieder up zu gehen. Dies ist aber nur ein Kupferkabel.. Trotzdem schon mal gut zu wissen, dann kann man das austauschen...

Das ist mir aber auch zu viel "scheint" usw.

Das kann auch mit einem fehlerhaften Treiber oder einer falschen Treiber/Firmware-Kombination zusammenhängen. Welcher Port ist außerdem gemeint (Switch oder NIC)?

Ich habe sonst das Gefühl dass die Backupsoftware (NovaBackup), die auf einem Uralt Server läuft

Noch älter als die

3x IBM X3650 M2

dort Probleme macht.

Das war auch eine meiner Vermutungen, wenn die Backupsoftware (ebenfalls uralte Version?) die Snapshots zwar erstellt, aber nach erfolgreichem Backup nicht mehr zuverlässig löscht, kommen solche Probleme durchaus vor.
Ich würde auf allen 3 Hosts erstmal sämtliche Treiberversionen und Firmwarestände vergleichen und ggf. angleichen.

Die erstellt ja die Snapshots um diese dann zu sichern. Das Backup funktioniert vorne und hinten nicht und meist hatte ich kein Backup wenn eine VM mal abgeschmiert ist.

Das zuerst fixen, ohne verlässliches Backup keinesfalls weiterbasteln. Die alte Backupkiste dekommisionieren (läuft ja eh nicht gescheit) und ggf. die Backups auf ein zusätzliches NAS laufen lassen. Die Snapshots auf jeden Fall mit Bedacht aufräumen. Und die Snapshot-Kette auf Konsistenz überprüfen, auch auf dem Exchange.

Was ist eure Meinung dazu?

Ehrliche Meinung: Der Aufwand wird monetär größer das zu fixen als das zu migrieren.
Zunächst braucht ihr erstmal einen ordentlich dokumentierten Ist-Zustand, ansonsten schraubst Du an der einen Stelle ein wenig rum und zwei (oder mehr) neue Baustellen tun sich auf.

Achso das SAN ist per FC verbunden

Auch da kann schon ein fehlerhaftes Treiberupdate für den Controller totales Chaos verursachen.

Gruß

cykes

Soo.
Backup soll auf Cloud umgestellt werden. Momentan läuft die Ist-Analyse. Es geht hierbei um einen übernommenen Kunden. Dieser weiß auch dass er investieren muss. Leider ist es aber so, dass wir erstmal aufräumen und alles vereinfachen sollen.

Das NovaBackup läuft auf einem Dell Server der sehr alt ist. Älter als die IBMs.

Mein Vorgehen wird jetzt kurzfristig sein: 1. Aufräumen und den einen physischen SBS als PDC ablösen, vorher dort die noch relevante Software auf die dafür vorgesehenen Application-Server bringen.

2. Danach das Cloud-Backup einsetzen + lokales Backup auf ein NAS oder auf Band.

Danach (bzw. zwischendrin) ein Angebot vorlegen für zwei neue Server die ich dann auf Hyper-V aufsetzen kann in einem Cluster (mit neuem SAN).

Das ganze so kurzfristig wie möglich. Ich habe mich jetzt dazu entschieden das Problem eher nicht zu identifizieren und einfach schnell die anderen physischen Server wegzubekommen, damit am Ende alles virtualisiert ist. Mal so als Idee: Da sind 3x 42HE 19 Zoll Schränke. Zwei davon sind voll mit physischen Servern, von denen ich hier (bis auf dem SBS und dem Backup-Server) noch nichts erzählt habe. In dem 3. sind halt die IBM Kisten mit SAN + USV. Also 2 Stück die voll sind mit Uralt-Infrastruktur die weg muss.

Danke auf jeden Fall für eure zahlreichen Ideen zur Problemlösung, aber das was die meisten hier sagen stimmt: Neu machen ins günstiger als da jetzt diesen Fehler zu eliminieren.....

Beste Grüße
Adrian Rodriguez

German Question VMware Virtualization