Network-Adapter neu starten für erfolgreiche Verbindung

[drei20]

Hallo.
1. Sorry falls ich hier falsch bin, bin ganz neu hier
2. Danke Administrator für die Aktivierung meines Accounts

Zu meiner eigentlichen Frage:
Ich habe mir mit VMware Workstation Pro 16.0 eine neue Ubuntu Server 20.04 VM erstellt. Dann habe ich erst durch die Oberfläche von Workstation selbst gearbeitet, was mich allerdings schon nach kurzer Zeit genervt hat, da man z.B. schwierig was Copy & Pasten kann. Außerdem will ich die VM nicht immer direkt offen haben, sondern nur im Hintergrund laufen lassen.
Mein Problem:
Wenn ich jetzt meinen Host (Windows 10 Education 20H2) neu starte und danach diese Ubuntu Server VM auch hochfahre (nach einem normalen Shutdown mit dem Befehl

Code: Alles auswählen

shutdown now

), dann habe ich keine Connection vom Host zur VM.

Info:
1. Ja, die VM hat eine IP bekommen: 192.168.32.131
2. Mein Windows Host hat auch eine IP: 192.168.32.1
3. VMNet8 für NAT wird verwendet

Allerdings kann ich mich zu diesem Zeitpunkt weder mit SSH verbinden, geschweige denn die VM überhaupt über diese IP erreichen. Was ich danach tun muss ist den VMNet8 Adapter zu deaktivieren und neu zu aktivieren (In meinen Host-Windows-Einstellungen).
Das kann doch nicht sein, dass das immer so ist, oder? Weil das nervt schon irgendwie ...
Und das passiert nicht nur bei der Ubuntu Server VM, sondern auch bei allen anderen. (Windows XP, Debian, Ubuntu Desktop)

Habe ich irgendwo etwas evtl. falsch konfiguriert? (Ich habe im Netz-Manager von Workstation nie etwas umgestellt).
Ich teile gerne Konfigurationsdateien auf Anfrage, ich weiß nur nicht, welche dafür notwendig sein könnten.

PS:
Da fällt mir ein, ich habe mal etwas in der Datei "vmnetdhcp.conf" verändert, ich habe nämlich einer anderen VM eine statische IP gegeben. Danach habe ich diesen VMnetDHCP Service neu gestartet und das hat auch funktioniert.

MfG
drei20

[~thc]

Moin.

Ich gehe mal davon aus, dass du sehr genau wusstest, was du da in der vmnetdhcp.conf tust - und nicht der Dienst dadurch gestört ist.

Ich habe das mit meinem sehr ähnlichen Setup (W10 Pro 20H2, Player 16.1, Debian 10 VM) mal versucht, nachzuvollziehen - die VM ist immer uneingeschränkt vom Host aus erreichbar.

Läuft auf deinem Host irgendeine "Sicherheits"-Software, deren Netzwerkmodul da reinfunken kann?

[drei20]

Moin.

Ich gehe mal davon aus, dass du sehr genau wusstest, was du da in der vmnetdhcp.conf tust - und nicht der Dienst dadurch gestört ist.

Ich habe das mit meinem sehr ähnlichen Setup (W10 Pro 20H2, Player 16.1, Debian 10 VM) mal versucht, nachzuvollziehen - die VM ist immer uneingeschränkt vom Host aus erreichbar.

Läuft auf deinem Host irgendeine "Sicherheits"-Software, deren Netzwerkmodul da reinfunken kann?

Ja, ich wusste was ich da mache, also so ca. (Habe es wieder entfernt, Service neu gestartet -> es ging immer noch nicht)

Code: Alles auswählen

host VMnet8 {
    hardware ethernet 00:0C:29:7C:E7:76;
    fixed-address 192.168.32.10;
}

Es läuft nur Windows Defender und die Firewall ist aktiviert. Das sollte aber egal sein, weil es dann ja trotzdem nicht gehen würde, nach dem Adapter neustart.

[~thc]

"host VMNet8" ist die interne Vergabe der VMNet8-IP-Adresse des Workstation-Hosts und passt nicht zu "einer anderen VM eine statische IP gegeben".

Die MAC-Adresse ist die einer VM und nicht die vom virtuellen Host-VMNet8-Adapter.

Entfernen darf man den Eintrag nicht.

Kannst du die Original-Datei aus einem Backup wiederherstellen? Wenn nein: WS komplett deinstallieren - kontrollieren, ob die vmnetdhcp.conf gelöscht ist - und neu installieren.

[Dayworker]

