Host-Zugriff auf laufende virtuelle Maschine(ping) scheitert

[tmarkl]

Hallo,
habe eine Frage: Ich betreibe eine Virtuelle Maschine (vmware) mit Windows Server 2008 als Image.
Nun wollte ich von meinem Host-Betriebssystem (Windows 7 home premium) per vpn auf das VMWare-Image zugreifen.
Um die IP-vom VMware image herauszufinden, habe ich es gestartet und dann im Windows Server 2008 die CMD ipconfig eingegeben und dann eine IP-Adresse bekommen z. B. "4711".
Als ich dann im Host Windows 7 einen ping auf die IP-Adresse "4711"ausführen wollte, kam ein Timeout. Ich kann also vom Host auf das VMWare Image so nicht zugreifen.
Nun habe ich im Host Windows 7 einen ipconfig ausgeführt und dabei die verfügbaren IP-Adressen im Netwerk angezeigt bekommen. Es zeigt einen Loopback adapter an und VMNet1 und VWNet2. Diese haben aber jeweils andere IP-Adressen als das VMWare-Image mit Windows Server 2008.

Meine Fragen:
- Was ist der Loopback adapter?
- Warum bekomme ich beim IPconfig nicht die Adresse der Virtuellen Maschine mit Windows Server 2008 angezeigt (IP-Adresse 4711)?
- Warum funktioniert der Ping vom Host auf die laufende VMware Maschine mit Windows Server 2008 (IP-Adresse 4711) nicht? Firewall ist im Windows 2008 Server nicht aktiv.

Vielen Dank im voraus für euren Input.

[Dayworker]

Sämtliche Windows-Version mit Firewall sprich alles seit XPSP2 antwortet standardmäßig auf keine sogenannten ICMP-Anfragen. Ein Ping muß daher scheitern.

Welches VMware-Netzwerkinterface hast du der VM gegeben?
Wieviele Netzwerkkarten hast du im Host?
Hier gehen keine Dateianhänge, VERLINKE daher bitte mal das ungekürzte "vmware.log" aus dem VM-Ordner auf einen Freehoster.

[mbreidenbach]

Bitte mal Ausgabe von ipconfig /all vom Host und vom Gast posten. Mit richtigen echten IP Adressen.

http://de.wikipedia.org/wiki/Loopback

[tmarkl]

Vielen Dank für Eure Antworten. Bevor ich hier umfangreiche Dokumente hochlade, teile ich euch meine neuesten Erkenntnisse mit.
Das VM-Ware Image besitzt einen Netwerk-Adapter "Loopback" Adapter mit dem Zweck, die IP-Adresse nicht dynamisch zu beziehen, sondern immer fest auf die IP-Adresse XY zu verweisen.
Nun habe ich auf meinen Host-System auch eine Netwerk-Komponente "Loopback", die ich nun auf die IP-Adresse XY des VMWare Images geändert habe.
Außerdem habe ich geprüft, daß der Loopback Adapter am Host "Bridged Network" verwendet und das VMWare-Image ebenfalls "Network-Adapter = Bridged" verwendet.

