Virtualisierung (ESXi HyperV)

[Benson]

Habt ihr Erfahrungen ob das im laufenden Betrieb geht oder habe ich dann einen kurzen Ausfall?

 

[Itrocket]

Ja.


Da war ich auch schon, habe jedoch keine Zuordnung bzgl. VM-Priorität gefunden. Siehe Screenshot.
Teaming/Lastausgleich brauchen wir eigentlich nicht, die onboard 1000er Karten würden wir eher nur als Failover nutzen wollen. Müsste ich die 1000er Karte dann runter zu standby packen, da sonst immer Lastausgleich stattfindet?

Hier habe ich jedoch noch nichts konfiguriert. Das ist alles noch von den "Experten" von Bechtle, die das Konstrukt damals aufgesetzt haben, die Hosts mit 10Gbit Karten verkaufen und dann nur einen 1Gbit Core-Switch hernehmen.

Spoiler: Screenshots

Logge dich ein oder registriere dich jetzt. to view Spoiler content!

Den 1GB als Standby-Adapter rein oder testweise ganz raus nehmen auf allen Hosts. Ein mixed Betrieb, so wie hier ist nicht empfehlenswert.

Eigentlich live möglich, aber der verdammte Murphy ist nicht zu unterschätzen.

 

[Benson]

Ja gut ok, das war jetzt einfach.
Habe den Lastausgleich entsprechend der VMware Doku umgestellt, jetzt ist es auch zur vorher langsamen VM schneller als 1Gbit.
Danke für die Tips!

Ausdrückliche Failover-Reihenfolge verwenden
Es wird immer der Uplink ausgewählt, der an erster Stelle der Liste der aktiven Adapter steht und die Failover-Ermittlungskriterien erfüllt. Bei dieser Option wird kein effektiver Lastausgleich durchgeführt.

 

[*Chris*]

Auch wenn das Problem jetzt gelöst ist, so wirklich Sinn ergibt das keinen, wieso immer dieselben VMs auf die 1gbit Karte und die anderen auf die 10gbit Karte zugegriffen haben. Vor allem soweit ich das sehe auch noch unterschiedlich je nachdem auf welchen Server der Zugriff erfolgt hat.

 

[Benson]

Nee, es hatten schon immer die selben VMs überall hin nur 1Gbit außer eben intern auf dem selben Host.

Die bisherige Option war "Anhand der ursprünglichen ID des virtuellen Ports routen".

Routen anhand des ursprünglichen virtuellen Ports
Der virtuelle Switch wählt Uplinks auf der Grundlage der Port-IDs der virtuellen Maschine auf dem vSphere Standard-Switch oder vSphere Distributed Switch aus.
Jede virtuelle Maschine, die auf einem ESXi-Host ausgeführt wird, verfügt über eine zugehörige virtuelle Port-ID auf dem virtuellen Switch. Zum Berechnen eines Uplinks für eine virtuelle Maschine verwendet der virtuelle Switch die Port-ID der virtuellen Maschine und die Anzahl der Uplinks in der Netzwerkkartengruppe. Nachdem der virtuelle Switch einen Uplink für eine virtuelle Maschine ausgewählt hat, leitet er den Datenverkehr immer durch denselben Uplink für diese virtuelle Maschine weiter, solang das System auf demselben Port ausgeführt wird. Der virtuelle Switch berechnet Uplinks für virtuelle Maschinen nur einmal, es sei denn, es werden Uplinks der Netzwerkkartengruppe hinzugefügt oder aus dieser entfernt.
Die Port-ID einer virtuellen Maschine ist unveränderlich, während die virtuelle Maschine auf demselben Host ausgeführt wird. Wenn Sie die virtuelle Maschine migrieren, ausschalten oder löschen, wird die Port-ID auf dem virtuellen Switch wieder verfügbar. Der virtuelle Switch sendet keine Daten mehr zu diesem Anschluss, was den Datenverkehr für den zugehörigen Uplink insgesamt reduziert. Wenn eine virtuelle Maschine eingeschaltet oder migriert wird, wird sie möglicherweise auf einem anderen Port angezeigt und verwendet eventuell den Uplink, der mit dem neuen Port verknüpft ist.

Routen anhand des ursprünglichen virtuellen Ports

Je nachdem was wann in welcher Reihenfolge angeschlossen und konfiguriert wurde kann ich mir das Verhalten so erklären.

 

