VBox 3.0.X - NATted Network, kein SSH-Zugriff im Headless Modus

[Rain_maker]

Ich habe hier ein ärgerliches Problem mit VirtualBox 3.0.x PUEL (sowohl 3.0.0 als auch 3.0.2 getestet).

Situation:

- Host: openSUSE 11.1 (i586 und x86_64, macht keinen Unterschied)

- Gäste: verschiedene Linuxdistributionen (openSUSE factory, grml, ...)

- Netzwerk über NAT (und Nein, ich möchte nicht auf Bridged o.ä. umstellen, es hat schliesslich auch mit den 2er Versionen von VBox problemlos funktioniert).

Symptome:

- Starte ich $GAST mittels GUI (VirtualBox+Klickklack oder VBoxSDL) so kann ich recht (auch das klappt nicht immer zu 100%, etwa 1-2 mal von 10 Versuchen geht auch das in die Hose) per SSH auf die virtuelle Maschine zugreifen.

Starte ich $GAST mittels VBoxHeadless, so schlägt der Zugriff per SSH fehl (gerade da, wo man ihn am ehesten brauchen würde *hmpf*).

Der entsprechende Port in Host und Gast ist offen (netstat, ausserdem funktioniert es ja in den anderen Modi, das Problem besteht wie gesagt nur im Headless Modus), es kommt auch keine Fehlermeldung, die Anmeldung landet ohne jegliche Rückmeldung einfach nur in einem Timeout.

Witzigerweise funktioniert aber der Zugriff über rdesktop, nur habe ich eben nicht immer X zur Verfügung, wenn ich auf eine der VMs will, von Sicherheitsaspekten mal ganz abgesehen.

Mit VBox 2.2.4 (und den Vorgängerversionen) ging das alles ohne Probleme, auch das "Allheilmittel" ~/.VirtualBox zu löschen und (alle! *röchel*) VMs neu einzurichten schaffte keine Abhilfe.

Ich bin zumindest vorübergehend wieder zurück auf 2.2.4, das hier soll auch weniger eine Anfrage nach Lösungen sein (wer eine hat, kann sich natürlich trotzdem melden), sondern vor allem auch ein Aufruf an Nutzer der 3.0.Xer Versionen, ob sie dieses Problem reproduzieren können.

Sollte dies der Fall sein, dann werde ich wieder die 3.0.X aufspielen und weiter nach Anhaltspunkten suchen.

Was ich nicht getestet habe (war mir dann zugegebenermassen zu doof) war die Umstellung von NAT auf Bridged/Host-only/*wasweißich*, ich habe bisher immer ohne Probleme NAT verwendet und möchte dies eigentlich auch weiter tun, vor allem wäre das nur ein Workaround und keine Lösung.

Die Frage lautet also:

Kann jemand dieses Verhalten reproduzieren?

(Gerne auch mit anderen Hostsystemen, um zu sehen, ob dieses Problem nur das Paket für openSUSE 11.1 oder auch andere betrifft.)

Greetz,

RM

[Rain_maker]

Heute wurde Version 3.0.4 veröffentlicht:

http://www.virtualbox.org/wiki/Changelog


NAT: using two or more NAT adapters in one VM was broken (3.0.0 regression)
NAT: fixed network communication corruptions (bugs #4499, #4540, #4591, #4604)
NAT: fixed passive ftp access to host server (bug #4427)

Das hörte sich nicht nur gut an, es scheint auch wirklich das zuvor beschriebene Problem der vorigen 3er-Versionen beseitigt zu haben. Bisher funktionierte es bei 10 Versuchen auch wirklich 10 mal, selbst wenn mehrere virtuelle Maschinen gleichzeitig liefen (jede natürlich auf einem anderen Port erreichbar).

Greetz,

RM

[Rain_maker]

Wäre ja auch zu schön gewesen.

Bis auf eine (sic!) Maschine funktioniert die Chose nun, openSUSE-Factory i586 zickt immer noch und das auf eine (neue) wundersame Weise.

Zunächst denkt man "liegt wohl am Gast-OS", aber wie erklärt man sich dann das hier?

- Starte ich die Maschine unter 3.0.4 mit NAT (egal in welchem Modus) und versuche per SSH zuzugreifen läuft der Verbindungsversuch in einen Timeout

- Starte ich die Maschine unter 3.0.4 mit Bridged Netzwerk auf wlan0 (oder eth0, wenn ich per Kabel online bin) => alles OK

- Starte ich die Maschine unter 3.0.4 mit NAT, greife anschliessend per rdesktop zu (oder beim Starten mit VirtualBox-GUI oder VBoxSDL direkt über das GUI-Fenster) und erzeuge minimalsten Netzwerktraffic (z.B. per "dig <irgendwas> eine einzige Abfrage, zypper ref, eigentlich alles ausser ping, was ja bei NAT nicht möglich ist), dann kann ich mich anschliessend einloggen, eine vorher "hängende" ssh-Anfrage zeigt mir direkt nach dem "Traffic erzeugen" die Abfrage der Key-Passhrase

- Last but not least, mit 2.2.4 alles kein Problem, egal welcher Modus, egal welche Art der Netzwerkeinrichtung, egal ob mit der "alten" Konfiguration oder der mittlerweile neu angelegten Konfiguration der VM

Alles irgendwie sehr seltsam, die Logs in ~./VirtualBox/Machines/<Name_der_Maschine>/ geben auch nicht gerade viel her, wobei ich mich da noch mal genauer einlesen muss, ob/wie man das beinflussen kann (debug oder allgemein höhere "Geschwätzigkeit" des Loggings).

[Rain_maker]

Nachdem es unter 3.0.8 einigermaßen (bis auf eben die eine VM) funktionierte, ging mit 3.0.10 mal wieder _gar nichts_ mehr, egal mit welcher virtuellen Maschine.

So bald man NAT (natürlich mit eingerichtetem Port Forwarding über VBoxManage, siehe Handbuch) als Setup hatte, war SSH-Zugriff nicht möglich, das ganze lief in einen Timeout und die SSH-Logs der jeweiligen VM zeigten keinerlei Verbindungsversuche, also kamen die Pakete nicht einmal am Ziel an.

"Lösen" konnte ich das Problem auf etwas ungewöhnliche Weise:

- Auswahl eines anderen Netzwerkadapters (Statt eine "Intel PRO/1000 MT Desktop" eine "Intel PRO/1000 MT Server", der Kerneltreiber für beide Karten ist eh der selbe, namentlich e1000.ko)

- Interface in der VM _unbedingt_ mit DHCP konfigurieren (feste IP wollte ums Verrecken nicht)

- Falls notwendig udev-Regeln in der virtuellen Maschine anpassen (damit aus eth1 wieder eth0 wird)

Das Mysteriöse daran ist, daß sonst keinerlei Probleme mit dem Netzwerk auftraten, so funktioniert(e) der Zugriff über RDP immer problemlos.

Irgendetwas ist mit der NAT-Implementierung seit VirtualBox 3.0.0 faul und jede neue Version wartete dabei mit anderen Überraschungen auf.

Hoffentlich war es das nun endgültig mit diesem Theater.

Greetz,

RM