9
Netzwerkfehler bei HyperV - Host
Hallo Admins,
ich habe folgendes Problem, welches mir so langsam graue Haare bereitet.
Folgendes Szenario:
Vorher:
Hostserver: ESXi 5.1
4 VMs mit Win 2008R2
-> Eine VM davon war mit einem Win SQL 2008 ausgestattet welcher für die Datenbank der Branchensoftware zuständig ist.
Nachher (nach Umstellung auf neue Hardware):
Hostserver HyperV 2016
4 VMs mit Win 2016
-> Eine VM davon mit SQL 2016 für die Datenbank der Brachensoftware
Clients nach wie vor Win 10 Pro
Infos zu Software des Kunden:
Die Software wird mit einem Netzlaufwerk verbunden. In diesem Fall mit "Z". Der User startet die Software.exe aus dem Netzlaufwerk herraus. Sprich die Software wird somit über das Netzwerk gestartet.
Ein Clientinstallation gibt es hier nicht.
Lediglich ein Reg-Wert wird eingefügt, welcher auf den SQL-Server verweist.
Einstellungen am HyperV
NIC-Team:
Es gibt 2 Netzwerkkarten (onboard) welche zu einem Team zusammengefügt wurden. Dieses Team wiederum wurde als VSwitch in den HyperV integriert.
Netzwerkumgebung:
Nicteam:
VSwitch:
Was ist das Problem ?
Die Software des Kunden stürt am Tag mehrfach mit folgendem Fehler ab:
-> Dies ist das einzigste was in Log des User geschrieben wird. Am Server und am Host wird nichts mitgeloggt.
Laut Hersteller, passiert dies nur bei "instabieler" Netzwerkverbindung. Sprich die Software wird kurz Netzwerkseitig unterbrochen. Spürbar ist ist dies nicht.
Wichtig für euch für die Fehlereingrenzung ist auch folgendes.
-> Am Terminalserver des Kunden ( VM im selben HyperV ) passiert dieser Fehler auch.
Was haben wir schon alles geändert:
Neuester Intel-Treiber installiert:
VMQ und Large-Send-Offload auf allen Schnittstellen deaktivert:
Anpassung der MAC der V-Switch
-> zuvor war Lan1 + Nic01 + vEthernet (Switch01) mit MAC A4:BF:01:1B:FA:26 versehen. Also 3 mal die selbe MAC welche für Ereignis-Log-Fehler "16945" sorgte.
Virenschutz wurde zum Test auch schon komplett entfernt -> Ohne Erfolg
Was hat sich nicht geändert:
-> Konfiguration und Hardware der Switches und Router
-> Virenschutz + Firewallkonfig
Gibt bei HyperV Servern einfach mehr Probleme was solche Szenarien angeht, oder vergesse ich einen wesentlichen Punkt in der Konfiguration ?
Falls Ihr noch mehr Info benötigt schreibt einfach.
vielen Dank schon einmal für eure Hilfe !
ich habe folgendes Problem, welches mir so langsam graue Haare bereitet.
Folgendes Szenario:
Vorher:
Hostserver: ESXi 5.1
4 VMs mit Win 2008R2
-> Eine VM davon war mit einem Win SQL 2008 ausgestattet welcher für die Datenbank der Branchensoftware zuständig ist.
Nachher (nach Umstellung auf neue Hardware):
Hostserver HyperV 2016
4 VMs mit Win 2016
-> Eine VM davon mit SQL 2016 für die Datenbank der Brachensoftware
Clients nach wie vor Win 10 Pro
Infos zu Software des Kunden:
Die Software wird mit einem Netzlaufwerk verbunden. In diesem Fall mit "Z". Der User startet die Software.exe aus dem Netzlaufwerk herraus. Sprich die Software wird somit über das Netzwerk gestartet.
Ein Clientinstallation gibt es hier nicht.
Lediglich ein Reg-Wert wird eingefügt, welcher auf den SQL-Server verweist.
Einstellungen am HyperV
NIC-Team:
Es gibt 2 Netzwerkkarten (onboard) welche zu einem Team zusammengefügt wurden. Dieses Team wiederum wurde als VSwitch in den HyperV integriert.
Netzwerkumgebung:
Nicteam:
VSwitch:
Was ist das Problem ?
Die Software des Kunden stürt am Tag mehrfach mit folgendem Fehler ab:
-> Dies ist das einzigste was in Log des User geschrieben wird. Am Server und am Host wird nichts mitgeloggt.
Laut Hersteller, passiert dies nur bei "instabieler" Netzwerkverbindung. Sprich die Software wird kurz Netzwerkseitig unterbrochen. Spürbar ist ist dies nicht.
Wichtig für euch für die Fehlereingrenzung ist auch folgendes.
-> Am Terminalserver des Kunden ( VM im selben HyperV ) passiert dieser Fehler auch.
Was haben wir schon alles geändert:
Neuester Intel-Treiber installiert:
VMQ und Large-Send-Offload auf allen Schnittstellen deaktivert:
Anpassung der MAC der V-Switch
-> zuvor war Lan1 + Nic01 + vEthernet (Switch01) mit MAC A4:BF:01:1B:FA:26 versehen. Also 3 mal die selbe MAC welche für Ereignis-Log-Fehler "16945" sorgte.
Virenschutz wurde zum Test auch schon komplett entfernt -> Ohne Erfolg
Was hat sich nicht geändert:
-> Konfiguration und Hardware der Switches und Router
-> Virenschutz + Firewallkonfig
Gibt bei HyperV Servern einfach mehr Probleme was solche Szenarien angeht, oder vergesse ich einen wesentlichen Punkt in der Konfiguration ?
Falls Ihr noch mehr Info benötigt schreibt einfach.
vielen Dank schon einmal für eure Hilfe !
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: 344435
Url: https://administrator.de/contentid/344435
Ausgedruckt am: 22.11.2024 um 16:11 Uhr
9 Kommentare
Neuester Kommentar
Hallo,
Wenn ich das richtig sehe wurde das Nic-Teaming über den server-manager erstellt oder? Wie ist das Nic-Teaming konfiguriert Switchunabhängig, Lacp. Statisches Lacp? Netzwerkkabel getauscht? Treiber aktuell?
Kannst du das Nic-Teaming wenn es die Karten unterstützen über den treiber mit Lacp erstellen! Natürlich managebarer Switch vorausgesetzt!
Ich würde auf einer Maschine welche es beim Kunden betrifft mal Wireshark anwerfen und dann schauen was im Fehlerfall passiert!
Was sagt das Log vom Server bezüglich des Nic-Teaming/Lan-Verbindung?
Gruß Niklas
Wenn ich das richtig sehe wurde das Nic-Teaming über den server-manager erstellt oder? Wie ist das Nic-Teaming konfiguriert Switchunabhängig, Lacp. Statisches Lacp? Netzwerkkabel getauscht? Treiber aktuell?
Kannst du das Nic-Teaming wenn es die Karten unterstützen über den treiber mit Lacp erstellen! Natürlich managebarer Switch vorausgesetzt!
Ich würde auf einer Maschine welche es beim Kunden betrifft mal Wireshark anwerfen und dann schauen was im Fehlerfall passiert!
Was sagt das Log vom Server bezüglich des Nic-Teaming/Lan-Verbindung?
Gruß Niklas
Hallo,
startet die Software mal über den UNC-Pfad.
Grüße
Richard
startet die Software mal über den UNC-Pfad.
Grüße
Richard
auch hallo...
ich habe folgendes Problem, welches mir so langsam graue Haare bereitet.
nicht doch..
Folgendes Szenario:
Vorher:
Hostserver: ESXi 5.1
4 VMs mit Win 2008R2
-> Eine VM davon war mit einem Win SQL 2008 ausgestattet welcher für die Datenbank der Branchensoftware zuständig ist.
gute Configuration...
welche Branchensoftware ist es denn ?
Nachher (nach Umstellung auf neue Hardware):
Hostserver HyperV 2016
uh.... hätte ich jetzt nicht gemacht... ich wärezu esxi6.5 gegangen!
Clients nach wie vor Win 10 Pro
Infos zu Software des Kunden:
Die Software wird mit einem Netzlaufwerk verbunden. In diesem Fall mit "Z". Der User startet die Software.exe aus dem Netzlaufwerk herraus. Sprich die Software wird somit über das Netzwerk gestartet.
Ein Clientinstallation gibt es hier nicht.
Lediglich ein Reg-Wert wird eingefügt, welcher auf den SQL-Server verweist.
Einstellungen am HyperV
NIC-Team:
Es gibt 2 Netzwerkkarten (onboard) welche zu einem Team zusammengefügt wurden. Dieses Team wiederum wurde als VSwitch in den HyperV integriert.
du schreibst nix zu deinem Switch! kann der LAG... etc usw.
als erstes würde ich das Nic Team auflösen! und Testen.
wenn du wirklich mehr leistung brauchst, baue eine 10GBit Nic ein, und kauf ein passenden switch!
bei einen neuen Server erwarte ich eigentlich sowas!
Was ist das Problem ?
Die Software des Kunden stürt am Tag mehrfach mit folgendem Fehler ab:
-> Dies ist das einzigste was in Log des User geschrieben wird. Am Server und am Host wird nichts mitgeloggt.
kann ich kaum glauben...
Laut Hersteller, passiert dies nur bei "instabieler" Netzwerkverbindung. Sprich die Software wird kurz Netzwerkseitig unterbrochen. Spürbar ist ist dies nicht.
das kann gut sein... wenn deine NIC Team nicht sauber rennt!
Wichtig für euch für die Fehlereingrenzung ist auch folgendes.
-> Am Terminalserver des Kunden ( VM im selben HyperV ) passiert dieser Fehler auch.
aha...
also liegt es am Host, bzw. an der Hardware!
was ist das für ein Server?
was für ein MB?
ist die kiste für deine Config Zertifiziert?
noch mal... löse dein NIC Teaming auf, schalte eine NIC ab! auf die idee hättest du selber kommen können!
Was haben wir schon alles geändert:
Neuester Intel-Treiber installiert:
VMQ und Large-Send-Offload auf allen Schnittstellen deaktivert:
Virenschutz wurde zum Test auch schon komplett entfernt -> Ohne Erfolg
Was hat sich nicht geändert:
-> Konfiguration und Hardware der Switches und Router
du hast am switch das teaming nicht eingerichtet?
vielen Dank schon einmal für eure Hilfe !
Frank
ich habe folgendes Problem, welches mir so langsam graue Haare bereitet.
Folgendes Szenario:
Vorher:
Hostserver: ESXi 5.1
4 VMs mit Win 2008R2
-> Eine VM davon war mit einem Win SQL 2008 ausgestattet welcher für die Datenbank der Branchensoftware zuständig ist.
welche Branchensoftware ist es denn ?
Nachher (nach Umstellung auf neue Hardware):
Hostserver HyperV 2016
4 VMs mit Win 2016
-> Eine VM davon mit SQL 2016 für die Datenbank der Brachensoftware
-> Eine VM davon mit SQL 2016 für die Datenbank der Brachensoftware
Clients nach wie vor Win 10 Pro
Infos zu Software des Kunden:
Die Software wird mit einem Netzlaufwerk verbunden. In diesem Fall mit "Z". Der User startet die Software.exe aus dem Netzlaufwerk herraus. Sprich die Software wird somit über das Netzwerk gestartet.
Ein Clientinstallation gibt es hier nicht.
Lediglich ein Reg-Wert wird eingefügt, welcher auf den SQL-Server verweist.
Einstellungen am HyperV
NIC-Team:
Es gibt 2 Netzwerkkarten (onboard) welche zu einem Team zusammengefügt wurden. Dieses Team wiederum wurde als VSwitch in den HyperV integriert.
als erstes würde ich das Nic Team auflösen! und Testen.
wenn du wirklich mehr leistung brauchst, baue eine 10GBit Nic ein, und kauf ein passenden switch!
bei einen neuen Server erwarte ich eigentlich sowas!
Was ist das Problem ?
Die Software des Kunden stürt am Tag mehrfach mit folgendem Fehler ab:
-> Dies ist das einzigste was in Log des User geschrieben wird. Am Server und am Host wird nichts mitgeloggt.
Laut Hersteller, passiert dies nur bei "instabieler" Netzwerkverbindung. Sprich die Software wird kurz Netzwerkseitig unterbrochen. Spürbar ist ist dies nicht.
Wichtig für euch für die Fehlereingrenzung ist auch folgendes.
-> Am Terminalserver des Kunden ( VM im selben HyperV ) passiert dieser Fehler auch.
also liegt es am Host, bzw. an der Hardware!
was ist das für ein Server?
was für ein MB?
ist die kiste für deine Config Zertifiziert?
noch mal... löse dein NIC Teaming auf, schalte eine NIC ab! auf die idee hättest du selber kommen können!
Was haben wir schon alles geändert:
Neuester Intel-Treiber installiert:
VMQ und Large-Send-Offload auf allen Schnittstellen deaktivert:
Anpassung der MAC der V-Switch
Virenschutz wurde zum Test auch schon komplett entfernt -> Ohne Erfolg
Was hat sich nicht geändert:
-> Konfiguration und Hardware der Switches und Router
-> Virenschutz + Firewallkonfig
Gibt bei HyperV Servern einfach mehr Probleme was solche Szenarien angeht, oder vergesse ich einen wesentlichen Punkt in der Konfiguration ?
ja... außer das du meiner meinung bei VMware bleiben solltest, hast du probleme mit deiner LAG/Teaming schlagmichnichtot config. was sagt eigentlich dein switch dazu?Gibt bei HyperV Servern einfach mehr Probleme was solche Szenarien angeht, oder vergesse ich einen wesentlichen Punkt in der Konfiguration ?
Falls Ihr noch mehr Info benötigt schreibt einfach.
beschreib mal die Hardware besser- also den Server!vielen Dank schon einmal für eure Hilfe !
@ niklasschaefer
-> Team wurde über den Servermanager erstellt
-> Momentan ist das NIC noch "Dynamisch" da keine konfig auf der Switch durchgeführt wurde. Also kein LACP / War bisher bei ESXi nicht nötig. Zuvor war auch ein Team von 2 Nics im ESXi eingerichtet.
-> Switches Sind von HP Typ 25XX ( Ich kuck morgen mal genauer nach )
-> Wireshark führ ich morgen mal mit dem Kunden aus
@ C.R.S.
-> Wird morgen getestet
@Vision2015
-> Ich hab vergessen zu schreiben das ich zum test schon einmal das NIC-Team aufgelöst habe -> Kein Erfolg
-> Hardware komme morgen. Hab momentan kein Zugriff auf die Hardwareliste. Ist aber ein Zertifizierter Server. Wie gesagt genaueres kommt morgen
-> Switches sind managed (HP ) Eine Konfig war aber komischerweis bisher nicht nötig. Also beim ESXi. Dieser war ja auch mit einem Nic-Team angebunden.
-> Genauers zur Hardware kommt morgen
-> Team wurde über den Servermanager erstellt
-> Momentan ist das NIC noch "Dynamisch" da keine konfig auf der Switch durchgeführt wurde. Also kein LACP / War bisher bei ESXi nicht nötig. Zuvor war auch ein Team von 2 Nics im ESXi eingerichtet.
-> Switches Sind von HP Typ 25XX ( Ich kuck morgen mal genauer nach )
-> Wireshark führ ich morgen mal mit dem Kunden aus
@ C.R.S.
-> Wird morgen getestet
@Vision2015
-> Ich hab vergessen zu schreiben das ich zum test schon einmal das NIC-Team aufgelöst habe -> Kein Erfolg
-> Hardware komme morgen. Hab momentan kein Zugriff auf die Hardwareliste. Ist aber ein Zertifizierter Server. Wie gesagt genaueres kommt morgen
-> Switches sind managed (HP ) Eine Konfig war aber komischerweis bisher nicht nötig. Also beim ESXi. Dieser war ja auch mit einem Nic-Team angebunden.
-> Genauers zur Hardware kommt morgen
Hallo,
zunächst habe ich noch ein Paar Fragen:
- Wie wird das Netzlaufwerk verbunden? Per GPO?
- Mit welchem Modus verbindest du die Laufwerke? Ersetzen?
- Wurde es vorher anders verbunden?
Ich tippe auf die Hintergrundaktualisierung der GPO bzw. der Netzlaufwerke. Angenommen du hast du Modus "Ersetzen" gewählt.
Alle 90 Minuten (je nach Einstellung) passiert folgendens:
- GPO wird im Hintergrund ausgeführt
- Netzlaufwerk wird kurz getrennt
- Netzlaufwerk wird wiederverbunden (ersetzt).
Dieses Verhalten kann einige Programme empfindlich stören.
Du könntest für das Netzlaufwerk testweise die Hintergrundaktualisierung ausschalten:
"Hintergrundaktualisierung der Gruppenrichtlinie deaktivieren" auf aktiviert setzen.
VG,
Florian
zunächst habe ich noch ein Paar Fragen:
- Wie wird das Netzlaufwerk verbunden? Per GPO?
- Mit welchem Modus verbindest du die Laufwerke? Ersetzen?
- Wurde es vorher anders verbunden?
Ich tippe auf die Hintergrundaktualisierung der GPO bzw. der Netzlaufwerke. Angenommen du hast du Modus "Ersetzen" gewählt.
Alle 90 Minuten (je nach Einstellung) passiert folgendens:
- GPO wird im Hintergrund ausgeführt
- Netzlaufwerk wird kurz getrennt
- Netzlaufwerk wird wiederverbunden (ersetzt).
Dieses Verhalten kann einige Programme empfindlich stören.
Du könntest für das Netzlaufwerk testweise die Hintergrundaktualisierung ausschalten:
"Hintergrundaktualisierung der Gruppenrichtlinie deaktivieren" auf aktiviert setzen.
VG,
Florian
Hi,
was man noch testen könnte wäre das NIC-Teaming in der VM zu machen. Ist so weit ich weiß mittlerweile der empfohlene Weg. Also pro NIC einen vSwitch und dann jeweils in die VM. Wir hatten auch Probleme mit dem NIC-Teaming auf Hypervisorebene das z.B. Pakete kamen doppelt von der Gebäudevisualisierung. Hier noch ne kleine Starthilfe:
https://technet.microsoft.com/de-de/library/mt179272.aspx
http://www.serverwatch.com/server-tutorials/configuring-nic-teaming-for ...
Gruß und Viel Erfolg,
Mad-Eye
edit: Hab wohl was überlesen sorry.
was man noch testen könnte wäre das NIC-Teaming in der VM zu machen. Ist so weit ich weiß mittlerweile der empfohlene Weg. Also pro NIC einen vSwitch und dann jeweils in die VM. Wir hatten auch Probleme mit dem NIC-Teaming auf Hypervisorebene das z.B. Pakete kamen doppelt von der Gebäudevisualisierung. Hier noch ne kleine Starthilfe:
https://technet.microsoft.com/de-de/library/mt179272.aspx
http://www.serverwatch.com/server-tutorials/configuring-nic-teaming-for ...
Gruß und Viel Erfolg,
Mad-Eye
edit: Hab wohl was überlesen sorry.
@Vision2015
-> Ich hab vergessen zu schreiben das ich zum test schon einmal das NIC-Team aufgelöst habe -> Kein Erfolg
Bisher scheint die Hintergrundaktualisierung der GPOs der Auslöser gewesen zu sein. Wir hatten heute keinen Absturz. Ich geb den Ding jetzt mal 2 Tage und melde mich nochmal.
Vielen Dank schon mal für die schnellen Tips
Vielen Dank schon mal für die schnellen Tips
Und war es die Lösung?
Bis heute gab es keinen Ausfall mehr. Vielen Dank für euere Hilfe !
