dunkelhut
Goto Top

VMware - Gast und Gastgeber finden einander im Netz nicht, jeden anderen, nur nicht einander

Netzwerkproblem oder bekannte Einschränkung ?

Hallo,

ich habe die VMware Workstation auf Windows Server 2008 64Bit [german] laufen.
Ich nenne es mal hier den "Gastgeber".

Weiterhin habe ich eine Windows XP Maschine als "Gast" kreiert.

Der Gast läuft im Bridgemodus und nach anfänglichen "Würfelhusten" findet er das Netzwerk, geht online, alles soweit schick.

...aber er erreicht seinen eigenen Gastgeber nicht.

Weder über DNS noch über IP.

Die IP-Konfiguration (statisch) entspricht der des Gastgebers, nur die IP-Adresse ist verständlicherweise eine andere.
Der "Gast" erreicht das gesamte Netzwerk nur eben seinen "Gastgeber" nicht.

Laut VMware verfügt der "GAST" auch über seine eigene MAC-Adresse.

Warum können sich "Gast" und "Gastgeber" nicht sehen ?

Ich habe "nur" zwei Server und wenn ich den VMware Player auf dem DomainController installiere dann schieße ich mir ja selber ins Knie, kein DNS für den "Gast", etc.

Abgesehen davon rät VMware von eine Installation von VMware auf einem Domaincontroller ab.

Ist das was ich in dieser Konstellation erlebe ein Konfigurationsproblem von VMware oder ist es eine bekannte Einschränkung ?
Ich habe früher schon mit VMware gearbeitet, hatte aber genug Maschinen und da ist mir das nie aufgefallen.

Ich arbeite mit der VMware Workstation Version 6.5.2 build-156735 und den VMware Tools Version 7.8.5, build-156735

Vielleicht ist es ja auch nur etwas "Einfaches" und ich sehe den Wald vor lauter Bäumen nicht... face-wink

Danke im Vorraus für eure Unterstüzung
DunkelHut

Content-ID: 115632

Url: https://administrator.de/contentid/115632

Ausgedruckt am: 24.11.2024 um 04:11 Uhr

RoterFruchtZwerg
RoterFruchtZwerg 08.05.2009 um 19:54:46 Uhr
Goto Top
Eine bekannte Einschränkung ist es definitiv nicht, denn es sollte problemlos funktionieren.
Wie genau kannst du den Host denn nicht erreichen? Vielleicht ist es einfach ein Problem mit dessen Firewall?
Stell bitte erst mit einem dritten Netzteilnehmer fest, ob der Host auf Pings von anderen Clients im Netz antwortet und schau dann, ob der Host auch vom Gast aus über den Ping erreichbar ist.
Ich denke eigentlich nicht, dass es ein VMware Problem ist.
DunkelHut
DunkelHut 08.05.2009 um 20:07:54 Uhr
Goto Top
Danke für Deine Antwort.

Ich habe generell in diesem Netzwerk die Windows Firewalls abgeschaltet da wir durch eine gut konfigurierte Hardwarelösung aus Richtung WAN vor allem Möglichen beschützt und behütet werden.

Im LAN sind also die "Tore" offen.

Ein Ping-Test vom DomainController auf den "Gast" war erfolgreich.

Ein Ping zwischen "Gast" und "Gastgeber" scheitert in beiden Richtungen.

Mir ist auch nicht bekannt das man da so viel verstellen kann.

Bridge Ja / Nein steht bei mir auf Ja

Danke für eure Gedanken
Gruß
DunkelHut
RoterFruchtZwerg
RoterFruchtZwerg 08.05.2009 um 20:16:50 Uhr
Goto Top
prüf bitte sicherheitshalber mal unter "Manage Virtual Networks" dass bei VMnet0 deine physikalische Netzwerkkarte ausgewählt ist, die du nutzen möchtest und weise dem Netzwerkadapter deiner VM explizit VMnet0 zu.
Dann prüf bitte noch auf dem Host, ob bei den Eigenschaften der physikalischen Netzwerkkarte das "VMware Bridge Protocol" installiert und aktiviert ist.

