Host-Only / NAT: Interface UNKOWN (OpenSUSE11.3 / VM 7.1.0)

[Dayworker]

Normalerweise schon, allerdings könnte deine Suse da schon wieder eine Sonderbehandlung brauchen.
Unter Windows gibt es dafür auch "vmnetcfg". Keine Ahnung ob VMware da für Linux inzwischen gleichwertiges im Programm hat oder ob du wie bisher auch die betreffenden conf-Dateien immer noch von Hand anpassen mußt. Allerdings sollten grundlegende Einstellungen der vmnetX auch über das Script "vmware-config.pl" getätigt werden können.

Ich kann aus den VMs die Addresse *.1 des vmnet1 erreichen. Aber keine dahinter liegenden Addressen. Vom VMware-Host kann ich alle VMs in vmnet1 erreichen. Das kann ich aber nicht von einem anderen Host. Von dort komme ich nur bis *.1

Das ist ja der Sinn eines Hostonly-Netzes. Du unterhältst damit ein separates Netz mit dem Host und daher hat der Gast ohne manuellen Routingeingriff auch keine Internetverbindung. Falls du über einen Router gehen willst/mußt, muß der dafür verwendete IP-Bereich auch dem Router bekannt gegeben werden. Andernfalls kennt der Router das private Netz nicht.

[Dayworker]

Kein Kabel angeschlossen.
Schau mal in Yast nach, ob du die vmnetX-Nic auf "immer aktiv" gesetzt bekommst oder die Automatik bei Kabelanschluß ausschalten kannst.

Ansonsten mußt du wahrscheinlich warten, bis die Workstation an Suse11.3 und dessen neuen Kernel angepaßt wurde. Darauf deuten auch die vielen "failed" Meldungen hin:

Virtual machine monitorfailed
Virtual machine communication interfacefailed
VM communication interface socket familyfailed
Blocking file systemfailed
Virtual ethernetfailed

[Dayworker]

Closed Source. Die Sourcen stehen zwar auch auf der VMware-Seite bereit, vermutlich allerdings nur die ursprünglichen und ob die vollständig sind oder überhaupt sämtliche seitdem gemachten Anpassungen enthalten, entzieht sich meiner Kenntnis. Dir würden jedoch auch nicht nur die vmnetX-Sourcen ausreichen. Virtual machine monitor ...failed und Virtual machine communication interface ...failed sind elementare VMware-Dienste/Damons. Daher kann die WS überhaupt nicht vollständig installiert sein bzw die Kernel-Module sind überhaupt nicht passend zum Kernel kompiliert worden. Da hilft entweder wirklich nur warten auf eine neue WS-Version, die mit deiner Kernel-Version umgehen kann oder nach entsprechenden Patches Auschau zu halten. Sehr bekannt sind da die privat gepflegten VMware-Any-Any-Patches oder der Distributor hat selbst was passendes zusammengestellt.

Alles in allem läßt sich zu Linux sagen, daß es wie immer das gleiche Spiel ist. Neue HW wird immer nur durch einen neuen Kernel unterstützt, Treiber-EW abseits des Kernels findet so gut wie nicht statt und ältere SW braucht immer eine Anpassung an die mit jeder Kernel-Version geänderten Kernel-Schnittstellen. Damit ist also nur solche SW problemlos noch auf neueren Kernelversionen lauffähig, die auch von den Kernel-Hackern mit gepflegt wird. Damit scheidet schon mal jede propitäre SW aus.

[Dayworker]

Schieb die Schuld für solche Probleme nicht komplett VMware zu, es gibt auf anderen Systemwelten genug ClosedSource-SW und die funktioniert dort auch.
Einzig die Kernel-Hacker mit ihren ständigen Änderungen an den Kernel-Schnittstellen verursachen hier den größten Ärger, jede neue Kernel-Version stellt eigentlich ein neues OS dar und muß daher wieder geprüft und ggf angepaßt werden.

[minimike]

Auf Wunsch eines nun ehemaligen Mitgliedes wurden dessen Beiträge gelöscht.

Darko Hojnik (Co Admin)

[Dayworker]

Ich sitz grad darüber kopfschüttelnder Weise am Rechner und bin echt immer wieder erstaunt, wie sich Linux-Jünger an immer neuen Kernel-Versionen aufgeilen können. Zumal neue Kernel mit KVM ja inzwischen auch eine mit dem Kernel gepflegte Virtualisierungslösung mitbringen...