12
Hyper-V VM(s) verlieren Netzwerk
Guten Tag Gemeinde
Ich weiss es ist Sonntag, aber evtl. hilft mir trotzdem wer bei meinem Dilemma.
Ich habe gestern einen Server bei einem Kunden installiert. Ein physischer Server, zwei virtuelle Server.
Heute morgen schrieb der Kunde ob ich was am Server mache, er käme nicht mehr drauf. Tatsächlich liess sich eine der zwei VMs nicht mehr anpingen, lief aber ganz normal. Im Eventlog fiel mir nichts spannend auf, bis auf das:
Sehr häufig wird die Ereignis ID 14 protokolliert.
Inhalt:
"Das Netzwerk der Miniport-NIC 'Microsoft Hyper-V Network Adapter' wurde geändert.
Was spannend ist:
Dies tritt erst seit gestern auf, seit der Server am "richtigen" Ort steht. Bei mir zu Hause hat er dieses Spielchen nicht gemacht. Alle waren immer verfügbar.
Ist da was mit dem physischen Switch nicht gut? Inkompatibilität?
Was mir auf dem betroffenen Server noch aufgefallen ist, ist noch dieser Fehler:
Der Name "BLABLUBB :0" konnte nicht auf der Schnittstelle mit IP-Adresse 192.168.0.5 registriert werden. Der Computer mit IP-Adresse 192.168.0.46 hat nicht zugelassen, dass dieser Computer diesen Namen verwendet.
BLABLUBB ist der NetBios Name der Domäne, aber scheinbar hat jemand auch diesen suboptimalen Namen für ein Netzwerkgerät ausgesucht. Irgendein Elektroinstallateur. Das denke ich, sollte zwingend geändert werden.
Aber kann das der Fehler sein?
Bereits getestet habe ich das:
https://docs.microsoft.com/de-de/troubleshoot/windows-server/networking/ ...
Habe aber eigentlich einen Intel Controller drin.
Auf dem Host fand ich noch den Fehler aus dem angehängten Bild, soll ich diese Erweiterung deaktivieren?
Gruss
Christof
Edit: Bin nahe dran in ein Ticket bei Microsoft zu investieren. Das Problem muss ich irgendwie zügig lösen.
Ich weiss es ist Sonntag, aber evtl. hilft mir trotzdem wer bei meinem Dilemma.
Ich habe gestern einen Server bei einem Kunden installiert. Ein physischer Server, zwei virtuelle Server.
Heute morgen schrieb der Kunde ob ich was am Server mache, er käme nicht mehr drauf. Tatsächlich liess sich eine der zwei VMs nicht mehr anpingen, lief aber ganz normal. Im Eventlog fiel mir nichts spannend auf, bis auf das:
Sehr häufig wird die Ereignis ID 14 protokolliert.
Inhalt:
"Das Netzwerk der Miniport-NIC 'Microsoft Hyper-V Network Adapter' wurde geändert.
Was spannend ist:
Dies tritt erst seit gestern auf, seit der Server am "richtigen" Ort steht. Bei mir zu Hause hat er dieses Spielchen nicht gemacht. Alle waren immer verfügbar.
Ist da was mit dem physischen Switch nicht gut? Inkompatibilität?
Was mir auf dem betroffenen Server noch aufgefallen ist, ist noch dieser Fehler:
Der Name "BLABLUBB :0" konnte nicht auf der Schnittstelle mit IP-Adresse 192.168.0.5 registriert werden. Der Computer mit IP-Adresse 192.168.0.46 hat nicht zugelassen, dass dieser Computer diesen Namen verwendet.
BLABLUBB ist der NetBios Name der Domäne, aber scheinbar hat jemand auch diesen suboptimalen Namen für ein Netzwerkgerät ausgesucht. Irgendein Elektroinstallateur. Das denke ich, sollte zwingend geändert werden.
Aber kann das der Fehler sein?
Bereits getestet habe ich das:
https://docs.microsoft.com/de-de/troubleshoot/windows-server/networking/ ...
Habe aber eigentlich einen Intel Controller drin.
Auf dem Host fand ich noch den Fehler aus dem angehängten Bild, soll ich diese Erweiterung deaktivieren?
Gruss
Christof
Edit: Bin nahe dran in ein Ticket bei Microsoft zu investieren. Das Problem muss ich irgendwie zügig lösen.
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: 1845737856
Url: https://administrator.de/contentid/1845737856
Ausgedruckt am: 24.11.2024 um 15:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
„bei Dir zu Hause“ - machst Du so etwas auf 'n Samstag privat?
Vermutlich hast du vergessen die Netzwerkkategorie auf privat zu setzen (typischer Anfängerfehler). Vermutlich wirst Du als nächste Wahnsinnstat die Firewall ausschalten
Gruß,
Jörg
„bei Dir zu Hause“ - machst Du so etwas auf 'n Samstag privat?
Vermutlich hast du vergessen die Netzwerkkategorie auf privat zu setzen (typischer Anfängerfehler). Vermutlich wirst Du als nächste Wahnsinnstat die Firewall ausschalten
Gruß,
Jörg
Zitat von @117471:
Hallo,
„bei Dir zu Hause“ - machst Du so etwas auf 'n Samstag privat?
Vermutlich hast du vergessen die Netzwerkkategorie auf privat zu setzen (typischer Anfängerfehler). Vermutlich wirst Du als nächste Wahnsinnstat die Firewall ausschalten
Gruß,
Jörg
Hallo,
„bei Dir zu Hause“ - machst Du so etwas auf 'n Samstag privat?
Vermutlich hast du vergessen die Netzwerkkategorie auf privat zu setzen (typischer Anfängerfehler). Vermutlich wirst Du als nächste Wahnsinnstat die Firewall ausschalten
Gruß,
Jörg
Hi Jörg
Ne ganz normal auf Domäne gesetzt. Die betroffene VM ist ja auch logischerweise in der Domäne.
Ich bin selbstständig und habe zu Hause mein Büro. D.h. ich hatte den Server für den Kunden an einem Mikrotik Router dem ich seinen IP Range zugewiesen habe. Gestern dann die Installation vor Ort.
Alles klar? ;)
Ich habe noch auf einen anderen Kundenserver gelinst, der auch Server 2019 mit einer VM hat. Da ist der virtuelle Switch gleich konfiguriert, und das Event 14 taucht auch da praktisch nie auf.
Gruss
Christof
Moin.
Die VMs sind mit statischen IP-Adressen konfiguriert?
Bist du dir zu 110% sicher, dass deren IP-Adressen im Kundennetz wirklich nicht anderweitig vergeben sind?
Ich hatte mal ein ähnliches Phänomen mit ner VM (noch unter 2012R2); stellte sich dann heraus, dass da ein Bauteil der Alarmanlage undokumentiert mit genau der gleichen IP-Adresse konfiguriert war wie die betroffene VM.
Cheers,
jsysde
Die VMs sind mit statischen IP-Adressen konfiguriert?
Bist du dir zu 110% sicher, dass deren IP-Adressen im Kundennetz wirklich nicht anderweitig vergeben sind?
Ich hatte mal ein ähnliches Phänomen mit ner VM (noch unter 2012R2); stellte sich dann heraus, dass da ein Bauteil der Alarmanlage undokumentiert mit genau der gleichen IP-Adresse konfiguriert war wie die betroffene VM.
Cheers,
jsysde
Zitat von @jsysde:
Moin.
Die VMs sind mit statischen IP-Adressen konfiguriert?
Bist du dir zu 110% sicher, dass deren IP-Adressen im Kundennetz wirklich nicht anderweitig vergeben sind?
Ich hatte mal ein ähnliches Phänomen mit ner VM (noch unter 2012R2); stellte sich dann heraus, dass da ein Bauteil der Alarmanlage undokumentiert mit genau der gleichen IP-Adresse konfiguriert war wie die betroffene VM.
Cheers,
jsysde
Moin.
Die VMs sind mit statischen IP-Adressen konfiguriert?
Bist du dir zu 110% sicher, dass deren IP-Adressen im Kundennetz wirklich nicht anderweitig vergeben sind?
Ich hatte mal ein ähnliches Phänomen mit ner VM (noch unter 2012R2); stellte sich dann heraus, dass da ein Bauteil der Alarmanlage undokumentiert mit genau der gleichen IP-Adresse konfiguriert war wie die betroffene VM.
Cheers,
jsysde
Hi jsysde
Jap, alles fixe IPs. Sogar nochmal geprüft - man weiss ja nie. :D Anderes Gerät kann eigentlich nicht sein, der alte Server hatte auch immer diese IP, also 192.168.0.5.
Ich vermute allerdings auch eher ein Umstand der von "aussen" her rührt. In meinem Testlab - ich nenne es jetzt nicht mehr privat :P - lief es einwandfrei.
Ich sehe gerade etwas sehr spannendes. Der Host selber verliert ständig die Verbindung zum Netzwerk!
Ich ziehe mich jetzt an und fahr mal dahin. Hab Schlüssel und er Kunde ist 10 Minuten entfernt. Wechsel ich mal Kabel und hänge das Ding direkt an die Firewall.
Ich ziehe mich jetzt an und fahr mal dahin. Hab Schlüssel und er Kunde ist 10 Minuten entfernt. Wechsel ich mal Kabel und hänge das Ding direkt an die Firewall.
Hallo,
Ich meinte eher den Hypervisor. Der sollte auf „Privat“ oder „Domäne“ stehen.
Auf der PS kannst Du dir den Adapter mit Get-NetConnectionProfile angucken.
Der Rechnername als NetBIOS-Name sollte eigentlich nicht stören. In dem Fall heißt das Gerät dann hurz.hurz
Evtl. kann man das „Elektrikergerät“ (Wallbox?) ja auch mal testweise zum Ausgrenzen abziehen…
Gruß,
Jörg
Zitat von @mazenauer:
Ne ganz normal auf Domäne gesetzt. Die betroffene VM ist ja auch logischerweise in der Domäne.
Ne ganz normal auf Domäne gesetzt. Die betroffene VM ist ja auch logischerweise in der Domäne.
Ich meinte eher den Hypervisor. Der sollte auf „Privat“ oder „Domäne“ stehen.
Auf der PS kannst Du dir den Adapter mit Get-NetConnectionProfile angucken.
Der Rechnername als NetBIOS-Name sollte eigentlich nicht stören. In dem Fall heißt das Gerät dann hurz.hurz
Evtl. kann man das „Elektrikergerät“ (Wallbox?) ja auch mal testweise zum Ausgrenzen abziehen…
Gruß,
Jörg
Hi Jörg
Steht auch auf Privat.
Leider weiss gerade auch der Chef nicht, was das für ein Gerät sein könnte. Werde morgen wohl mal die Elektriker anrufen die hier am Werke waren. ;)
Steht auch auf Privat.
Leider weiss gerade auch der Chef nicht, was das für ein Gerät sein könnte. Werde morgen wohl mal die Elektriker anrufen die hier am Werke waren. ;)
Hallo alle
Ich habe jetzt beim Server das Netzwerkkabel sowie den Port am Switch gewechselt. Seit fast einer Stunde nun keine seltsamen Einträge mehr im Log, und vor allem keine Discos mehr auf dem Host selber.
Ich klopfe jetzt nicht auf Holz sondern knutsche Holz, in der Hoffnung, dass das echt so eine Murphy-Banalität war...
Ich habe jetzt beim Server das Netzwerkkabel sowie den Port am Switch gewechselt. Seit fast einer Stunde nun keine seltsamen Einträge mehr im Log, und vor allem keine Discos mehr auf dem Host selber.
Ich klopfe jetzt nicht auf Holz sondern knutsche Holz, in der Hoffnung, dass das echt so eine Murphy-Banalität war...
Hallo,
Wenn es nicht dokumentiert ist, wird es abgeschaltet
In den Switches sollte man ja sehen können, auf welchem Port die MAC-Adresse herumturnt
Gruß,
Jörg
Zitat von @mazenauer:
Leider weiss gerade auch der Chef nicht, was das für ein Gerät sein könnte.
Leider weiss gerade auch der Chef nicht, was das für ein Gerät sein könnte.
Wenn es nicht dokumentiert ist, wird es abgeschaltet
In den Switches sollte man ja sehen können, auf welchem Port die MAC-Adresse herumturnt
Gruß,
Jörg
1Zitat von @117471:
Hallo,
Wenn es nicht dokumentiert ist, wird es abgeschaltet
In den Switches sollte man ja sehen können, auf welchem Port die MAC-Adresse herumturnt
Gruß,
Jörg
Hallo,
Zitat von @mazenauer:
Leider weiss gerade auch der Chef nicht, was das für ein Gerät sein könnte.
Leider weiss gerade auch der Chef nicht, was das für ein Gerät sein könnte.
Wenn es nicht dokumentiert ist, wird es abgeschaltet
In den Switches sollte man ja sehen können, auf welchem Port die MAC-Adresse herumturnt
Gruß,
Jörg
Hi Jörg
Leider kein sehr intelligenter Switch. ;) Aber wir wissen es jetzt. Es ist die Beleuchtung.
Und ich gebe dir recht, dass das kein Problem sein SOLLTE. Aber der Fileserver führt das im Eventlog als Fehler auf, und Fehler die keine sind, sind im "Ernstfall" halt Mist für die Analyse.
Man erinnert sich doch gerne an die SBS Zeiten... da war mehr rot als weiss im Log. ;)
Hallo,
mein SBS war dauerhaft grün.
Aber ich hatte auch die "Passwort läuft nie ab" Option vom spsearch Dienst gesetzt und den WSUS regelmäßig bereinigt
Gruß,
Jörg
mein SBS war dauerhaft grün.
Aber ich hatte auch die "Passwort läuft nie ab" Option vom spsearch Dienst gesetzt und den WSUS regelmäßig bereinigt
Gruß,
Jörg
Zitat von @117471:
Hallo,
mein SBS war dauerhaft grün.
Aber ich hatte auch die "Passwort läuft nie ab" Option vom spsearch Dienst gesetzt und den WSUS regelmäßig bereinigt
Gruß,
Jörg
Hallo,
mein SBS war dauerhaft grün.
Aber ich hatte auch die "Passwort läuft nie ab" Option vom spsearch Dienst gesetzt und den WSUS regelmäßig bereinigt
Gruß,
Jörg
pah
Wie langweilig. ;)
Seit ich Kabel und Port gewechselt habe scheint sich das Ganze übrigens beruhigt zu haben…