Falls das alles passt... kannst du mit Wireshark umgehen?
DunkelHut
DunkelHut 08.05.2009 um 21:58:47 Uhr
Goto Top
Ich habe die Dinge so geprüft wie vorgeschlagen.

Hier die Snapshots:

986f6eb08de18cf54af0010a08cfb1a5-vmware_01

823a49711796134094df60ee3992e169-vmware_02

f67266354a57f41d8e9e3a0aaa2ae34d-vmware_03

11cb6f1f7a1f0c54353947b921cb3db6-vmware_04

Ja, mit Wireshark komme ich klar.

Ich habe auch noch mal ein Treiberupdate auf dem "Gast" laufen lassen. VMware bildet seine virtuellen Netzwerkkarten unter Windows Server 2008 als Intel Networkadapter ab.

Für das Ding waren zum Anfang keine Treiber da.
Die habe ich dann selbst eingebunden.

Vielleicht ist es auch noch wichtig zu bemerken das auf dem IBM Server die sch... Broadcom Karten onboard sind. Beide Onboardkarten habe ich im TeamingMode laufen.

Zur Not kann ich ja noch irgend eine "reale" Karte zum testen reinstecken.

Was denkst Du ?
RoterFruchtZwerg
RoterFruchtZwerg 08.05.2009 um 22:09:43 Uhr
Goto Top
Vielleicht ist der virtuelle Adapter durch das Teaming ein Problem. Möglicherweise kann der Treiber dieses virtuellen Adapters die Pakete von der VM nicht zuordnen, da sie direkt in den Netzwerk-Stack des virtuellen Adapters kommen, statt in eine der realen Karten.
Könnte also an einem Problem im Zusammenspiel des virtuellen Adapters und des Bridge Protocols sein.

Mit Wireshark kannst du aber überprüfen, ob zumindest eine unidirektionale Kommunkation zwischen Host und Gast möglich ist. Leg dazu am besten statische ARP Einträge für Gast/host auf Gast/Host an und prüf dann, ob bei einem Ping ICMP Pakete zumindest in eine Richtung durchkommen. Dieses Wissen kann durchaus nützlich sein.


Wenn es dir lediglich um eine funktionierende Kommunikation geht, kannst du dem Gast noch ein zweites Netzwerkinterface geben und als Host-Only einrichten. Dann kommunizieren Gast und Host über eine private Netzwerkverbindung (ein eigenes Subnetz) und alle anderen über die Bridge, was ja geht.
DunkelHut
DunkelHut 08.05.2009 um 22:44:46 Uhr
Goto Top
Danke für die beiden Gedankenansätze.

Ich werde beides versuchen und entsprechend hier die Resultate veröffentlichen.

Danke für Deine Zeit und Deine Gedanken heute.
Ich melde mich.

Gruß
DunkelHut
DunkelHut
DunkelHut 09.05.2009 um 09:51:12 Uhr
Goto Top
@RoterFruchtZwerg

Also ICMP technisch tut sich zwischen "Gastgeber" und "Gast" gar nichts.

Aber da noch mal eine Frage:
Wie setzt man im WireShark den Filter so, das man nur auf den Traffic zwischen zwei Adressen schaut ?

Ich habe bislang nur auf die einzelne IP bzw. MAC Adresse abgrenzen können. Nie auf Kombinationen und deren Traffic zueinander.

Ich habe weiterhin versucht zwischen "Gastgeber" und "Gast" ein virtuelles Netzwerk aufzubauen.

Lustiger Weise will der Gast mit seiner realen Adresse mit dem "Gastgeber" über sein virtuelle Adresse sprechen (lt. WireShark)

Das Blöde ist das zwischen dem System um das es geht und mir rund 600 km liegen, sonst würde ich das den Teaming-Mode der Onboard-Broadcom Karten auflösen.

Ich werde da kommende Woche wohl eine zusätzliche Netzwerkkarte einbauen lassen.