Dadurch wurde ein ping vom host auf die IP-Adresse XY möglich. Dennoch scheint es, als ob ich trotz des erfolgreichen ping nicht auf die IP-Adresse XY zugreifen kann. Hintergrund: Auf dem VM-Ware Image läuft eine SAP-Netweaver Trial Instanz, die ich mittels SAPlogon vom VM-Ware-Image über die IP-Adresse XY erfolgreich erreichen kann, aber außerhalb (vom Host mit den gleichen Saplogon-Einstellungen (IP-Adresse...) nicht.

Wie kann ich überprüfen, ob der Host auf die IP-Adresse XY wirklich Zugriff hat?

Gerne schicke ich euch meine Protokolle.

Thomas

[~thc]

Die feste Zuweisung einer IP-Adresse hat nichts mit dem Adaptertyp zu tun.
Meinst du den "Microsoft Loopback Adapter" als Netzwerkkarte? Warum soll dieser zum Einsatz kommen?
Du gibst dem Host-Loopback-Adapter die gleiche IP-Adresse wie dem Loopback-Adapter der VM?
Das ist kaum nachvollziehbar.

[tmarkl]

Hallo,
die Sache mit dem Loopback-Adapter war doof von mir. Der Loopback-Adapter kommt daher zum Einsatz, weil ich in einem nicht netzerkfähigem Betriebssystem innerhalb diesem Betriebssystems z. B. Win 7 home eine Netwerkanwendung z. B. SAP-Netweaver Trial betreiben möchte. Der Loopback-Adapter ermöglicht das Betreiben einer Netwerkanwendung im gleichen Betriebssystem, ohne daß man also ein Netzwerk hat.

Aber nun zu meinem Problem. Wenn ich in meiner VM-Ware Maschine als Netwerk = BRIDGED ausgewählt habe, findet die Kommunikation der VMWare über VMnet0 statt, die dazu meine HOST-LAN-IP-Adresse haben muß.
- Da ich kein DCHP in der VMWare-Maschinehabe, muß ich diese wohl manuell zuordnen, oder? (VMWare-Virtual Network Editor?)
- Im meinen ipconfig /all protokoll vom Host finde ich keine IP vom Netzwerkadapter. Folgendes steht im ipconfig-Protokoll:

Ethernet-Adapter LAN-Verbindung:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physikalische Adresse . . . . . . : 38-60-77-E5-6C-C9
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja

Kann es sein, daß die ganze Geschichte mit Verbindung Host-Guest über Bridged VMNet0 deshalb nicht funktioniert, weil der dabei angesprochener Netwerkadapter (Realtek PCle GBE Family Controller) disabled ist (Medium getrennt; keine IP-Adresse)?

vielen Dank im voraus für Eure Infos.

[~thc]

EIne VM mit "Bridged"-Netzwerkanschluss ist eigentlich dazu gedacht, von außerhalb der Host-Maschine aus dem Netzwerk heraus erreichbar zu sein. Deine Host-Netzwerkkarte ist nicht mit einem Switch verbunden - also mach das keinen Sinn.

Wenn du nur von deinem Host aus deine VM über das Netz erreichen willst, das ist das "Host-Only"-Netzwerk dein Freund. Über ipconfig findest du die IP-Adresse des Hosts und deine VM bekommt per DHCP (ist per Standard aktiv) von der VMWare eine passende IP aus dem selben Subnetz.

[tmarkl]

Hallo, Danke für Deine Antwort, aber könntest du mir das noch genauer erklären, was ich zu tun habe?
Das ist das ipconfig von meinem Rechner.

Windows-IP-Konfiguration

Hostname . . . . . . . . . . . . : thma1-PC1
Prim„res DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : fritz.box

Ethernet-Adapter LAN-Verbindung* 4:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Check Point Virtual Network Adapter For Endpoint VPN Client
Physikalische Adresse . . . . . . : 54-FC-CC-BE-3A-14
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja

Ethernet-Adapter Loopback-Adapter:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft Loopbackadapter
Physikalische Adresse . . . . . . : 02-00-4C-4F-4F-50
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::5856:39b5:ff73:459a%19(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.74.1(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 0.0.0.0
DHCPv6-IAID . . . . . . . . . . . : 386007116
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-67-50-CF-4C-80-93-07-41-F3
DNS-Server . . . . . . . . . . . : 192.168.238.1
NetBIOS ￾ber TCP/IP . . . . . . . : Aktiviert

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 3:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter #2
Physikalische Adresse . . . . . . : 4C-80-93-07-41-F4
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 2:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter
Physikalische Adresse . . . . . . : 4C-80-93-07-41-F4
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Ethernet-Adapter LAN-Verbindung:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physikalische Adresse . . . . . . : 38-60-77-E5-6C-C9
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung:

Verbindungsspezifisches DNS-Suffix: fritz.box
Beschreibung. . . . . . . . . . . : Intel(R) Centrino(R) Wireless-N 1030
Physikalische Adresse . . . . . . : 4C-80-93-07-41-F3
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::898b:d769:93fa:c37e%14(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.158.25(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Mittwoch, 18. Dezember 2013 18:26:20
Lease l„uft ab. . . . . . . . . . : Samstag, 28. Dezember 2013 18:26:17
Standardgateway . . . . . . . . . : 192.168.178.1
DHCP-Server . . . . . . . . . . . : 192.168.178.1
DHCPv6-IAID . . . . . . . . . . . : 369104128
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-67-50-CF-4C-80-93-07-41-F3
DNS-Server . . . . . . . . . . . : 192.168.178.1
NetBIOS ￾ber TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter VMware Network Adapter VMnet1:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet1
Physikalische Adresse . . . . . . : 00-50-56-C0-00-01
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::c57a:159:82c7:54ad%21(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.32.1(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 318787670
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-67-50-CF-4C-80-93-07-41-F3
DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS ￾ber TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter VMware Network Adapter VMnet8:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet8
Physikalische Adresse . . . . . . : 00-50-56-C0-00-08
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::3898:88aa:c0a4:a99e%22(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.247.1(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 335564886
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-16-67-50-CF-4C-80-93-07-41-F3
DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS ￾ber TCP/IP . . . . . . . : Aktiviert

Tunneladapter isatap.{80F2AE63-7F46-483E-AAE6-090D4FFC19D7}:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Tunneladapter Teredo Tunneling Pseudo-Interface:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.fritz.box:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix: fritz.box
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #4
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{356B88AC-FA3A-4E35-A317-B0122A450E59}:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #6
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{230F8110-97B1-4488-B236-03C01F5111C0}:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #8
Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja

[Dayworker]

Wenn ich deine vielen Netzwerkadapter so sehe, solltest du da dringendst mal aufräumen. Ich kann dir jetzt nicht mal sagen, wie die Workstation darauf reagiert und NAT bzw Host-only einrichtet, wenn keine Nic aktiv ist. Bei einem älteren VMware-Produkt war ohne wenigstens eine funktionale Netzwerkkarte (Nic aktiv und mit Router bzw Switch über Lan oder WLan verbunden) an dieser Stelle das Ende erreicht und mit vielen Nics wird die Config für NAT und Host-only schwierig. Diese beiden VMware-Netzwerkinterfaces brauchen in jedem Fall einen sich von deinen restlichen, genutzten IP-Bereichen sich unterscheidenden, eigenen IP-Bereich. Andernfalls funktioniert das Routing zwischen Host und den Gästen (VMs) nicht.

[~thc]

Weise deiner VM über die Konfiguration den Netzwerktyp "Host-Only" zu.

Dann sollte sie beim Start von der VMWare WS eine DHCP-Adresse aus dem gleichen Subnetz wie "VMNet1" auf dem Host zugewiesen bekommen - wichtig dabei ist, dass die VM nur die normale, für sie physische Netzwerkkarte besitzt - keinen Loopback-Adapter.

Wenn du in der VM

Code: Alles auswählen

ipconfig /all

ausführst, sollte die Netzwerkkarte der VM eine IP-Adresse im Bereich 192.168.32.x bekommen haben.

Dann kannst du vom Host aus auf die VM über diese Adresse zugreifen. Von der VM aus erreichst du den Host unter 192.168.32.1.

[tmarkl]

Hallo ~thc, ich werde es probieren. Allerdings weiß ich nicht, ob die VMWare eine normale Netzwerkkarte besitzt. Die IP, die ich benötige, kommt aus dem Loopback-Adapter des VMWare-Images. Der Loopback-Adapter ist dafür da, damit ich innerhalb des VMWare Images mit einem Saplogon auf ein SAP-Netweaver zugreifen kann, was im gleichen System nur mit Loopback-Adapter geht.

[~thc]

Dann musst du die normale Karte der VM parallel zum Loopback-Adapter betreiben, aber du wirst die VM dann von deinem Host aus nur auf der physischen Karte der VM erreichen.

Den Loopback-Adapter der VM kannst du von "außen" (Host) nie erreichen, da sie eine virtuelle Karte des VM-Betriebssystems ist.

[tmarkl]

Hallo thc,
mein Problem ist, daß ich genau auf die ip-adresse 192.168.75 vom lapptop aus auf die virtuelle Maschine zugreifen muß, weil unter dieser IP-Adresse im vmware image ein SAP-System zu erreichen ist. Das blöde dabei ist, daß im vmware image diese IP-Adresse einem Loopback-Adapter zugewiesen ist.
Als Anlage habe ich mal was in die Dropbox hochgeladen, das vmware-Log und ipconfig von host und guest.Vielleicht hilft euch das weiter.


https://dl.dropboxusercontent.com/u/542 ... guest.docx

https://dl.dropboxusercontent.com/u/542 ... 012014.txt

[Dayworker]

Ausgehend von deinem "vmware.log" ist bei dir als Gast-OS winnetenterprise-64 bzw Windows Server 2003 Enterprise x64 Edition eingestellt. Wie kommst du da auf Server 2008?
Deine DOCX-Datei kann und will ich mir nicht ansehen, ich habe weder ein Office 2007 oder neuer noch will ich mich mit einer Inst desselben belasten.


Der einzigste Grund, weshalb man im Gast mit dem Loopback-Adapter rumfummelt, dürfte sein, wenn der Gast keine Netzwerkkarte bekommen soll, was sehr ungeschickt ist (*1), und ein Programm im Gast aber eine feste IP voraussetzt. Dann wäre aber die vergebene e1000-Nic in der VM-Config unnötig... Mir erschließt sich in diesem Zusammenhang auch nicht, weshalb du ein Server-Gast mit Bluetooth und Sound behelligst. BT unter W2k3 war meist ein Gefrickel und Sound ist per Default in den Diensten abgeschaltet.

Den Loopback-Adapter im Host würde ich daher direkt wieder löschen, damit kannst du nichts anfangen. Dann konfiguriere dein "Intel(R) Centrino(R) Wireless-N 1030" im "VMware Network Editor" bzw über "vmnetcfg.exe" als VMnet0, hoffentlich läßt das Centrino-Modul den Promiscuous-Mode zu, nimm den Haken bei Auto-Bridging/Detect raus und gib der VM dann Host-only. Damit solltest du die VM dann erreichen. Falls das nicht klappt, könnte sich aus deiner DOCX-Datei ergeben, solltest du in der FritzBox, und darauf deutet die IP-Adresse 192.168.178.1 hin, eine feste Route von deiner Centrino-IP 192.168.158.0 auf die 192.168.32.1 des VMnet1 setzen.


*1)
VMware kommuniziert seit ewigen Zeiten für die Arbeit in einer VM immer die GastOS-Beugaben sprich VNC, SSH oder RDP zu nutzen und die VMware-Console ausschließlich für administrative Arbeiten sprich Tools- oder GastOS-Inst zu verwenden.

[~thc]

Ist der Loopback-Adapter in der VM technisch notwendig für die SAP-Umgebung? Du kannst ja stattdessen dem "richtigen" virtuellen Netzwerkadapter (Intel PRO/1000 MT) auch diese IP zuweisen, wenn du willst.

[Dayworker]

Vermutlich schon, aber rein die IP würde sich ja auch über die Datei "hosts" anpinnen lassen und die VM hat ja bereits eine e1000-Nic.
Keine Ahnung, was der TO in seinem DOCX-Kram verpackt hat. Einfach ASCII-Dateien, JPGs oder auch PDFs von Host und Gast würden uns hier weiter bringen, als sich erst noch mit M$-Dateien auseinandersetzen zu müssen.

In meinen Augen ist sein Problem, daß diese unsägliche Auto-Bridging/Detect-Geschichte aktiv ist, sein VMware-Host über mehr als eine Netzwerkverbindung verfügt und das Routing dann zufällig über irgendeine davon ausgeführt wird. Ich kann aus dem "vmware.log" nicht einmal herauslesen, welches VMnetX er der VM überhaupt gegeben hat...

[tmarkl]

Hallo Dayworker und thc, vielen Dank schon mal für eure Hilfe.

Ja, das VM-ware-Betriebssystem ist Windows Server 2003 Enterprise x64 Edition.

Der Loopback-Adapter hat den Zweck, daß ein Programm im Gast immer die gleiche IP-Adresse bekommen soll. Bei dem Programm im Gast handelt es sich um ein SAP-NW-Demo-System, das vom SAPlogon immer unter der gleichen IP-Adresse zu erreichen ist.

Ein Problem bei der Geschichte ist also, daß die IP-Adresse, die ich in der vmware anpingen möchte, ein Loopback-Adapter im VMWare-Image ist. Einen Loopback-Adapter kann ich aber nie anpingen, weil er ein Dead-End ist.
Somit besteht die Aufgabe darin, den Bridge Network im Host-System mit den VM-Ware-Settings im Gast Betriebssystem einzustellen. Dann wird die IP-Adresse der VMWare automatisch in die des Host-OS zugewiesen und ein ping bzw. Zugiff über Host-Saplogon auf das SAP-NW-Trial des Guest-OS ist möglich.

Der Grund, warum ich Bridge Networking verwenden möchte, ist, daß ich im Gegensatz zu NAT etc keine IP-Adressen der VMWare manuell zuweisen muß, sondern daß diese VMWare IPs automatisch über die NIC an das Host-OS übertragen werden. Dazu muß aber auch im Host das Auto-Briding für die NIC (Realtek PCIe Family controller) richtig konfiguriert sein und das ist wohl das Problem dabei.

Ich habe nun das Word-Dokument in ein für Dayworker (hoffentlich) kompatibles PDF-Format umgewandelt Es enthält ipconfigs von host und guest und auch die Virtual Network Einstellungen der VMWare.

Eine Frage habe ich noch vorab an Dayworker: Warum soll die Verbindung von Host zu Guest über die Intel Centrino Wireless laufen? Da hängt mein Internet dran (Fritzbox). Ich habe in meinen Hardwareeinstellungen nachgesehen und die eigentliche LAN-Netzwerkkomponente im Host ist doch der Realtek PCIe BGE Family Controller. Dieser taucht auch in den Bridging-Einstellungen im Virtual Network Editor der VMWare auf (siehe PDF) und über diesen würde ich auch gerne die Verbindung von Host zu Guest laufen lassen. Aus meiner (sicherlich etwas laienhaften) Sicht ist das Auto-Bridging im Guest (VMWare) richtig eingestellt. Was jetzt eingestellt werden muß ist der Host, so daß er sich mit dem Guest über das Auto-Bridging verbinden kann. Ich hoffe, ihr könnt mir mittels des PDF mehr Anleitung dazu geben?

https://dl.dropboxusercontent.com/u/542 ... 6guest.pdf

[Dayworker]

Ohne mir das PDF jetzt angesehen zu haben, kann ich dir gleich sagen, daß das Auto-Bridging/Detect nur mit einer Nic zuverlässig funktioniert
Sobald mehrere Nic's in einem Rechner stecken, ist ansonsten die Wahl der Nic für das VMnet0 = Bridging reine Glückssache und kann sich bei jedem Host-Reboot verändern. Du hast mit aktivem Auto-Bridging/Detect keine Möglichkeit diese Reihenfolge zu beeinflussen. Wenn die VMware-Bridge dabei auf eine nichtangeschlossene Nic fällt, sind NAT und Host-only ebenfalls komplett unterbrochen. Falls du mehrere aktive Nic's im Rechner hast, wird es sogar noch wichtiger, daß du dort eine feste Zuordnung triffst und diese nachher über das Custom-Interface auch so an die jeweilige VMs weiterreichst. Andernfalls kann es dir passieren, daß ohne feste Zuordnung einer Nic zu einem VMware-Netzwerk-Interface sprich VMnetX eine VM ungewollt für die Welt offen ist oder du mit unerklärlichen Verbindungsproblemen zu kämpfen hast.

JA wir wissen auch nicht, weshalb VMware noch immer Auto-Bridging/Detect in alle seine Desktopprodukte integriert, obwohl es nachweislich nicht zuverlässig funktioniert.

Für NAT und Host-only muß man keine IP-adressen manuell zuweisen. Dafür ist bei sämtlichen VMware-Desktopprodukten ein VMware-DHCP-Server installiert, den man dann im "VMware Nwetzwerk Editor" bzw "vmnetcfg.exe" nur noch aktivieren muß. Selbst der IP-Bereich für diese beiden VMware-Netzwerkinterface-Typen ist konfigurierbar.

Wenn du deine Realtek-Nic nutzen willst, muß diese auch mit einem Switch oder Router verbunden sein oder die Karte bleibt abgeschaltet und ist nicht für VMware ansprechbar.


Dein PDF sehe ich mir noch an...

[Dayworker]

Sorry, daß wird jetzt noch richtig viel Schreibarbeit werden...



Wie ich bereits geschrieben hatte, ist die VM-Einstellung "Bridged" in deinem PDF auf Seite 2 kontraproduktiv, wenn du mehrere Nic's im Host und Auto-Detect/Bridging aktiviert hast.
Auf derselben Seite im zweiten CMD-Fenster siehst du dann auch, weshalb du die VM nicht unter deiner Wunsch-IP "192.168.75.1" anpingen kannst. Dort ist unter "Ethernet adapter Local Area Connection 2" für die Intel 1000MT der Apipa-Bereich 169.254.X.Y eingetragen und dies passiert immer dann, wenn eine Nic keine IP über DHCP bekommen kann. Schuld daran ist der Umstand, daß deine Realtek-Nic keine Verbindung zu einem Router/Switch hat und du trotz mehrerer Nic's im Host dieses dusselige Auto-Detect/Bridging aktiviert hast. Deine VM wird höchstens dann erreichbar sein, wenn du entweder die im PDF auf Seite 2 im zweiten CMD-Fenster genannte vollständige IP nutzt oder falls das nicht klappt, zusätzlich in deiner FritzBox noch eine feste Route auf die 169.254.0.0 mit Netzmaske 255.255.0.0 von deiner im Host genutzten IP-Adresse anlegst. Allerdings könnte es auch sein, daß der Apipa-Adressbereich überhaupt nicht gerootet wird und dann ist die VM von aussen trotzdem nicht erreichbar...


Die einfachste Lösung ist daher, einfach in jedem Fall das Auto-Detect/Bridging zu deaktivieren, das VMnet0 = Bridge auf das Centrino-Wlan zu legen, dann würden auch NAT und Host-only darüber funktional abgebildet werden und die Realtek-Nic komplett aussen vor zu lassen oder diese auf ein noch freies VMnetX (2-7 oder 9-10) zu legen. Wenn du die VM aber aus IP-Bereichsgründen über die Realtek-Nic laufen lassen willst, muß diese mit einem Router oder Switch eine Verbindung haben und das Centrino-WLan würde ich dann auf ein noch freies VMnetX (2-7 oder 9-10) legen. Die VMnet0 = Bridge, VMnet1 = Host-only und VMnet8 = NAT würde ich nur im Notfall umkonfigurieren, wenn du wirklich mehr als 10 verschiedene VMware-Netzwerkinterfaces brauchst. Je nach Player-standalone oder Workstation/Player-Version werden sogar mehr als 10 VMnetX unterstützt, was eine Umkonfiguration der bereits vorbelegten VMnetX noch unnötiger macht und dir im Fehlerfall nur Achselzucken beschert, wenn du deine VMnetX-Config dann nicht bis ins letzte Detail beschreibst. Jeder geht ansonsten bei VMware-Desktopprodukten davon aus, daß VMnet0 = Bridge, VMnet1 = Host-only und VMnet8 = NAT ist.

In jedem Fall solltest du die VM, wie im PDF Seite 2 in den "Virtual Machine Settings" ersichtlich, auch mit dem "Custom: Specific virtual network" ausstatten und dann im darunter befindlichen Auswahlmenu das mit der gewünschten Nic verbundene Bridge-Device einstellen. Wenn du das nicht manuell, sondern, wie momentan dort eingestellt, über "Bridged: Connected directly to the physical network" machst, drehst du dich wieder im Kreis und die VM wird Verbindungprobleme haben. Die Bridged-Einstellung sucht sich einfach wieder irgendein Host-Netzwerkgerät und dabei ist es ihm wieder völlig egal, ob dieses überhaupt mit einem "Medium" verbunden ist.


Wie du daran siehst, ist "Auto-Detect/Bridging" bei mehreren Host-Netzwerkgeräten (Lan- oder WLan spielt da keine Rolle) völlig kontraproduktiv.

Wer hat dir eigentlich diese VM so konfiguriert und ohne weitere Hinweise übergeben
Denjenigen würde ich mal fragen, welche VMware-Netzwerkconfig er genau am Laufen hatte und wie er das konfiguriert hat.
In meinen Augen wäre es leichter gewesen, die virtuelle Intel 1000MT fest auf die IP 192.168.75.1 mit Netzwerkmaske 255.255.0.0 bei DNS auf 192.168.178.1 zu setzen und sowohl der FritzBox als auch dem Host dieselbe Netzwerkmaske 255.255.0.0 zuzuweisen. Sobald du dann bei deaktiviertem "Auto-Detect/Bridging" das Centrino-WLan mit dem VMnet0 = Bridge verbindest, würde deine FritzBox direkt die SAP-VM als neuen LAN-Teilnehmer sehen (weshalb die VM dann über Centrino-WLan in der FritzBox trotzdem als LAN- und nicht als WLan-Gerät eingeloggt wird, würde hier zuweit sein und kann ich dir gern mal in einem anderen Thread erklären...) und somit wäre die VM auch über den DNS-Namen "eccehp5" im gesamten FritzBox-Netzwerk erreichbar.

[tmarkl]

Hallo,
vielen Dank nochmals für die Antworten. Ich habe das Problem jetzt gelöst. Wie ich anfangs schon dachte, lag das Problem an der IP-Adresse des Guest-Systems. Dort war die IP-Adresse, auf die ich vom Host zugreifen wollte, auf einen Loopback-Adapter eingestellt. Doch ein Loopback-Adapter kann von außen (Host) nicht angepingt werden. Daher ist auch der Ping vom Host auf diese IP gescheitert.

=> Eine Verbindung Host zu Guest-System funktioniert unabhängig von dem Verbindungstyp (Bridged; NAT) nur dann, wenn ich die Guest-IP vom Host aus auch anpingen kann - und das war wegen dem Loopback-Adapter nicht möglich (s. o.).

Was habe ich gemacht. Ich habe das VMWare-Image + alle Systeme darauf nochmals neu eingerichtet und die Guest-Anwendungs-IP-Adresse von Loopback-Adapter auf LAN2 gerichtet. Dann konnte ich die Guest- IP-Adresse problemlos vom Host aus pingen und mich darauf verbinden. Ich habe bei der VM-Ware den Verbindungstyp "Bridged" gelassen, weil ich damit ohne irgendwelche weiteren Einrichtungsarbeiten sofort mit arbeiten kann.

Viele Grüße

Thomas