[*Chris*]

Deswegen habe ich wegen dem Restart der VM gefragt, normalerweise hätte er sich eine neue Port-ID nehmen müssen. Genau das gibt für mich keine Sinn, wieso zufälligerweise genau dieselben VMs wieder über die 1gbit Karte geroutet wurden.

Sind da evtl. Regeln in den Port Groups eingestellt?

 

[Itrocket]

Deswegen habe ich wegen dem Restart der VM gefragt, normalerweise hätte er sich eine neue Port-ID nehmen müssen. Genau das gibt für mich keine Sinn, wieso zufälligerweise genau dieselben VMs wieder über die 1gbit Karte geroutet wurden.

Sind da evtl. Regeln in den Port Groups eingestellt?

Ein Neustart reicht nicht aus. Die VM muss gemoved, komplett abgeschaltet (kenne das genaue Zeitintervall nicht, aber ich glaube es dauert ein paar Minuten bis die ID frei gegeben wird) oder gelöscht werden, damit die ID frei wird.

Sofern er dann immer nur diese paar VMs einzeln gemoved hat, hat die jeweilige sich natürlich wieder diese freie ID genommen. Aber hier kenne ich das Testszenario zu wenig. Aber bei der geringen Anzahl an VMs für drei Hosts erscheint mir das plausibel.

 

[Benson]

Habe mal wieder ein Problem, vielleicht hat das Universalforum für alle Lebenslagen einen Tip.

Wir haben seit 17. März Probleme mit zwei Windows 2016 Std. VMs, die als Terminalserver im Verbund laufen, einer davon ist der Broker.
Die VMs frieren nach dem Hochfaren bei der ersten Anmeldung komplett ein (auch bei einem lokalen Konto). Sie antworten dann auch nicht mehr auf Ping. In der VMware Konsole kreiselt teilweise noch der Kreis bei der Anmeldung, teilweise bewegt sich aber gar nichts. Nach Zeitraum x, meist ca. 10 Minuten (nicht gemessen), reagieren sie auf einmal wie von Geisterhand wieder, auch der Ping kommt ab dem Zeitpunkt wieder zurück.
Das Verhalten zeigen sie wie es aussieht nur nach dem Boot, wenn sie durchlaufen gibt's keine Probleme.
Da es ab dem 17. März auftrat und an dem Tag bzw. wahrscheinlich in der Nacht auch Updates installiert wurden, hatte ich natürlich Windows Updates im Verdacht, habe auf einen Stand von der Woche davor zurückgesichert - kein Unterschied, Fehler tritt auch ohne die Updates vom 17. März auf.
Der Fehler tritt übrigens auch nicht bei jedem Boot auf! Es wirkt willkürlich.

Ist-Umgebung:
3 Fujitsu ESXi Hosts welche im Cluster mit HA-Unterstützung laufen (noch unter VMware 6.0). Speicher ist ein Dell Unity das per FC angebunden ist.
Der Fehler tritt nur bei diesen beiden VMs auf. Wir haben noch einen anderen 2016 Std, der zeigt das Verhalten nicht, hat aber auch nicht die aktuellsten Updates.
Es wurde an den VMs nichts installiert, da hat sich seit Monaten nichts geändert. Sie wurden ursprünglich Ende 2017 installiert, waren seit Mitte 2018 im produktiven Einsatz und liefen seitdem reibungslos durch.
Der Fehler tritt auf jedem Host auf. Auch wenn man die VMs komplett heruntergefahren hatte.
Die Auslastung der Hosts ist nicht außergewöhnlich.
Wir haben schon alle VMs heruntergefahren und die Hosts neugestartet, sie liefen seit 240 Tagen - keine Besserung.
Sicherungsjobs laufen spät Abends, nicht in dem Zeitraum.

Wir haben sogar einen Ersatz-Host dort ins Netz gebracht, aktuelle und ungenutzte Hardware von vor 2 Jahren, der Datenspeicher ist ebenfalls ein anderer (per NFS von OpenE eingebunden), die Switches etc. über die er ins Netzwerk geht sind andere. Der Host (Supermicro) läuft unter VMware 6.5, wir haben die VMs also auf diesen Host zurückgesichert, auf 6.5 aktualisiert, die VMware Tools aktualisiert. Das lief die ersten 10 Neustarts dann auch, weswegen wir Kompatibilitätsprobleme mit 2016 und VMware 6.0 im Verdacht hatten (die Updates der drei Hosts auf 6.7 sind fest eingeplant) - bei Tests gestern Abend trat der Fehler dort aber wieder auf.