Den Broadcom Karten traue ich nicht mehr. Ich habe mit den Dingern schon viel Müll erlebt.

Was würdest Du vorschlagen ?

Gruß
DunkelHut
RoterFruchtZwerg
RoterFruchtZwerg 09.05.2009 um 10:47:14 Uhr
Goto Top
Lustiger Weise will der Gast mit seiner realen Adresse mit dem
"Gastgeber" über sein virtuelle Adresse sprechen (lt.WireShark)

Ok, das musst du bitte genauer ausführen....

Dein System sollte jetzt so aufgebaut sein:

Host:
- Virtueller Teaming-Adapter in VMware gebridged mit VMnet0, IP im Subnetz X
- Virtueller VMware-Adapter in VMware gebridged mit VMnet1, IP im Subnetz Y

Gast:
- Virtueller VMware Netzwerkadapter 1 eingestellt auf Custom: VMnet0, IP im Subnetz X
- Virtueller VMware Netzwerkadapter 2 eingestellt auf Custom: VMnet1, IP im Subnetz Y

Über die beiden IP Adressen im Subnetz Y von Host und Gast sollten die beiden problemlos kommunizieren können.
DunkelHut
DunkelHut 09.05.2009 um 11:43:56 Uhr
Goto Top
Also ich habe das schon verstanden was Du meinst, aber ich bin mir bei der Umsetzung nicht so ganz sicher.

Ich schicke Dir hier erst mal die Einstellungen vom HOST (Gastgeber)

5033ef696cacaf979df0d4ca24891247-bridge_i

b581f56bd780fb5eb3e6bb0686323109-bridge_ibjpg

6a90d7253adab150c5844702d3df982d-bridge_ii

4a24e2e7d21753e65092f28ee6e6083d-bridge_iib

a4c474d248baac550b79951985c78621-host

Wie Du im letzten Bild sehen kannst läuft da wohl schon irgend etwas schief.

Netz 192.168.3.0 / 255.255.255.0
Hauptnetz der Domain über das "Gastgeber" (Host) und "Gast" erstaunlicher Weise nicht kommunizieren können

Netz 192.168.33.0 / 255.255.255.0
virtuelles Netz über das ersatzweise "Gastgeber" (Host) und "Gast" kommunizieren sollen.

Ich möchte die Einträge statisch vergeben um es besser zu verstehen. Ist das ein Problem ?

Vorschläge ?

Gruß
DunkelHut
RoterFruchtZwerg
RoterFruchtZwerg 09.05.2009 um 12:00:34 Uhr
Goto Top
Falls du die eingeschränkte Konnektivität meinst, das ist noch nicht zwangsweise ein Problem.
Wie sieht denn die Konfiguration des Gastes aus?

Ansonsten würde ich Wireshark am Gast und am Host anwerfen und jeweils VMnet1 mitschneiden und schauen, ob hier die Pakete richtig versendet werden, und ob sie ankommen.
Falls sie schon garnicht versendet werden, gib doch mal deine Routing-Tabellen hier an ("route -4 print").
DunkelHut
DunkelHut 09.05.2009 um 14:26:48 Uhr
Goto Top
Jetzt wird es interessant

Jetzt erreiche ich vom CLIENT den HOST und umgedreht aber eben vom CLIENT den Rest vom Netz noch nicht.

Ein paar Einstellungen die Du vorgeschlagen hast @RoterFruchtZwerg konnte ich nicht so vornehmen. Es ist gut möglich das ich da den richtigen Einstieg nicht gefunden habe.

Um den Zustand jetzt transparent zu machen poste ich die Schnappschüsse von den Einstellungen der VMware vom Host, vom Client als auch die Routing-Table von beiden.

VMware Einstellungen HOST
5820ca13d256da2045d8f03eb71a5785-solution_00
56bfc87bf38806ebc8c549f4a84cf786-solution_01
614138154cfaf554f81744cf6eb11ef2-solution_02
9ece59c28ded76a3ef910a9b508b9421-solution_03
a54d767ca51c66f118ae9762acdff4b9-solution_04
ac833e89d5a42b1e49d44ce093bdacb8-solution_05
0e44c79990c4329e25d6bbd839700ca2-solution_06


