Solución de la comunidad

El puente de VM de ZimaOS no puede comunicarse con el 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.

Si una máquina virtual de ZimaOS que usa «Bridge to eth0» recibe una IP normal de la LAN y puede comunicarse con otros dispositivos de la LAN, pero no puede comunicarse con el propio host de ZimaOS, el comportamiento coincide con el conocido patrón de aislamiento de host de macvtap. En el hilo original, cambiar la máquina virtual a NAT restableció de inmediato la conectividad entre la máquina virtual y el host.

Sin embargo, el hilo no incluía una confirmación de IceWhale de que ZimaOS implemente definitivamente esa opción con macvtap de libvirt. Por lo tanto, la formulación correcta debe basarse en los síntomas: se comporta como un aislamiento de macvtap, en lugar de afirmar que la implementación interna es un hecho documentado.

El patrón de síntomas es muy específico

  • La máquina virtual recibe una dirección DHCP en la LAN física.
  • La máquina virtual puede comunicarse con los routers y otros dispositivos de la LAN.
  • La máquina virtual no puede resolver mediante ARP ni conectarse a la IP del host de ZimaOS.
  • El modo NAT restablece el acceso a los servicios que se ejecutan en el host.

Esto es diferente de una máquina virtual que no tiene red en absoluto. Afecta principalmente a los flujos de trabajo en los que el invitado debe comunicarse con un servicio vinculado directamente al host de ZimaOS.

Por qué esto parece macvtap

La guía de aislamiento de host de macvtap de libvirt documenta el mismo patrón: un invitado que usa una interfaz directa/macvtap puede comunicarse con la red externa, pero no directamente con su host de virtualización.

La referencia actual del formato de red de libvirt también distingue entre un puente de host preexistente y una conexión directa macvtap, y señala la limitación de macvtap para la comunicación entre el host y el invitado.

Usa NAT cuando la máquina virtual deba acceder a servicios del host de ZimaOS

En la prueba de la comunidad, el modo NAT fue la solución alternativa verificada. Si un proxy inverso dentro de la máquina virtual solo necesita acceso saliente a un servicio del host de ZimaOS, NAT puede ser más sencillo que forzar una interfaz conectada mediante puente a la LAN.

Si el invitado también necesita una dirección de primera clase en la LAN, una segunda interfaz de máquina virtual en una red virtual accesible desde el host es un patrón común de libvirt, pero que ZVM lo ofrezca correctamente depende de la interfaz y la versión actuales de ZimaOS.

Diseña el proxy inverso teniendo en cuenta el límite de red

Si Caddy o Nginx se ejecuta en una máquina virtual mientras Home Assistant u otro servicio se ejecuta directamente en el host de ZimaOS, verifica la accesibilidad del host antes de dedicar tiempo a la configuración de TLS o del proxy. La guía de proxy inverso de ZimaOS resulta útil una vez que funciona la conectividad básica de capa 3.

Para la configuración general de interfaces y direcciones IP, la guía de conexión de dispositivos de ZimaOS ofrece una referencia independiente.

En resumen

El hilo verifica el síntoma de red y la solución alternativa mediante NAT. No verifica la implementación exacta de ZimaOS. Considera «macvtap» como la mejor explicación técnica del aislamiento de host observado, a menos que la documentación actual de IceWhale confirme explícitamente el backend.