Hostsystem Gentoo AMD64, GSX 3.2 Netzwerkprobleme bei NAT

[squadra]

Hallo

ich habe auf einem Gentoo 64Bit System den GSX 3.2 aufgesetzt, was auch soweit einwandfrei funktioniert. Bei dem Gastsystem handelt es sich um eine Windows XP Pro Installation die über NAT ins Internet connected. Sämtliche ausgehenden Verbindungen wie z.b. Http oder FTP Downloads funktionieren einwandfrei, jedoch sobald eine ausgehende Verbindung aufgebaut wird (FTP Upload z.b.) bricht die Transferrate auf ein Minimum ein. Max-Speed ist dann 32kb, jedoch "pumpt" das ganze 0kb - 30kb - 0kb usw...

Ich habe bereits Stundenlang in den US VMware Foren gesucht, es werden auch teils ähnliche Probleme beschrieben, allerdings konnte ich keine Lösung finden.

Die Hostkonfiguration:

Gentoo AMD64
Kernel 2.6.13 (wurde allerdings auch mit niedrigeren Kernelversionen getestet ohne Erfolg
vmlance und vmx NIC Treiber getestet, kein Unterschied!
vm-tools Installiert


In den Systemlogs kann ich weiter nichts auffälliges finden ausser:

/dev/vmmon[4967]: fast clock rate 0 -> 19
/dev/vmmon[4967]: fast clock rate 19 -> 83
/dev/vmmon[4967]: fast clock rate 83 -> 84
vmmon: Had to deallocate locked 115259 pages from vm driver ffff810079f7c000
vmmon: Had to deallocate AWE 3711 pages from vm driver ffff810079f7c000

was ich nicht wirklich zuordnen kann...


Eine Bridged Verbindung kann ich leider nicht aufbauen da sich die Maschine bei einem Provider befindet und die IP´s die ich dort benutze an die MAC des Servers gebunden sind. Weitere MAC´s kann oder will mir der ISP nicht eintragen.

Vielleicht hat von euch jemand eine Idee?

[squadra]

Ich hab das gleiche jetzt mal auf einem 32Bit Debian Host getestet, selbes Problem... *verzweifel*

[minimike]

Hmm läuft deine Hostnic mit Autonegotation ? Versuch evtl mal die Geschwindigkeit festzusetzen. Vorsicht evtl kappt das die Netzwerkverbindung! Dann wird ein teurer Anruf beim Dienstleister fällig. Evtl auch mal preemtime oder andere Varianten von Clocking im Kernel probieren. Sind nur schüsse ins Blaue!

[squadra]

Das mit autonegation werd ich versuchen, selbst falls die Maschine nicht erreichbar sein sollte ist das kein Problem da ich diesen Remote rebooten kann.

Mit den Kerneloptionen die du angesprochen hast kann ich allerdings nicht viel anfangen, gibts dazu irgendwo Doku oder eine Beschreibung?

[minimike]

In den Kernelsourcen steht in der Doku was über Premtime. Es gibt aber noch weitere Projekte die Latenszeit des Kernels zu minimieren. Es ist nur eine Vermutung anhand der von dier geposteten Fehlermeldung. In Con Kolivas Patchset ist was nettes hierfür mit dabei.
http://members.optusnet.com.au/ckolivas/kernel/

[squadra]

Nun, den eigentlichen Fehler hab ich zwar nicht gefunden, nachdem dieses Problem auf verschiedenen Hostsystemen (unterschiedliche Hardware/Distributionen) reproduzierbar war, denke ich das das wohl einfach ein allgemeiner Bug ist.

Aber mit einem "Dirty Workaround" hab ich das Problem nun doch in den Griff bekommen, und zwar hab ich auf dem Hostsystem einen FTP Bouncer aufgesetzt der an vmnet8 gebunden ist. Vom Guestsystem aus wird auf diesen Connected, der leitet dann den kompletten Datenstrom weiter, nicht nur die Control Verbindung.

Etwas unkonventionell, aber funktioniert