En ZVM-gäst kan ha en giltig LAN-adress och ändå inte kunna nå tjänster som körs på själva ZimaOS-värden. Det var kärnproblemet i den här tråden. När den virtuella maskinen var inställd på Bridge to eth0 kunde gästen delta i LAN-nätverket men rapporterade att det saknades en rutt till värden. Zima-Giorgio rekommenderade att växla den virtuella maskinen till NAT när målet var att ansluta till ZimaOS-delningar.
Källan visar också att ”nätverksrutt” och ”SMB-behörighet” är separata problem. En senare användare växlade till NAT och nådde inloggningsdialogen, men kunde fortfarande inte komma åt RAID-delningen med flera konton. Det autentiserings- och lagringsproblemet ska inte blandas ihop med isoleringsproblemet mellan värd och bryggat nätverk.
Bryggläge gav den virtuella maskinen normal LAN-åtkomst
Den ursprungliga användaren valde Bridge to eth0 eftersom de ville att den virtuella maskinen skulle fungera som en annan enhet i det lokala nätverket. I det läget kunde den virtuella maskinen få en LAN-adress och kommunicera med andra system i LAN-nätverket.
Den saknade vägen gällde specifikt kommunikationen mellan den virtuella maskinen och ZimaOS-värden.
Zima-Giorgio rekommenderade NAT för åtkomst till värden
IceWhales Zima-Giorgio bad användaren stänga av den virtuella maskinen och ändra nätverket från Bridge till NAT. I en uppföljning beskrev han sin erfarenhet som en kompromiss: NAT ger åtkomst till värden, medan bryggläge ger åtkomst till andra enheter i LAN-nätverket.
Detta är officiell supportvägledning från källtråden från 2025, inte ett generellt påstående om alla libvirt-topologier.
Senare rapporter från communityn stämde fortfarande överens med värdisolering i macvtap
I maj–juni 2026 beskrev en annan tråd i communityn samma mönster: en bryggad virtuell maskin fick en normal LAN-IP-adress, kunde nå andra LAN-enheter men kunde inte använda ARP eller ansluta till ZimaOS-värden. När användaren växlade till NAT återställdes värdanslutningen omedelbart.
Användarna misstänkte att ZVM:s sökväg ”Bridge to eth0” implementerades med macvtap, vars värdisoleringsbeteende är välkänt. Den offentliga tråden innehöll ingen bekräftelse från IceWhale av den exakta backendlösningen, så macvtap bör fortfarande betraktas som en stark förklaring från communityn snarare än ett officiellt påstående om implementationen.
SMB-inloggningsproblem är ett separat lager
En deltagare växlade till NAT och kunde till slut nå ZimaCube-inloggningsdialogen, men SMB-konton fungerade fortfarande inkonsekvent. Huvudkontot kunde bläddra bland vissa sökvägar på värden medan åtkomsten till RAID misslyckades, och andra konton gav behörighetsfel.
När grundläggande IP-åtkomst finns ska SMB-delningens konto och behörigheter felsökas separat.
Aktuell dokumentation för ZimaOS beskriver Samba-delning per användare samt läs- och läs-/skrivbehörigheter. Använd den aktuella modellen för Samba-behörigheter för flera användare i ZimaOS när en virtuell maskin kan nå servern men autentisering eller åtkomst fortfarande misslyckas.
Ubuntus poster för fil- och fjärrdelning använder inte samma protokoll
Källans användare lade märke till att Ubuntu visade ”ZimaCube (File Sharing)” och ”ZimaCube (Remote Login)”. Lösenordshanteraren visade också en sftp://-anslutning för den senare.
SFTP över SSH och SMB är olika tjänster. En lyckad SFTP-inloggning bevisar inte att SMB-behörigheterna är korrekta, och en SMB-delning bör testas med en SMB-URL eller en webbläsare för nätverksdelningar, inte med SSH-posten.
En användare i communityn byggde en lösning med statiska rutter för bryggläge
En annan deltagare behöll den virtuella maskinen i bryggläge och använde en tredje Debian-server som router mellan den virtuella maskinen och värden. Därefter lade de till statiska rutter på båda slutpunkterna. De uppgav att det fungerade men kallade resultatet ”inte särskilt snyggt”.
Dessa Linux-routningskommandon var experiment från communityn, inte IceWhales rekommenderade ZVM-design. Den extra routern blir dessutom en flaskhals för genomströmningen och ytterligare en felkälla.
Välj nätverk utifrån den virtuella maskinens faktiska roll
- Den virtuella maskinen behöver främst nå tjänster eller delningar på ZimaOS-värden: NAT är det första testet som stöds av källan.
- Den virtuella maskinen behöver främst fungera som en separat LAN-enhet: Bryggläge kan ge den en normal LAN-adress.
- Den virtuella maskinen behöver både åtkomst till värden och LAN-nätverket: Testa den aktuella ZVM-versionen noggrant; den historiska källan visar att detta var den olösta luckan.
Aktuella nätverksinställningar i ZimaOS dokumenterar inte ett ZVM-arbetsflöde med br0
Den aktuella offentliga dokumentationen för nätverk i ZimaOS omfattar fysiska gränssnitt, DHCP/manuell IP-konfiguration och fjärråtkomst. Den publicerar ingen stödd procedur för att skapa en anpassad värdbrygga specifikt för att kringgå ZVM:s värdisolering.
Använd den aktuella nätverksmodellen för ZimaOS innan du manuellt redigerar värdrutter eller NetworkManager-filer.
Vanliga frågor om åtkomst till ZVM-värden
Gav NAT den virtuella maskinen i källan åtkomst till ZimaOS-värden?
Ja. Användare rapporterade att byte till NAT tog bort hindret med att ingen rutt till värden fanns.
Åtgärdade NAT automatiskt SMB-behörigheterna?
Nej. En användare nådde inloggningsdialogen men hade fortfarande separata problem med behörigheterna för delningen.
Var routningslösningen med den tredje servern officiell?
Nej. Det var en lösning från communityn för användare som ville behålla bryggläget.