VMware Einstellungen CLIENT
8f1fa528832a914cf0537ccc00e3415d-solution_07



Routing Table HOST
===========================================================================Schnittstellenliste 17 ...00 21 5e 28 9f 5a ...... BASP Virtual Adapter - Virtuelles Netzwerk 14 ...00 ff 3a 29 27 9e ...... TeamViewer VPN Adapter 13 ...00 21 5e 28 9f 5a ...... BASP Virtual Adapter 1 ........................... Software Loopback Interface 1 18 ...00 00 00 00 00 00 00 e0 isatap.{4D59E1BF-0197-440A-8B38-DCE002D23FBB 15 ...00 00 00 00 00 00 00 e0 isatap.{3A29279E-2CCA-4E9C-8AD8-60F7FF236CB3 12 ...02 00 54 55 4e 01 ...... Teredo Tunneling Pseudo-Interface 21 ...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #4===========================================================================IPv4-Routentabelle===========================================================================Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik 0.0.0.0 0.0.0.0 192.168.3.11 192.168.3.253 261 0.0.0.0 0.0.0.0 192.168.3.11 169.254.174.209 276 127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306 127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306 127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306 169.254.0.0 255.255.0.0 Auf Verbindung 169.254.174.209 276 169.254.174.209 255.255.255.255 Auf Verbindung 169.254.174.209 276 169.254.255.255 255.255.255.255 Auf Verbindung 169.254.174.209 276 192.168.3.0 255.255.255.0 Auf Verbindung 192.168.3.253 261 192.168.3.253 255.255.255.255 Auf Verbindung 192.168.3.253 261 192.168.3.255 255.255.255.255 Auf Verbindung 192.168.3.253 261 224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306 224.0.0.0 240.0.0.0 Auf Verbindung 192.168.3.253 261 224.0.0.0 240.0.0.0 Auf Verbindung 169.254.174.209 276 255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306 255.255.255.255 255.255.255.255 Auf Verbindung 192.168.3.253 261 255.255.255.255 255.255.255.255 Auf Verbindung 169.254.174.209 276===========================================================================Ständige Routen: Netzwerkadresse Netzmaske Gatewayadresse Metrik 0.0.0.0 0.0.0.0 192.168.3.11 256 0.0.0.0 0.0.0.0 192.168.3.11 Standard===========================================================================

Routing Table CLIENT [ KORRIGIERT ]
===========================================================================Schnittstellenliste0x1 ........................... MS TCP Loopback interface0x2 ...00 0c 29 65 87 4e ...... Intel(R) PRO/1000 MT Network Connection - Paketplaner-Miniport======================================================================================================================================================Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl 0.0.0.0 0.0.0.0 192.168.3.11 192.168.3.252 10 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.3.0 255.255.255.0 192.168.3.252 192.168.3.252 10 192.168.3.252 255.255.255.255 127.0.0.1 127.0.0.1 10 192.168.3.255 255.255.255.255 192.168.3.252 192.168.3.252 10 224.0.0.0 240.0.0.0 192.168.3.252 192.168.3.252 10 255.255.255.255 255.255.255.255 192.168.3.252 192.168.3.252 1Standardgateway: 192.168.3.11===========================================================================Ständige Routen: Keine

@RoterFruchtZwerg
In jedem Fall an Dich erst einmal ein großes Dankeschön.
Du hast sehr viel Zeit investiert um mir zu helfen. Da hast Du deutlich was gut bei mir.

Für den ersten Moment mal hier ein virtuelles Freibier, gern auch mal ein reales...

DANKE für Deine Mühe!

Vielleicht finden wir ja nun zusammen auch noch den Rest raus.
Ich denke jetzt kann es nur noch am Routing liegen.

Gruß
DunkelHut
RoterFruchtZwerg
RoterFruchtZwerg 09.05.2009 um 15:14:24 Uhr
Goto Top
Moment... da stimmt ja jetzt so einiges nicht mehr...

Wo ist der Netzwerkadapter für VMnet1 hin? Weder im Routing noch im Bridging kommt er vor, das Netzwerk 192.168.33.0/24 hast du völlig entfernt?

Dann, mit den Routing-Tabellen stimmt etwas nicht, die vom Client stammt nie und nimmer aus der VM, das ist doch die selbe wie vom Host?


Dass jetzt eine Kommunikation stattfindet liegt vermutlich daran, dass du mit "BASP Virtual Adapter - Virtuelles Netzwerk" gebridged hast... Das gibt dir die Kommunikation mit dem Host, aber nicht mit dem Netzwerk.
Umgekehrt hattest du es zuvor mit "BASP Virtual Adapter" gebridged, das gibt die die Kommunikation mit dem Host, aber nicht mit dem Netzwerk.

Das Problem liegt also eindeutig am Treiber für die Virtuellen BASP Adapter...

Bridge also VMnet0 wieder mit "BASP Virtual Adapter" und richte erneut VMnet1 mit 192.168.33.0/24 ein, wie es eigentlich zuvor schon hätte sein sollen.
DunkelHut
DunkelHut 09.05.2009 um 15:32:55 Uhr
Goto Top
...ich habe mir jetzt erst mal Kaffe gemacht

Die Routing-Table war die vom HOST, da hatte ich mich vertan. Ich habe das oben korrigiert.

Ich schaue noch mal nach den Einstellungen.

Mit dem Treiberproblem magst Du recht haben.

Ich habe schon mal eine Netzwerkkarte geordert.

[Bridge also VMnet0 wieder mit "BASP Virtual Adapter]
ist passiert...

[richte erneut VMnet1 mit 192.168.33.0/24 ein]
Welchem Adapter so VMnet1 denn zugewiesen werden ?
Wo bekommt er denn dann seine IP her ?

Danke...

Gruß
DunkelHut
RoterFruchtZwerg
RoterFruchtZwerg 09.05.2009 um 18:15:53 Uhr
Goto Top
VMnet1 soll mit dem Adapter "VMware Virtual Ethernet Adapter for VMnet1" gebridged werden. Da du diesen entfernt hast, kannst du unter "Host Virtual Adapters" einen Neuen erzeugen.
Diesem weist du eine IP im Netz 192.168.33.0/24 ganz normal über die Eigenschaften dieser Netzwerkverbindung zu.
DunkelHut
DunkelHut 09.05.2009 um 18:37:35 Uhr
Goto Top
Momentan ist erst mal Ruhe. Die Verbindung ist zusammengebrochen. Muss mal sehen was los ist.

Sobald das Ding wieder Online ist melde ich mich wieder.

Gruß
DunkelHut
DunkelHut
DunkelHut 14.05.2009 um 16:51:06 Uhr
Goto Top
Die Ursache für die Störungen lagen darin das als VMwareschnittstelle keine physische sondern eine virtuelle Netzwerkarte genutzt wurde.

Bei dem IBM Server sind zwei Broadcom Netzwerkkarten onboard. Mit einem Tool von Broadcom kann man die Karten dann im Teamingmode laufen lassen. Dadurch erhält man eine höhere Ausfallsicherheit weil es Reserven gibt. Leider ist es wohl so, daß der Treiber für die virtuelle Netzwerkkarte, das "Broadcom-Team", eben nicht jeden Modus unterstützt. VMware greift wohl da im Schichtenmodel ziemlich weit unten ein und das kann der Treiber wohl nicht händeln.

Ich habe den Teamingmode beendet und beide Broadcomkarten wieder für "normale" Nutzung freigegeben. Damit läuft VMware nun so wie man es sich erhofft.

Wenn es also zu kompliziert wird, einfach mal die Strategie wechseln.

Danke noch mal an den "RotenFruchtZwerg" für seine Mühe und seine Unterstützung.

Gruß
DunkelHut