scrises
Goto Top

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

Nicteam:
2

VSwitch:
3



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.
4

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:
6

VMQ und Large-Send-Offload auf allen Schnittstellen deaktivert:
7

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.

8


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 !

Content-ID: 344435

Url: https://administrator.de/forum/netzwerkfehler-bei-hyperv-host-344435.html

Ausgedruckt am: 23.12.2024 um 05:12 Uhr

niklasschaefer
niklasschaefer 25.07.2017 um 19:55:26 Uhr
Goto Top
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
C.R.S.
C.R.S. 25.07.2017 um 21:25:11 Uhr
Goto Top
Hallo,

startet die Software mal über den UNC-Pfad.

Grüße
Richard
Vision2015
Vision2015 25.07.2017 aktualisiert um 21:42:17 Uhr
Goto Top
Zitat von @Scrises:

Hallo Admins,
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!
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.


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:

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
du hast am switch das teaming nicht eingerichtet?
-> 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?
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 !
Frank
Scrises
Scrises 25.07.2017 um 22:52:33 Uhr
Goto Top
@ 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
110135
Lösung 110135 26.07.2017 um 06:39:46 Uhr
Goto Top
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
Mad-Eye
Mad-Eye 26.07.2017 aktualisiert um 10:01:58 Uhr
Goto Top
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.
@Vision2015
-> Ich hab vergessen zu schreiben das ich zum test schon einmal das NIC-Team aufgelöst habe -> Kein Erfolg
Scrises
Scrises 26.07.2017 um 19:28:46 Uhr
Goto Top
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
110135
Lösung 110135 30.07.2017 um 19:35:04 Uhr
Goto Top
Und war es die Lösung?
Scrises
Scrises 30.07.2017 um 22:00:33 Uhr
Goto Top
Bis heute gab es keinen Ausfall mehr. Vielen Dank für euere Hilfe !