Win10 als VMware Host

[mainziman]

mein Rechner mit VMware-Wkst 7.x (kein Win10) hat einige Linux Guests am Laufen, darunter auch einen, welcher DHCP-Server ist;

beim Router (eine Plastikbox) habe ich die IP-Adresse des Linux-VM-Guests als DHCP-Relay eingetragen;

es existiert noch ein anderer Rechner im LAN mit einem Win10 und Wkst. Pro;
beide Rechner (meiner und der andere mit Win10) und auch meine Linux-Guests haben alle eine fixe IPv4-Adresse eingestellt; diverse VM-Guests (Linux, Windows, ...) zum Test bekommen deren IPv4-Adresse über DHCP;

was passiert hier auf dem Win10-Rechner, sodaß ich fast täglich folgendes im per Mail versendeten Log (Logwatch) habe:

Code: Alles auswählen

 --------------------- dhcpd Begin ------------------------

 Addresses Leased:
    192.168.1.19 -> 00:50:56:c0:00:01 [WIN10-KISTE] (192.168.1.128): 8 Time(s)
    192.168.1.19 -> 00:50:56:c0:00:01 [WIN10-KISTE] (eth0): 10 Time(s)
    192.168.1.31 -> 00:50:56:c0:00:08 [WIN10-KISTE] (192.168.1.128): 8 Time(s)
    192.168.1.31 -> 00:50:56:c0:00:08 [WIN10-KISTE] (eth0): 11 Time(s)
 
 
 ---------------------- dhcpd End -------------------------


192.168.1.128 ist hier die IP-Adresse der LAN-Seite von meinem Router (der Plastikbox)

00:50:56:c0:00:01 bzw. 00:50:56:c0:00:08 sind doch die beiden virtuellen Netzwerkadapter, welche bei der Installation von VMware installiert werden ...
was wird hier seltsames veranstaltet?

[~thc]

DHCPv4 basiert auf Broadcast-Nachrichten, die jeder IPv4-Router im eigenen LAN-Segment hält - soll heißen: DHCPv4 wird nicht in andere Subnetze geroutet zu denen der Router ebenfalls Zugang hat.

Wenn DHCPv4-Clients einen DHCPv4-Server erreichen müssen, der in einem anderen Subnetz steht. brauchst du ein DHCPv4-Relay.

Für dein Setup (DHCPv4-Server ist im eigenen Subnetz) darfst du also kein Relay einstellen. DHCPv4 sollte auf dem Router vollständig deaktiviert werden. Der Linux-VM-DHCP-Server sollte "authoritative" für dein Subnetz sein.

[mainziman]

soweit ok, die eigentliche Frage ist aber: wie kommen diese seltsamen DHCP Botschaften mit MAC-Adressen der beiden von VMware installierten virtuellen Netzwerkkarten von dem Win10 VMware-Host zum DHCP-Server?

[~thc]

Hast du verstanden, was ich geschrieben habe? Dein DHCPv4-Setup ist falsch. Wozu sollte jemand die Logs in einem fehlerhaften Setup begutachten? Das macht doch keinen Sinn.

[mainziman]

dann erklär was falsch sein soll bevor Du Käse verbreitest;

[mainziman]

es gibt noch einen 3ten PC im LAN und passiert derartiges das auf dem Win10 VMHost passiert nicht; also liegts nicht an Deinem Käse sondern an was?

[mainziman]

und ein Hinweis, um Dir Deinen Käse auszutreiben, derartiges ist erst nachdem dieser besagte Win10 VM Host von Win7 auf Win10 upgedated wurde ...

[~thc]

Du bist witzig. Dein Setup ist falsch, aber du hältst es für richtig, da es ja bis zum Einsatz von Windows 10 funktionierte - und daher "richtig" sein muss.

Dann funktioniert aber doch etwas nicht ganz richtig und du fragst hier im Forum nach. Nur passt dir die Antwort überhaupt nicht in den Kram. Also muss die Antwort falsch ("Käse") sein.

[mainziman]

Äh mal langsam; Du willst mir erklären, daß mein Setup falsch ist, bist aber nicht in der lage den Fehler zu benennen;
und das nur weil Du nicht fähig bist, die Frage zu beantworten;

