Ein ZVM-Gast kann eine gültige LAN-Adresse haben und trotzdem keine Dienste erreichen, die direkt auf dem ZimaOS-Host laufen. Das war das Kernproblem in diesem Thread. Bei der Einstellung Bridge to eth0 konnte der Gast am LAN teilnehmen, meldete aber keine Route zum Host. Zima-Giorgio empfahl, die VM auf NAT umzustellen, wenn das Ziel der Zugriff auf ZimaOS-Freigaben ist.
Die Quelle zeigt außerdem, dass „Netzwerkroute“ und „SMB-Berechtigung“ getrennte Probleme sind. Ein späterer Nutzer wechselte zu NAT und erreichte den Anmeldedialog, konnte aber mit mehreren Konten weiterhin nicht auf die RAID-Freigabe zugreifen. Dieses Authentifizierungs- bzw. Speicherproblem sollte nicht mit dem Host-Isolationsproblem im Bridge-Modus verwechselt werden.
Der Bridge-Modus ermöglichte der VM normalen LAN-Zugriff
Der ursprüngliche Nutzer wählte „Bridge to eth0“, weil sich die VM wie ein weiteres Gerät im lokalen Netzwerk verhalten sollte. In diesem Modus konnte die VM eine LAN-Adresse erhalten und mit anderen LAN-Systemen kommunizieren.
Der fehlende Pfad betraf ausdrücklich die Kommunikation zwischen VM und ZimaOS-Host.
Zima-Giorgio empfahl NAT für den Host-Zugriff
IceWhales Zima-Giorgio forderte den Nutzer auf, die VM herunterzufahren und die Netzwerkeinstellung von Bridge auf NAT zu ändern. In einer Folgeantwort beschrieb er seine Erfahrung als Abwägung: NAT ermöglicht den Zugriff auf den Host, während Bridge den Zugriff auf andere LAN-Geräte bietet.
Das ist eine offizielle Supportempfehlung aus dem Quell-Thread von 2025 und keine allgemeine Aussage über jede libvirt-Topologie.
Spätere Community-Berichte entsprachen weiterhin der Host-Isolierung durch macvtap
In einem weiteren Community-Thread von Mai/Juni 2026 wurde dasselbe Muster beschrieben: Eine Bridge-VM erhielt eine normale LAN-IP-Adresse, konnte andere LAN-Geräte erreichen, aber weder den ZimaOS-Host per ARP auflösen noch eine Verbindung zu ihm herstellen. Der Wechsel zu NAT stellte die Host-Konnektivität sofort wieder her.
Die Nutzer vermuteten, dass der ZVM-Pfad „Bridge to eth0“ mit macvtap implementiert wurde, dessen Host-Isolierungsverhalten bekannt ist. Der öffentliche Thread enthielt keine Bestätigung von IceWhale zum genauen Backend. Daher sollte macvtap weiterhin als starke Erklärung aus der Community und nicht als offizielle Aussage zur Implementierung betrachtet werden.
SMB-Anmeldeprobleme sind eine separate Ebene
Ein Teilnehmer wechselte zu NAT und konnte schließlich den ZimaCube-Anmeldedialog erreichen, doch die SMB-Konten verhielten sich weiterhin inkonsistent. Mit seinem Hauptkonto konnte er einige Host-Pfade durchsuchen, während der Zugriff auf RAID fehlschlug; bei anderen Konten wurden Berechtigungsfehler angezeigt.
Sobald die grundlegende IP-Konnektivität besteht, sollten SMB-Freigabekonto und Berechtigungen separat untersucht werden.
Die aktuellen ZimaOS-Dokumente beschreiben Samba-Freigaben pro Benutzer sowie Lese- und Lese-/Schreibberechtigungen. Verwende das aktuelle ZimaOS-Modell für Samba-Berechtigungen bei mehreren Benutzern, wenn eine VM den Server erreichen kann, die Authentifizierung oder der Zugriff aber weiterhin fehlschlägt.
Ubuntus Einträge für Dateifreigabe und Remote-Anmeldung verwenden nicht dasselbe Protokoll
Der Nutzer aus der Quelle bemerkte, dass Ubuntu „ZimaCube (File Sharing)“ und „ZimaCube (Remote Login)“ anzeigt. Sein Passwortmanager enthielt außerdem eine sftp://-Verbindung für Letzteres.
SFTP über SSH und SMB sind unterschiedliche Dienste. Eine erfolgreiche SFTP-Anmeldung bestätigt nicht, dass die SMB-Berechtigungen korrekt sind. Eine SMB-Freigabe sollte mit einer SMB-URL oder einem Browser für Netzwerkfreigaben getestet werden, nicht über den SSH-Eintrag.
Ein Community-Nutzer richtete für den Bridge-Modus eine statische Routing-Umgehung ein
Ein anderer Teilnehmer behielt die Bridge-Verbindung der VM bei und verwendete einen dritten Debian-Server als Router zwischen VM und Host. Anschließend fügte er auf beiden Endpunkten statische Routen hinzu. Er berichtete, dass es funktionierte, bezeichnete das Ergebnis jedoch als „nicht besonders elegant“.
Diese Linux-Routing-Befehle waren ein Experiment aus der Community und keine von IceWhale empfohlene ZVM-Konfiguration. Der zusätzliche Router wird außerdem zu einem Durchsatzengpass und zu einem weiteren Ausfallpunkt.
Wähle die Netzwerkkonfiguration nach der tatsächlichen Rolle der VM
- Die VM muss hauptsächlich auf vom ZimaOS-Host bereitgestellte Dienste oder Freigaben zugreifen: NAT ist der von der Quelle unterstützte erste Test.
- Die VM soll sich hauptsächlich wie ein separates LAN-Gerät verhalten: Bridge kann die normale LAN-Adresse bereitstellen.
- Die VM benötigt sowohl Host- als auch LAN-Zugriff: Teste die aktuelle ZVM-Version sorgfältig; die historische Quelle zeigt, dass dies die ungelöste Lücke war.
Die aktuellen ZimaOS-Netzwerkeinstellungen dokumentieren keinen br0-Workflow für ZVM
Die aktuelle öffentliche ZimaOS-Netzwerkdokumentation behandelt physische Schnittstellen, DHCP bzw. manuelle IP-Konfiguration und den Fernzugriff. Sie veröffentlicht kein unterstütztes Verfahren zum Erstellen einer benutzerdefinierten Host-Bridge, um die Host-Isolierung von ZVM zu umgehen.
Informiere dich über das aktuelle ZimaOS-Netzwerkmodell, bevor du Host-Routen oder NetworkManager-Dateien manuell bearbeitest.
FAQ zum Host-Zugriff mit ZVM
Ermöglichte NAT der Quell-VM den Zugriff auf den ZimaOS-Host?
Ja. Nutzer berichteten, dass der Wechsel zu NAT die Blockade „Keine Route zum Host“ beseitigte.
Behob NAT automatisch die SMB-Berechtigungen?
Nein. Ein Nutzer erreichte den Anmeldedialog, hatte aber weiterhin separate Probleme mit den Berechtigungen der Freigabe.
War die Routing-Umgehung über einen dritten Server offiziell?
Nein. Sie war eine Lösung aus der Community für Nutzer, die den Bridge-Modus beibehalten wollten.
