Warum sterben meine Client-Hyper-V-Verbindungen immer wieder?

Ich habe Client Hyper-V unter Win8, der einige VMs wie Ubuntu, eine saubere Windows-Build-Maschine usw. hostet. Meine VMs sind mit einem externen virtuellen Switch verbunden (gemeinsam mit dem Verwaltungsbetriebssystem), und das funktioniert einwandfrei ... für eine Weile - sie können die Welt sehen. Nach einer unbestimmten Zeit, wenn ich die Gast-VM wieder aufnehme, hat sie jedoch keinen Internetzugang mehr. Es kann einfach nicht sehen. Es hilft nicht, den Gast vollständig herunterzufahren und neu zu starten.

Derzeit kann ich dies nur "heilen", indem ich die Gäste aussetze, in den Virtual Switch Manager gehe, meine virtuellen Switches entferne, dieselben virtuellen Switches erneut hinzufüge und das Gastbetriebssystem reaktiviere. Dann funktioniert es sofort. Dies funktioniert sogar, wenn der Gast gerade angehalten wurde (nicht vollständig heruntergefahren).

Ist das ein häufiger Fehler? Was kann ich tun, um dies zu verhindern?

Update: Nach dem Experimentieren muss ich anscheinend nur den externen virtuellen Switch löschen / neu hinzufügen . Bis dahin glaubt das Gastbetriebssystem, dass die Verbindung getrennt ist.

— Marc Gravell
quelle

Wenn ich die Gast-VM wieder aufnehme, hat sie keinen Internetzugang. bedeutet, wenn Sie die VM nicht anhalten, wird Ihr Internetzugang ohne Unterbrechung fortgesetzt?

— Avirk

@avirk kann sich auch auf Suspend / Resume auf dem Host beziehen - viele Variablen. Aber um Ihre Frage zu beantworten - es scheint nicht zu passieren, wenn Sie den Gast ununterbrochen benutzen ... Aber ich muss den Gast selten ununterbrochen benutzen :)

— Marc Gravell

Ich frage mich, ob dies auf die Tatsache zurückzuführen ist, dass Hyper-V-Client eine portierte Version des Hyper-V-Servers ist und daher voraussichtlich die meiste Zeit mit einem Client ausgeführt wird, der ständig ausgeführt wird.

— James Mertz

Antworten:

Dies könnte ein Treiberproblem sein.

Im Thread Hyper-V Virtual Switch (Windows 8) bestand die Lösung beispielsweise darin, ein Downgrade auf Windows 7-Treiber durchzuführen, anstatt die von Windows 8 installierten zu verwenden.

— harrymc
quelle

Irgendeine Idee, ob es sich um den Gastgeber oder den Gast handelt?

— Marc Gravell

Windows 8 ist angeblich der Host.

— Harrymc

in meinem Fall habe ich auch win8 Gäste - Sie können sehen, wie es verwirrend werden kann; p

— Marc Gravell

Da das Problem auch unter Linux auftritt, muss der Host der gemeinsame Faktor sein. Am besten fahren Sie zunächst mit Linux-Clients fort, wenn dies möglich ist.

— Harrymc

Für Informationen habe ich eine separate Antwort mit weiteren Informationen hinzugefügt, aber Sie haben definitiv die Prämie verdient, mich auf den richtigen Weg zu führen - Prost.

— Marc Gravell

Das Problem hier waren (wie harrymc zu Recht bemerkte) zwielichtige Treiber und / oder Hardware, in diesem Fall ein integrierter Marvell-Netzwerkadapter. Es war nicht möglich, dem Ansatz "Verwenden eines älteren Treibers" zu folgen (er wird einfach nicht installiert, und ich bin mir nicht sicher, ob dies ohnehin eine gute Vorgehensweise ist), daher habe ich stattdessen einen Intel CT-Netzwerkadapter (oder einen GT) eingesetzt wäre wahrscheinlich in Ordnung, wenn Sie keinen freien PCI Express-Steckplatz haben).

Mit dem On-Board würde dieses Szenario beim Suspendieren des Hosts auftreten: Es wird für Hyper-V einfach nicht korrekt fortgesetzt. Mit der dedizierten Netzwerkkarte funktioniert es einfach . Wenn Sie sich die Mühe machen, die Netzwerkkarte auszutauschen, erhalten Sie möglicherweise auch ein gut unterstütztes Modell / eine Marke, weshalb ich mich für Intel entschieden habe.

— Marc Gravell
quelle