Man findet auch in keinem Log Fehler, weder im vSphere, noch in VeeamOne. Die einzige Auffälligkeit die ich dort feststellen konnte war das hier, Speichernutzung ging unter die Decke, obwohl die Maschine nichts gemacht hat.
32GB Ram, die normalerweise auch bei voller Nutzeranzahl nicht über 25GB Auslastung gehen. Zur Wiederholdung: es passierte in diesem Zeitraum auf der VM absolut nichts.
Man sieht, dass es sich ab etwa 8:20 Uhr (erster Screenshot) bzw. 9 Uhr (zweiter Screenshot) wieder normalisiert hat, ab dann arbeiten die VMs als wäre nichts gewesen und bringen auch normale Performance.





So langsam gehen mir die Ideen aus.
Die Terminalserver neu zu installieren wollte ich mir wenn möglich ersparen, zumal ich bei meiner Recherche Beiträge gesehen habe, wo der Fehler auch nach Neuinstallationen auftrat.

 

[Itrocket]

Klingt für mich nach einem Speicherproblem.

Hast du den Memory fixiert, respektive komplett reserviert? Hier hatte ich Mal massiv Probleme mit diversen VMs welche sich ähnlich verhalten haben. Habe dann den Speicher komplett für die VMs reserviert und das Problem war Geschichte.

 

[Benson]

Nein, sieht nicht so aus:



Kann das mal testen, die eigentlichen prod-VMs zeigten das Verhalten auch ohne Netzwerk, so kann ich das isoliert testen.
Würde mich dann aber trotzdem interessieren, wieso das auf einmal auftrat, nur bei diesen beiden VMs und das auch auf anderer identischer und komplett anderer Hardware.

 

[Itrocket]

Nein, sieht nicht so aus:

Anhang anzeigen 11036

Kann das mal testen, die eigentlichen prod-VMs zeigten das Verhalten auch ohne Netzwerk, so kann ich das isoliert testen.
Würde mich dann aber trotzdem interessieren, wieso das auf einmal auftrat, nur bei diesen beiden VMs und das auch auf anderer identischer und komplett anderer Hardware.

Kann ich dir auch nicht beantworten, kann dir nur sagen das dies bei Echtzeitsystemen wie RDS oder Citrix öfter mal zu Problemen führt. Ich würde da alle Ressourcen fix zuweisen. Auch bei DB Servern, vor allem SQL und Co. Dynamische Memory verhalten sich immer unvorhersehbar und sorgen öfter für massive Performanceeinbussen.

Wobei dein Effekt in dem Ausmass neu für mich ist. Hatte schon ähnliche Probleme mit dynamischen Mem, aber das waren dann relativ kurze Hänger von ein paar Sekunden, aber da waren auch viele User drauf.

 

[Benson]

Die Einstellung bringt leider nichts, friert noch genau so ein.



Der Host ist auch trotzdem nicht arg ausgelastet:

 

[Itrocket]

Die Einstellung bringt leider nichts, friert noch genau so ein.

Anhang anzeigen 11037

Der Host ist auch trotzdem nicht arg ausgelastet:
Anhang anzeigen 11039

Schade. Einen versuch war es wert.

Nutzt ihr NTP Server für die Timesync? Wenn ja, welche und stimmt die Zeit nach dem Bootvorgang?
Hast du NTFS Logs im Event?
Habt ihr NFS Luns im VMware?
Wie sehen die Services nach dem Reboot aus?
Welche stehen auf automatic delayed?
Welches Antivirenprogramm nutzt ihr (Defender)? Welche scheduled tasks siehst du?

 

[Benson]

NTP ist der lokale DC, die Uhrzeit stimmt auch.
NTFS Log ist nicht aktiv.
Nur ein NFS Datenspeicher ist eingebunden, in dem liegen die Backups. Der liegt aber auf einem anderen SAN. Alles andere ist per VMFS5vom Unity eingebunden.
Virenscanner ist F-Secure.
In der Aufgabenplanung sehe ich nichts außergewöhnliches, bei den Diensten ebenso wenig. Er berappelt sich dann ja und alles läuft, sogar der Broker usw. kommt dann hoch und der Lastausgleich funktioniert...