wer ist jetzt witzig?

[mainziman]

hättest es denn beantwortet, wenn ich nur den Log hingeknallt und den Hinweis gegeben hätte, daß der Win10 Rechner selbst aber eine fixe IPv4-Adresse hat?
und derartiges bei den anderen nonWin10-VM-Hosts nicht ist ...

darum beschränke Dich einfach auf das, ich merke schon Deine Lesekompetenz ist nicht hinreichend um Zusammenhänge zu erkennen;

[~thc]

Und du meinst, Beleidigungen helfen dir hier weiter? Geht es dir jetzt wenigstens besser, nachdem du etwas Rumpelstielzchen gespielt hast (hier und als PM)?

Also gut, dann überlese ich das jetzt mal mit deiner Plastikbox und dem Relay.

Deine Win10-Maschine fragt mit den MAC-Adressen von VMNet1 und VMNet8 nach Leases? Einfachste Erklärung: Win10 als Host erst ab Workstation 12.

[v-rtc]

Hallo,

was ist denn hier los? Moderatoren?

Viele Grüße

Rolf

[Dayworker]

Punkt 1)
Win10 wird, wie korrekt geschrieben, erst ab WS12 offiziell supportet.

Punkt2)
Zwei DHCP-Server in einem Subnetz sorgen fast immer für Probleme. Es reicht wenn ein Server die Regeln etwas weitet. Daher einfach einen DHCP-Server abschalten und man hat dauerhaft Ruhe.

Punkt3)
VMware hatte aus unverständlichen Gründen vmnet1 : 00 50 56 C0 00 01 und vmnet8 : 00 50 56 C0 00 08 hardcodiert. Bei allen betroffenen Player- oder WS-Versionen trifft die VMware-Aussage, daß die MAC-Adressen bei jeder Player/WS-Inst ausgewürfelt würden, nicht zu. Installiert man Player bzw WS auf mehreren Rechnern, bekommen auch die jeweiligen VMs dieselben MAC-Adressen. Für beide VMnetX ist das eigentlich unkritisch, da diese ja entweder keinen (vmnet1 = Host-only) oder nur indirekten (vmnet8 = NAT) Inet-Zugang haben. Das sowohl bei "Host-only" als auch "NAT" ein VMware-DHCP-Server werkelt, macht die Sache nicht einfacher. Win10 scheint, ausgehend von deinem Logwatch-Log, die lokalen DHCP-Server von "vmnet1" und "vmnet8" zu forwarden in Richtung Router und der wiederum schickt das dank deinem DHCP-Relay zur Linux-DHCP-VM. Du hast dir somit einen Loop gebastelt. Ein DHCP-Relay macht ja nichts anderes, als alle empfangenen DHCP-Übertragungen im Subnetz an die angegebene IP-Adresse in einem anderen Subnetz weiterzuleiten. In meinen Augen kann Win10 nichts mit den VMnet1/8 anfangen und schickt daher deren DHCP-Announcen gewissermaßen als Spam weiter.

[rprengel]

Punkt 1)
Win10 wird, wie korrekt geschrieben, erst ab WS12 offiziell supportet.

Punkt2)
Zwei DHCP-Server in einem Subnetz sorgen fast immer für Probleme. Es reicht wenn ein Server die Regeln etwas weitet. Daher einfach einen DHCP-Server abschalten und man hat dauerhaft Ruhe.

