Een ZVM-gast kan een geldig LAN-adres hebben en toch geen toegang krijgen tot services die op de ZimaOS-host zelf draaien. Dat was het kernprobleem in deze discussie. Toen de VM was ingesteld op Bridgen naar eth0, kon de gast deelnemen aan het LAN, maar meldde deze geen route naar de host. Zima-Giorgio adviseerde om de VM over te schakelen naar NAT wanneer het doel was verbinding te maken met shares op ZimaOS.
De bron laat ook zien dat een “netwerkroute” en “SMB-machtiging” afzonderlijke problemen zijn. Een latere gebruiker schakelde over naar NAT en bereikte het aanmeldingsvenster, maar kon nog steeds met meerdere accounts geen toegang krijgen tot de RAID-share. Dat authenticatie- en opslagprobleem moet niet worden verward met het hostisolatieprobleem in bridgemodus.
Bridgemodus Gaf de VM Normale LAN-bereikbaarheid
De oorspronkelijke gebruiker selecteerde Bridgen naar eth0 omdat die wilde dat de VM zich gedroeg als een ander apparaat op het lokale netwerk. In die modus kon de VM een LAN-adres verkrijgen en communiceren met andere systemen op het LAN.
Het ontbrekende pad was specifiek de communicatie tussen de VM en de ZimaOS-host.
Zima-Giorgio Adviseerde NAT voor Toegang tot de Host
Zima-Giorgio van IceWhale vertelde de gebruiker de VM af te sluiten en de netwerkmodus te wijzigen van Bridge naar NAT. In een vervolgreactie beschreef hij zijn ervaring als een afweging: NAT geeft toegang tot de host, terwijl Bridge toegang biedt tot andere LAN-apparaten.
Dat is officieel ondersteuningsadvies uit de brondiscussie uit 2025, geen algemene uitspraak over elke libvirt-topologie.
Latere Communitymeldingen Pasten Nog Steeds bij Hostisolatie door macvtap
In mei-juni 2026 beschreef een andere communitydiscussie hetzelfde patroon: een bridged VM kreeg een normaal LAN-IP-adres, kon andere LAN-apparaten bereiken, maar kon de ZimaOS-host niet via ARP bereiken of er verbinding mee maken. Overschakelen naar NAT herstelde de hostverbinding onmiddellijk.
De gebruikers vermoedden dat ZVM's pad “Bridgen naar eth0” was geïmplementeerd met macvtap, waarvan het hostisolatiegedrag goed bekend is. De openbare discussie bevatte geen bevestiging van IceWhale over de exacte backend. macvtap moet daarom worden beschouwd als een sterke verklaring vanuit de community, niet als een officiële bewering over de implementatie.
SMB-aanmeldingsproblemen Zijn een Afzonderlijke Laag
Een deelnemer schakelde over naar NAT en kon uiteindelijk het aanmeldingsvenster van ZimaCube bereiken, maar SMB-accounts gedroegen zich nog steeds inconsistent. Met het hoofdaccount konden sommige hostpaden worden bekeken, terwijl toegang tot de RAID mislukte, en andere accounts gaven machtigingsfouten.
Zodra de basis-IP-bereikbaarheid werkt, moet je het SMB-shareaccount en de machtigingen afzonderlijk onderzoeken.
De huidige ZimaOS-documentatie beschrijft Samba-sharing per gebruiker en lees- of lees-schrijfmachtigingen. Gebruik het huidige ZimaOS-model voor Samba-machtigingen voor meerdere gebruikers wanneer een VM de server kan bereiken, maar authenticatie of toegang nog steeds mislukt.
Ubuntu's Vermeldingen voor Bestandsdeling en Externe Aanmelding Gebruiken Niet Hetzelfde Protocol
De gebruiker in de bron merkte op dat Ubuntu “ZimaCube (Bestandsdeling)” en “ZimaCube (Externe aanmelding)” toonde. In de wachtwoordmanager stond voor die laatste ook een sftp://-verbinding.
SFTP via SSH en SMB zijn verschillende services. Een geslaagde SFTP-aanmelding bewijst niet dat de SMB-machtigingen correct zijn. Een SMB-share moet worden getest met een SMB-URL of een browser voor netwerks shares, niet via de SSH-vermelding.
Een Communitygebruiker Bouwde een Statische-routeringsoplossing voor Bridgemodus
Een andere deelnemer hield de VM in bridgemodus en gebruikte een derde Debian-server als router tussen de VM en de host. Vervolgens voegde die statische routes toe aan beide eindpunten. De gebruiker meldde dat het werkte, maar noemde het resultaat “niet fraai”.
Deze Linux-routeringsopdrachten waren experimenten van de community, niet het door IceWhale aanbevolen ZVM-ontwerp. De extra router wordt bovendien een knelpunt voor de doorvoer en een extra storingspunt.
Kies de Netwerkmodus op Basis van de Werkelijke Rol van de VM
- De VM moet vooral toegang hebben tot services of shares op de ZimaOS-host: NAT is de eerste test die door de bron wordt ondersteund.
- De VM moet zich vooral gedragen als een afzonderlijk LAN-apparaat: Bridge kan het normale LAN-adres leveren.
- De VM heeft zowel toegang tot de host als tot het LAN nodig: test de huidige ZVM-release zorgvuldig; de historische bron laat zien dat dit de onopgeloste leemte was.
De Huidige Netwerkinstellingen van ZimaOS Documenteren Geen ZVM-br0-procedure
De huidige openbare documentatie over ZimaOS-netwerken behandelt fysieke interfaces, DHCP-/handmatige IP-configuratie en externe toegang. Er wordt geen ondersteunde procedure gepubliceerd voor het maken van een aangepaste hostbridge specifiek om het hostisolatiegedrag van ZVM te omzeilen.
Raadpleeg het huidige ZimaOS-netwerkmodel voordat je handmatig hostroutes of NetworkManager-bestanden bewerkt.
Veelgestelde Vragen over Toegang tot de ZVM-host
Kon de VM in de bron via NAT de ZimaOS-host bereiken?
Ja. Gebruikers meldden dat overschakelen naar NAT de blokkade waarbij geen route naar de host bestond, wegnam.
Loste NAT de SMB-machtigingen automatisch op?
Nee. Eén gebruiker bereikte het aanmeldingsvenster, maar had nog steeds afzonderlijke problemen met de machtigingen voor shares.
Was de routeringsoplossing met een derde server officieel?
Nee. Het was een oplossing vanuit de community voor gebruikers die de bridgemodus wilden behouden.