Habe jetzt auch festgestellt, dass es nicht unbedingt nur nach dem Hochfahren passiert. Vorhin war ich schon angemeldet und dann fror er ein. Jetzt aktuell scheinbar beim Herunterfahren. Allerdings konnte ich es bei der VM, die den reservierten Speicher bekommen hat jetzt nicht wieder nachvollziehen. Ich teste weiter.

 

[silverSl!DE]

Jetzt mal frei ins blaue geschossen, Wie ist der Festplatten I/O? Lagert der iwas tonnenweise aus oder sucht sich evtl an Reg-Keys tot?

 

[Benson]

Jetzt mal frei ins blaue geschossen, Wie ist der Festplatten I/O? Lagert der iwas tonnenweise aus oder sucht sich evtl an Reg-Keys tot?

Der ist ok, liegen ja auch die anderen VMs aufm selben SAN und es gibt sonst keine Probleme.
Reg Key: die friert wie halt wirklich komplett ein. Wenns nur langsam wäre würde sie ja wenigstens zurückpingen. Und ich han das per Konsole beobachtet: das Aufwachen ist wirklich instant, wie in nem Video Pause und play drücken.

Aber so unmotiviert das klingt: ich habe einen vorerst funktionierenden Zustand hergestellt und mich jetzt die ganze Woche damit rum geschlagen. Jetzt habe ich erst mal eine Woche Urlaub und lasse das Thema ruhen.

 

[Itrocket]

Der ist ok, liegen ja auch die anderen VMs aufm selben SAN und es gibt sonst keine Probleme.
Reg Key: die friert wie halt wirklich komplett ein. Wenns nur langsam wäre würde sie ja wenigstens zurückpingen. Und ich han das per Konsole beobachtet: das Aufwachen ist wirklich instant, wie in nem Video Pause und play drücken.

Aber so unmotiviert das klingt: ich habe einen vorerst funktionierenden Zustand hergestellt und mich jetzt die ganze Woche damit rum geschlagen. Jetzt habe ich erst mal eine Woche Urlaub und lasse das Thema ruhen.

Ein paar Nächte drüber schlafen, Google bemühen und eventuell hat ein anderer das gleiche oder ein ähnliches Problem. Geniesse die Auszeit, so wie ich. Die Corona Homeoffice Zeit war extrem, da ich noch weniger zu dem gekommen bin was eigentlich für diese Zeit geplant war. Wird Zeit zum trinken und schlafen.

Noch als kleiner Input. Geht die CPU eigentlich auch hoch? Und/Oder hast du Enhanced VMotion Compatibility (EVC) aktiviert? Möglicherweise ist die CPU auch der Auslöser. Ist aber eben schwer zu beurteilen.

 

[silverSl!DE]

Btw cpu. Evtl ne xeon microcode geschichte?
Hat fujitsu auch wie dell custom builds vom hypervisor? Dell hatte da mal nen miesen bug bei nem build mit nem elenden memory leak. Hat ram weggemuncht wie ich ne pizza hawaii.

 

[Itrocket]

Btw cpu. Evtl ne xeon microcode geschichte?
Hat fujitsu auch wie dell custom builds vom hypervisor? Dell hatte da mal nen miesen bug bei nem build mit nem elenden memory leak. Hat ram weggemuncht wie ich ne pizza hawaii.

Pizza Hawaii?? Was bist du denn für einer? Das ist doch keine Pizza.








Würde meine Holde jetzt sagen. Ich liebe die Pizza auch. Scheinbar ne ITler-Krankheit.

 

[Benson]

Würde meine Holde jetzt sagen. Ich liebe die Pizza auch. Scheinbar ne ITler-Krankheit.

Gehts noch? Was sind hier die Ausschlusskriterien?


Ich hatte kein Homeoffice, im Gegenteil komprimierter Büroalltag weil nur die nervigen Kollegen nicht im Urlaub waren.

@CPU
Die Geschichte tritt halt auch auf einem drei Jahre neueren Supermicro Host auf... da ist ungefähr alles anders.
Aber nein, die ging nicht hoch. Bin ja jetzt kein Profi wie ihr aber in vsphere und veeamOne war die einzige Auffälligkeit die oben gezeigt mit dem RAM.

Und/Oder hast du Enhanced VMotion Compatibility (EVC) aktiviert?

Denke nein, wir haben nicht mal HA aktiv.