Punkt3)
VMware hatte aus unverständlichen Gründen vmnet1 : 00 50 56 C0 00 01 und vmnet8 : 00 50 56 C0 00 08 hardcodiert. Bei allen betroffenen Player- oder WS-Versionen trifft die VMware-Aussage, daß die MAC-Adressen bei jeder Player/WS-Inst ausgewürfelt würden, nicht zu. Installiert man Player bzw WS auf mehreren Rechnern, bekommen auch die jeweiligen VMs dieselben MAC-Adressen. Für beide VMnetX ist das eigentlich unkritisch, da diese ja entweder keinen (vmnet1 = Host-only) oder nur indirekten (vmnet8 = NAT) Inet-Zugang haben. Das sowohl bei "Host-only" als auch "NAT" ein VMware-DHCP-Server werkelt, macht die Sache nicht einfacher. Win10 scheint, ausgehend von deinem Logwatch-Log, die lokalen DHCP-Server von "vmnet1" und "vmnet8" zu forwarden in Richtung Router und der wiederum schickt das dank deinem DHCP-Relay zur Linux-DHCP-VM. Du hast dir somit einen Loop gebastelt. Ein DHCP-Relay macht ja nichts anderes, als alle empfangenen DHCP-Übertragungen im Subnetz an die angegebene IP-Adresse in einem anderen Subnetz weiterzuleiten. In meinen Augen kann Win10 nichts mit den VMnet1/8 anfangen und schickt daher deren DHCP-Announcen gewissermaßen als Spam weiter.

Zu Punkt 3
Das passiert wenn man mit dem Netzwerkeditor herum spielt und die Bindungen der VMs zu den Netzwerkkarten ändert.
Gruss

[Dayworker]

Jein, die MAC-Addy ist leider auch ohne manuelle Umkonfiguration ungünstig. Der MAC-Bereich 00:50:56:00:00:00-00:50:56:3F:FF:FF ist für die manuelle Vergabe von MAC-Adressen vorgesehen, während 00:0C:29:XX:YY:ZZ für die dynamische sprich Vergabe durch WS, Player, Fusion und ESX(i) vorgesehen ist. Nur XX und YY sind wirklich frei für die WS verfügbar, denn ZZ entspricht immer dem Hash der VMX-Datei.

[add]
Und auch XX und YY sidn nicht wirklich frei verfügbar, siehe dazu den KB-Eintrag Setting a static MAC address for a virtual NIC (219).

[Martin]

Und auch XX und YY sidn nicht wirklich frei verfügbar, siehe dazu den KB-Eintrag Setting a static MAC address for a virtual NIC (219).

Dieser KB-Artikel ist inzwischen wohl nur noch als Link-Sammlung zu den entsprechenden Kapiteln der neueren Manuals hilfreich.
"Note: This information applies only to ESX 2.5 and earlier, it is not applicable to ESX 3.0 and later. For information about MAC address management in later releases see the relevant documentation for the version of ESXi/ESX you are using."

Zum Beispiel heißt es in der Doku zu vSphere 5.5
"Standardmäßig verwendet VMware den OUI (Organizationally Unique Identifier, eindeutiger Bezeichner für Organisationen) 00:50:56 für manuell generierte Adressen, es werden jedoch alle eindeutigen manuell erstellten Adressen unterstützt. "

[Dayworker]

Mit Link-Sammlung hast du Recht, aber da du den 5.5er direkt ansprachst... Der MAC-Range 00:50:56 ist weiterhin für statische Adressen vorgesehen. Der ESXi selbst generiert ohne vCenter oder Einträge in der VMX-Datei wie die Adresse zu allozieren ist, immer Adressen im Bereich 00:0C:29 (siehe auch http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.networking.doc/GUID-DC7478FF-DC44-4625-9AD7-38208C56A552.html. Sobald du jedoch statische Adressen vergibst, kann bzw überprüft der ESXi nicht mehr auf Adresskonflikte und der Anwender muß dafür selbst Sorge tragen. Daher ist es ja gerade so ungeschickt von VMware, für die vmnet1 (Host-only)und vmnet8 (NAT) ausgerechnet die für den statischen Adressbereich vorgesehenen MAC-Adressen beginnend mit 00:50:56 zu verwenden und das dann auch noch fest in die SW zu kodieren.

Unabhängig davon gehts hier um die Workstation und dort ist der Adressbereich 00:0C:29 wie auch der für statische Adressen vorgesehene Bereich auch noch etwas anders. Das entscheidende Oktet beispielsweise im "statischen" Bereich habe ich mal fett hervorgehoben 00:50:56:00:00:00-00:50:56:3F:FF:FF. Der für den ESXi nutzbare Bereich ist hier wirklich nur bis 3F vorgesehen, damit es zu keinen Überschneidungen mit der Workstation und dem GSX-Server kommt.