Die IP-Adressen für VM/Guest und Wirt/Host sind aber unterschiedlich?
Mit einem Windows-Host/Wirt würde ich prinzipiell garnix manuell in den Conf-Dateien einstellen, sondern alles per "VMware Network Editor" sprich "vmnetcfg" im VMware-Programmeverzeichnis erledigen. Selbst Portfreigaben für NAT lassen sich seit mehreren Jahren darüber einstellen und man spart sich damit sowohl das Anhalten als auch Starten dazugehöriger Dienste.

[drei20]

"host VMNet8" ist die interne Vergabe der VMNet8-IP-Adresse des Workstation-Hosts und passt nicht zu "einer anderen VM eine statische IP gegeben".

Die MAC-Adresse ist die einer VM und nicht die vom virtuellen Host-VMNet8-Adapter.

Entfernen darf man den Eintrag nicht.

Kannst du die Original-Datei aus einem Backup wiederherstellen? Wenn nein: WS komplett deinstallieren - kontrollieren, ob die vmnetdhcp.conf gelöscht ist - und neu installieren.

Du verstehst mich falsch. Den Eintrag habe ich selbst hinzugefügt um einer anderen VM eine "statische Adresse" zu geben. Das hat auch funktioniert. Die Standard-Einstellungen in dieser Datei habe ich nicht verändert. Heißt mein Host und meine anderen VM haben noch alle DHCP IPs. Dafür muss ich nichts deinstallieren und neu installieren.

Die IP-Adressen für VM/Guest und Wirt/Host sind aber unterschiedlich?
Mit einem Windows-Host/Wirt würde ich prinzipiell garnix manuell in den Conf-Dateien einstellen, sondern alles per "VMware Network Editor" sprich "vmnetcfg" im VMware-Programmeverzeichnis erledigen. Selbst Portfreigaben für NAT lassen sich seit mehreren Jahren darüber einstellen und man spart sich damit sowohl das Anhalten als auch Starten dazugehöriger Dienste.

Die IP am Windows-Host ist `192.168.32.1` und die am Ubuntu Server ist `192.168.32.131`. Im Virtual Network Editor kann ich keiner VM eine statische IP geben. Ja, das ist nicht der normale Weg, das wäre nämlich über z.B. den Netzwerkmanager vom jeweiligen VM-Betriebssystem.
Aber darum geht es jetzt auch nicht, weil die betroffene VM davon nicht betroffen ist.
Ich muss den Netzwerkadapter immer neu starten, dass ich eine Verbindung zwischen Host und Guest herstellen kann. Obwohl beide eine IP haben.

[Dayworker]

Genau solche manuelle Eintragungen an "vmnetcfg" vorbei hatte ich mir schon gedacht. Einfach den DHCP-Server von VMware-NAT ausschalten hätte gereicht. Mit deiner festen IP und bei aktiven VMware-DHCP ist die Kommunikation nachhaltig gestört. Hoffentlich hat dein Host-Windows nicht die Heimnetz-IP 192.168.32.1. Das ist die IP-Adresse des VMware-NAT-Interface. NAT versteckt ja die Gast-IP hinter der IP-Adresse des Hosts/Wirts und das Routing funktioniert logischerweise nur dann, wenn sich Host- und Gast-IP unterscheiden.

[drei20]

Genau solche manuelle Eintragungen an "vmnetcfg" vorbei hatte ich mir schon gedacht. Einfach den DHCP-Server von VMware-NAT ausschalten hätte gereicht. Mit deiner festen IP und bei aktiven VMware-DHCP ist die Kommunikation nachhaltig gestört. Hoffentlich hat dein Host-Windows nicht die Heimnetz-IP 192.168.32.1. Das ist die IP-Adresse des VMware-NAT-Interface. NAT versteckt ja die Gast-IP hinter der IP-Adresse des Hosts/Wirts und das Routing funktioniert logischerweise nur dann, wenn sich Host- und Gast-IP unterscheiden.

1. Okay dann können wir das Thema mit der "vmnetcfg" abschließen, da ich alles zurückgesetzt habe.
2. Habe ich das vielleicht falsch verstanden? Mein richtiges LAN-Netz ist im Netzwerk 10.0.0.0/24 und das VMnat-Netz ist 192.168.32.0/24.
2.1. Der VMnet-Adapter am Windows-Host hat 192.168.32.1
2.2. Der VMnet-Adapter am Ubuntu-Server hat 192.168.32.131

Trotz Neuinstallation kommt die Verbindung erst nach einem Adapter-Neustart zustande

[~thc]

Ich denke, das Problem ist irgendwo im Host-OS zu suchen. Kannst du nach einem Neustart des Win 10 E mal schauen
- ob alle VMWare-relevanten Dienste, die automatisch gestartet werden sollen, es auch werden?
- ob im Ereignisprotokoll System/Anwendung Fehler oder Warnungen auftauchen, die das Netzwerk/VMWare betreffen?