5
VSwitch scheint nicht mehr zu arbeiten
Hallo,
ich habe ein VMware- System mit vSphere 5.1 und 3 Dell-Servern laufen. Ohne erkennbaren Grund (keine Updates, keine Konfigurationsänderungen usw) können die VM´s eines der 3 Server das Netzwerk nicht mehr erreichen. Weder kann man aus diesen VM´s einen anderen Netzwerkknoten anpingen, noch sind diese VM´s anpingbar. Der Zugriff über das Management (vSphere-Client) ist problemlos möglich. Ich habe den betreffenden Server in den Wartungsmodus versetzt, alle VM´s verschoben und ihn neu gestartet. Danach 2 VM´s zurück kopiert und gestartet. Keine Änderung.
Es werden keine Fehler oder Warnungen angezeigt. Bis Gestern zum Feierabend gab es keine Probleme, Heute Morgen trat der beschriebene Effekt auf.
Da keine Updates installiert wurden und die Konfiguration nicht geändert wurde, weiß ich nicht, wo ich bei der Fehlersuche ansetzen soll.
Bin für jeden Tipp dankbar.
MfG
Jürgen
ich habe ein VMware- System mit vSphere 5.1 und 3 Dell-Servern laufen. Ohne erkennbaren Grund (keine Updates, keine Konfigurationsänderungen usw) können die VM´s eines der 3 Server das Netzwerk nicht mehr erreichen. Weder kann man aus diesen VM´s einen anderen Netzwerkknoten anpingen, noch sind diese VM´s anpingbar. Der Zugriff über das Management (vSphere-Client) ist problemlos möglich. Ich habe den betreffenden Server in den Wartungsmodus versetzt, alle VM´s verschoben und ihn neu gestartet. Danach 2 VM´s zurück kopiert und gestartet. Keine Änderung.
Es werden keine Fehler oder Warnungen angezeigt. Bis Gestern zum Feierabend gab es keine Probleme, Heute Morgen trat der beschriebene Effekt auf.
Da keine Updates installiert wurden und die Konfiguration nicht geändert wurde, weiß ich nicht, wo ich bei der Fehlersuche ansetzen soll.
Bin für jeden Tipp dankbar.
MfG
Jürgen
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: 211950
Url: https://administrator.de/forum/vswitch-scheint-nicht-mehr-zu-arbeiten-211950.html
Ausgedruckt am: 24.12.2024 um 19:12 Uhr
5 Kommentare
Neuester Kommentar
Moin,
1. Mit den Kollegen reden die nach (deinem) Feierabend "nichts gemacht haben"
2. Phys. Switch: konfig prüfen, (trunk noch da usw), Logs durchforsten, ggfs. Kabel tauschen
3. vSwitch löschen, neu erstellen, vNICs zu ordnen, neu testen
lg,
Slainte
Da keine Updates installiert wurden und die Konfiguration nicht geändert wurde, weiß ich nicht, wo ich bei der
Fehlersuche ansetzen soll.
Am Anfang Fehlersuche ansetzen soll.
1. Mit den Kollegen reden die nach (deinem) Feierabend "nichts gemacht haben"
2. Phys. Switch: konfig prüfen, (trunk noch da usw), Logs durchforsten, ggfs. Kabel tauschen
3. vSwitch löschen, neu erstellen, vNICs zu ordnen, neu testen
lg,
Slainte
Hallo,
zu 1. - kann ausgeschlossen werden, da ich der einzige Admin bin.
zu 2. Das war die Lösung.
zu 3. entfällt
Der Tipp mit dem phy. Switch war gut. Manchmal sieht man den Wald vor Bäumen nicht.
Der phy. Switch sind 2 kaskadierte Dell-Switche aus der 7000-Reihe (PC7048 - 48x GB, Layer 3). In deren Konfiguration scheint die Tagging-Einstellung für die 4 Ports an denen der 3. VMware-Server hin, "verloren" gegangen zu sein. D.h. die VLAN´s wurden nicht an den vSwitch des 3. Servers durchgereicht.
Warum das "passierte", ist noch unklar. "Fremdeinwirkung" kann ich ausschließen (siehe 1.). Ich habe zwar eine Vermutung, aber das ist im nachgang nicht mehr reproduzierbar. Der Switch verwaltet mehere Konfigurationen, von denen aber nur eine als "Boot-Konfiguration" deklarierbar ist. Anscheinend hat er nicht die richtige Konfiguration beim Booten genutzt (oder es war noch die "alte" Konfiguration als Boot-Konfig markiert). Warum der Switch aber gebootet hat, ist unklar. Die Switche laufen über eine USV.
Am Ende ist es auch egal, es läuft wieder.
Jürgen
zu 1. - kann ausgeschlossen werden, da ich der einzige Admin bin.
zu 2. Das war die Lösung.
zu 3. entfällt
Der Tipp mit dem phy. Switch war gut. Manchmal sieht man den Wald vor Bäumen nicht.
Der phy. Switch sind 2 kaskadierte Dell-Switche aus der 7000-Reihe (PC7048 - 48x GB, Layer 3). In deren Konfiguration scheint die Tagging-Einstellung für die 4 Ports an denen der 3. VMware-Server hin, "verloren" gegangen zu sein. D.h. die VLAN´s wurden nicht an den vSwitch des 3. Servers durchgereicht.
Warum das "passierte", ist noch unklar. "Fremdeinwirkung" kann ich ausschließen (siehe 1.). Ich habe zwar eine Vermutung, aber das ist im nachgang nicht mehr reproduzierbar. Der Switch verwaltet mehere Konfigurationen, von denen aber nur eine als "Boot-Konfiguration" deklarierbar ist. Anscheinend hat er nicht die richtige Konfiguration beim Booten genutzt (oder es war noch die "alte" Konfiguration als Boot-Konfig markiert). Warum der Switch aber gebootet hat, ist unklar. Die Switche laufen über eine USV.
Am Ende ist es auch egal, es läuft wieder.
Jürgen
Bei Dell Billigsthardware ist das nicht unüblich und musst du wohl mit leben.
Manchmal hilft ein Update auf die aktuellste Firmware aber nicht immer. Das sind keine eigenen Dell Switches sondern umgelabelte Massenware von Accton.
Manchmal hilft ein Update auf die aktuellste Firmware aber nicht immer. Das sind keine eigenen Dell Switches sondern umgelabelte Massenware von Accton.
Moin,
Die 7000er sind von Brocade, ist nix mit Billigsthardware.
VG,
Thomas
Die 7000er sind von Brocade, ist nix mit Billigsthardware.
VG,
Thomas
Bei Dell [...] ist das nicht unüblich und musst du wohl mit leben.
Das kann ich so nur bestägigen. Für (dummes) L2 Switchung ohne Schnörkel taugen die Dell Dinger, ansontsen brauchts was anstädniges - hab mittlerweile alle Dell Kisten entsorgt.Die 7000er sind von Brocade, ist nix mit Billigsthardware.
Ne glaub das liegt an der Dell Firmware. Hatte auch extreme Probleme angefangen von den 32xx über 52xx, 54xx bis hoch zu den 62xxF
