Veraltet: VMWare Anpassungen für LogoDIDACT als Gastsystem mit Promiscuous Mode

Zuletzt geändert von superadmin am 2022/03/25 10:56

Bitte den hier beschriebenen, veralteten Weg der VMware Anpassungen nicht mehr verwenden und stattdessen auf folgende Anleitung zurückgreifen, die den empfohlenen Weg darstellt.


Folgender Effekt kann nach der Grundinstallation von LogoDIDACT unter VMware auftreten. Es ist möglich, sich von einem internen Client auf den ldhost zu verbinden, jedoch nicht zum logosrv als LXC-Container. Dies liegt an Netzwerk-Filtereinstellungen am ESXi Host.

https://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp#securing_an_esx_configuration/c_securing_virtual_switch_ports.html
https://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp#com.vmware.vsphere.server_configclassic.doc_40/esx_server_config/securing_an_esx_configuration/c_securing_virtual_switch_ports.html

In den Einstellungen des ESXi Hosts unter Netzwerk kann man die einzelnen vSwitches bearbeiten. Unter Switch -> Netzwerkkarte zur VM -> Bearbeiten -> Reiter Sicherheit findet man einige Einstellungen, die man ändern sollte, damit die Kommunikation von Clients zum logosrv funktioniert. Die Änderung ist für den vSwitch nötig, der für die interne Schnittstelle des LogoDIDACT Servers zuständig ist.

ESXi vmware-vswitch-ldhost.png

Hier die abgebildeten Einstellungen wie folgt ändern:

Mac Adress Changes -> Accept
Forget Transmissions -> Accept
Promiscuous Mode Operation -> Accept/Allow

Neue Erkenntnisse:
Die Kombination des notwendigen Promiscuous Mode unter VMWare in Kombination mit dem Open VSwitch in LogoDIDACT 2.0 scheint grundlegende Probleme zu verursachen.
Die Port-Gruppe auf dem VSphere Server verhält sich wie ein Hub und diese Inflation von Netzwerkpaketen führt zu massiven Kollisionen und bringt irgendwann das Samba-Netz zum Erliegen.
Wenn man den Samba-Dienst kurz anhält und wieder neu startet, erholt sich der Verkehr zum logosrv wieder.
Fazit: LogoDIDACT 2.0 virtualisiert unter VMWare funktioniert derzeit nicht!

Der folgende Artikel beschreibt die Problematik auf technischer Ebene und zeigt als Lösung einen Nested ESXi:
https://blogs.vmware.com/vcloud/2015/04/nested-esxi-vcloud-air.html

Möglicherweise sind wir nun wieder an der Stelle angelangt, die schon bei der Einführung von OVS in LogoDIDACT 2.0 aufgetreten ist und benötigen für Rembo ein eigenes "physikalisches" Interface.
Nur auf diesem Interface müsste dann der Promiscuous Mode in VMWare aktiviert werden.


Ein anderer Ansatz ist die Umgestaltung der LogoDIDACT Interfaces, sodass auf den Promiscuous Mode innerhalb der vSwitch-Einstellungen von VMware verzichtet werden kann.

Die Vorgehensweise hierzu wird in nachfolgendem Artikel beschrieben:

Dies stellt auch den empfohlenen Betriebsmodus dar!