Soluzione della community

Il bridge VM di ZimaOS non riesce a raggiungere l'host: macvtap o NAT?

A user found that a ZVM bridged to eth0 could reach the LAN but not services on the ZimaOS host; switching the VM to NAT restored host connectivity.

Se una VM ZimaOS che utilizza “Bridge to eth0” riceve un normale IP della LAN e riesce a raggiungere gli altri dispositivi della LAN, ma non riesce a raggiungere direttamente l'host ZimaOS, il comportamento corrisponde al noto schema di isolamento dell'host di macvtap. Nel thread originale, il passaggio della VM alla modalità NAT ha ripristinato immediatamente la connettività tra VM e host.

Tuttavia, il thread non include una conferma da parte di IceWhale che ZimaOS implementi sicuramente questa opzione tramite macvtap di libvirt. La formulazione corretta deve quindi basarsi sui sintomi: il comportamento è simile all'isolamento di macvtap, senza affermare che l'implementazione interna sia un fatto documentato.

Lo schema dei sintomi è molto specifico

  • La VM riceve un indirizzo DHCP sulla LAN fisica.
  • La VM riesce a raggiungere router e altri dispositivi della LAN.
  • La VM non riesce a risolvere l'indirizzo ARP dell'IP dell'host ZimaOS né a connettersi a esso.
  • La modalità NAT ripristina l'accesso ai servizi in esecuzione sull'host.

Questo è diverso da una VM completamente priva di rete. Il problema riguarda soprattutto i flussi di lavoro in cui il guest deve chiamare un servizio associato direttamente all'host ZimaOS.

Perché sembra un problema di macvtap

La guida di libvirt all'isolamento dell'host con macvtap documenta lo stesso schema: un guest che utilizza un'interfaccia diretta/macvtap può raggiungere la rete esterna, ma non può comunicare direttamente con il proprio host di virtualizzazione.

L'attuale documentazione di riferimento sul formato di rete di libvirt distingue inoltre un bridge dell'host già esistente da una connessione diretta macvtap e segnala la limitazione della comunicazione tra host e guest imposta da macvtap.

Usa la modalità NAT quando la VM deve raggiungere i servizi dell'host ZimaOS

Nel test della community, la modalità NAT è risultata la soluzione alternativa verificata. Se un proxy inverso all'interno della VM ha bisogno soltanto dell'accesso in uscita a un servizio sull'host ZimaOS, il NAT può essere più semplice che forzare un'interfaccia con bridge sulla LAN.

Se il guest deve avere anche un indirizzo LAN dedicato, una seconda interfaccia della VM su una rete virtuale raggiungibile dall'host è uno schema comune di libvirt, ma la possibilità di esporla in modo semplice dipende dall'interfaccia e dalla versione attuali di ZVM e ZimaOS.

Progetta il proxy inverso tenendo conto del confine di rete

Se Caddy o Nginx viene eseguito in una VM mentre Home Assistant o un altro servizio è in esecuzione direttamente sull'host ZimaOS, verifica la raggiungibilità dell'host prima di dedicare tempo alla configurazione di TLS o del proxy. La guida al proxy inverso di ZimaOS è utile una volta che la connettività di base a livello 3 funziona.

Per la configurazione generale delle interfacce e degli IP, la guida alla connessione dei dispositivi ZimaOS fornisce una base separata.

In sintesi

Il thread verifica il sintomo di rete e la soluzione alternativa basata sul NAT. Non verifica l'implementazione precisa di ZimaOS. Considera “macvtap” la migliore spiegazione tecnica dell'isolamento osservato dell'host, a meno che la documentazione aggiornata di IceWhale non confermi esplicitamente il backend.