Un guest ZVM può avere un indirizzo LAN valido e continuare a non riuscire a raggiungere i servizi in esecuzione sull'host ZimaOS stesso. Questo era il problema principale discusso in questa discussione. Con la VM impostata su Bridge to eth0, il guest poteva partecipare alla LAN, ma non disponeva di una route verso l'host. Zima-Giorgio ha consigliato di passare a NAT quando l'obiettivo era connettersi alle condivisioni di ZimaOS.
La fonte mostra inoltre che il problema della «route di rete» e quello dei «permessi SMB» sono distinti. In seguito, un altro utente è passato a NAT e ha raggiunto la finestra di accesso, ma non è comunque riuscito ad accedere alla condivisione RAID con diversi account. Questo problema di autenticazione e archiviazione non va confuso con il problema di isolamento dell'host in modalità bridge.
La modalità Bridge ha fornito alla VM la normale raggiungibilità LAN
L'utente originale ha selezionato Bridge to eth0 perché voleva che la VM si comportasse come un altro dispositivo della rete locale. In questa modalità, la VM poteva ottenere un indirizzo LAN e comunicare con gli altri sistemi della LAN.
Il percorso mancante riguardava specificamente la comunicazione tra VM e host ZimaOS.
Zima-Giorgio ha consigliato NAT per l'accesso all'host
Zima-Giorgio di IceWhale ha chiesto all'utente di arrestare la VM e modificare la rete da Bridge a NAT. In un messaggio successivo, ha descritto la propria esperienza come un compromesso: NAT consente di accedere all'host, mentre il bridge consente di accedere agli altri dispositivi della LAN.
Si tratta di una raccomandazione ufficiale dell'assistenza, tratta dalla discussione del 2025, non di un'affermazione generica su ogni topologia libvirt.
Le segnalazioni successive della community corrispondevano ancora all'isolamento dell'host di macvtap
Tra maggio e giugno 2026, un'altra discussione della community ha descritto lo stesso schema: una VM in bridge riceveva un normale IP LAN, poteva raggiungere gli altri dispositivi della LAN, ma non riusciva a risolvere l'ARP o a connettersi all'host ZimaOS. Il passaggio a NAT ha ripristinato immediatamente la connettività con l'host.
Gli utenti sospettavano che il percorso «Bridge to eth0» di ZVM fosse implementato tramite macvtap, il cui comportamento di isolamento dell'host è ben noto. La discussione pubblica non includeva una conferma di IceWhale sul backend esatto, quindi macvtap dovrebbe rimanere una spiegazione plausibile della community, non un'affermazione ufficiale sull'implementazione.
I problemi di accesso SMB appartengono a un livello separato
Un partecipante è passato a NAT ed è finalmente riuscito a raggiungere la finestra di accesso di ZimaCube, ma gli account SMB continuavano a comportarsi in modo incoerente. Con l'account principale poteva esplorare alcuni percorsi dell'host, mentre l'accesso al RAID non riusciva; con altri account comparivano errori di autorizzazione.
Una volta stabilita la raggiungibilità IP di base, è necessario verificare separatamente l'account della condivisione SMB e i relativi permessi.
La documentazione attuale di ZimaOS descrive la condivisione Samba per utente e i permessi di sola lettura o lettura-scrittura. Usa il modello attuale di ZimaOS per i permessi Samba multiutente quando una VM riesce a raggiungere il server, ma l'autenticazione o l'accesso continuano a non funzionare.
Le voci Condivisione file e Accesso remoto di Ubuntu non usano lo stesso protocollo
L'utente della fonte ha notato che Ubuntu mostrava «ZimaCube (Condivisione file)» e «ZimaCube (Accesso remoto)». Il suo gestore di password mostrava inoltre una connessione sftp:// per quest'ultima.
SFTP su SSH e SMB sono servizi diversi. Un accesso SFTP riuscito non dimostra che i permessi SMB siano corretti; una condivisione SMB dovrebbe essere testata con un URL SMB o con un browser delle condivisioni di rete, non tramite la voce SSH.
Un utente della community ha creato una soluzione con route statiche per la modalità Bridge
Un altro partecipante ha mantenuto la VM in bridge e ha usato un terzo server Debian come router tra la VM e l'host, aggiungendo poi route statiche su entrambi gli endpoint. Ha riferito che la soluzione funzionava, definendola però «non proprio elegante».
Quei comandi di routing Linux erano esperimenti della community, non il design ZVM raccomandato da IceWhale. Il router aggiuntivo diventa inoltre un collo di bottiglia per il throughput e un ulteriore punto di guasto.
Scegli la rete in base al ruolo effettivo della VM
- La VM deve principalmente raggiungere servizi o condivisioni ospitati da ZimaOS: NAT è il primo test supportato dalla fonte.
- La VM deve principalmente comportarsi come un dispositivo LAN separato: il bridge può fornire un normale indirizzo LAN.
- La VM deve raggiungere sia l'host sia la LAN: testa attentamente la versione attuale di ZVM; la fonte storica mostra che questo era il problema ancora irrisolto.
Le impostazioni di rete attuali di ZimaOS non documentano una procedura br0 per ZVM
La documentazione pubblica attuale sulla rete di ZimaOS tratta le interfacce fisiche, la configurazione IP tramite DHCP o manuale e l'accesso remoto. Non pubblica una procedura supportata per creare un bridge personalizzato dell'host specificamente per aggirare il comportamento di isolamento dell'host di ZVM.
Consulta il modello di rete attuale di ZimaOS prima di modificare manualmente le route dell'host o i file di NetworkManager.
Domande frequenti sull'accesso all'host da ZVM
NAT ha consentito alla VM della fonte di raggiungere l'host ZimaOS?
Sì. Gli utenti hanno riferito che il passaggio a NAT ha eliminato il blocco dovuto all'assenza di una route verso l'host.
NAT ha risolto automaticamente i permessi SMB?
No. Un utente ha raggiunto la finestra di accesso, ma ha continuato ad avere problemi separati con i permessi delle condivisioni.
La soluzione di routing tramite un terzo server era ufficiale?
No. Era una soluzione della community per gli utenti che volevano mantenere la modalità bridge.
