Moin,
betreibt irgendjemand L2TP-Gateways auf VMware-Blechen? Bei KVM ist bekannt, dass man das Offloading abschalten muss.
Weiß jemand, was man da bei VMware tun muss oder kann? Wir haben zwei Bleche die mehr als einmal wöchentlich einfrieren (also die Bleche und nicht nur die Gateway-VMs). Sind beides VMware-Bleche und auf beiden läuft ein Gateway mit L2TP-VPN. Da VMware ansonsten eigentlich den Ruf hat, sehr stabil zu sein, hab ich mir das Offloadingproblem im Verdacht.
Grüße
Matthias
Nur sicherheitshalber gefragt: Ihr hängt die L2TP-Tunnel in eine Bridge oder direkt auf den Batman. Letzteres ist ja bei vielen nur bedingt stabil.
Wir betreiben 4 ESX Hosts und dort läuft alles mit L2TP stabil.
Dass euer gesamtes blech einfriert ist ja schon trivial. Das sind nicht zufällig i7 Prozessoren?
Genau.
Doch… Eins der Bleche ist ein i7-3770 das andere weiß ich grad nicht…
Habt ihr mal per KVM geguckt ob ihr einen „Pink screen of death“ habt?
Ist das ein 6.x ESXi ?
Grüße
@Comacho, habe das gerade kurz gegooglet, aber man findet leider sehr viel in Bezug auf ESXi und i7, was ist da die Problematik? Ich gehe davon aus, dass das beides i7-Kerne sein werden, weil es beides Kisten aus der Hetzner-Server-Börse sind.
Bzgl. dieser pinken Fehlermeldung meinst du auf dem Blech, nehme ich an? Ist das der Bluescreen von ESXi?
Ja das ist quasi der BlueScreen vom ESX.
Unser VMWare Spezi sagte mir, als ich ihm das hier erzählte, das bei einigen älteren i7
ein Microcode Update nötig ist. Das Problem soll aber nur ab der 6.x ESX reihe auftreten,
da es wohl mit neueren VM-Kerneln ein Problem gibt im Zusammenhang mit diesen älteren i7.
Aber helfen würde ein Scrnr vom Pink Screen 
Gruß
Dass die Offloading-Features bei SDN nicht so geil sind hat aber nur bedingt etwas mit unserem damaligen Problem zutun. Damals traten die Probleme im konkreten Zusammenhang mit dem r8169 Treiber auf. Die selbe Hardware mit dem r8168 lief* (bzw. auch mit r8169 und einem neueren Kernel → damit auch neuere Version des r8169). Bei anderer (Netzwerk-)Hardware konnten wir die Probleme nicht beobachten. Es war also schlichtweg ein Bug in einem einzelnen Treiber; daher würde ich das jetzt nicht als die wahrscheinlichste Ursache annehmen.
Hast zu ggf. den Eintrag aus der knowledge base zur Hand? Dann könnte @vax schauen, ob der Prozesssor potentiell betroffen ist, ohne auf den nächsten Absturz warten zu müssen.