Un invitado de ZVM puede tener una dirección LAN válida y aun así no poder acceder a los servicios que se ejecutan en el propio host ZimaOS. Ese fue el problema central de este hilo. Con la máquina virtual configurada como Puente a eth0, el invitado podía participar en la LAN, pero no tenía ninguna ruta al host. Zima-Giorgio recomendó cambiar la máquina virtual a NAT cuando el objetivo fuera conectarse a los recursos compartidos de ZimaOS.
La fuente también muestra que la «ruta de red» y el «permiso SMB» son problemas independientes. Más adelante, otro usuario cambió a NAT y llegó al cuadro de diálogo de inicio de sesión, pero seguía sin poder acceder al recurso compartido RAID con varias cuentas. Ese problema de autenticación y almacenamiento no debe confundirse con el aislamiento del host en modo puente.
El modo puente proporcionaba al invitado un acceso LAN normal
El usuario original seleccionó Puente a eth0 porque quería que la máquina virtual se comportara como otro dispositivo de la red local. En ese modo, la máquina virtual podía obtener una dirección LAN y comunicarse con otros sistemas de la LAN.
La ruta que faltaba era específicamente la comunicación entre la máquina virtual y el host ZimaOS.
Zima-Giorgio recomendó NAT para acceder al host
Zima-Giorgio, de IceWhale, indicó al usuario que apagara la máquina virtual y cambiara la red de Puente a NAT. En un mensaje posterior, describió su experiencia como una solución de compromiso: NAT permite acceder al host, mientras que el puente proporciona acceso a otros dispositivos de la LAN.
Se trata de una recomendación oficial del hilo de la fuente de 2025, no de una afirmación genérica sobre todas las topologías de libvirt.
Informes posteriores de la comunidad seguían coincidiendo con el aislamiento del host de macvtap
En mayo y junio de 2026, otro hilo de la comunidad describió el mismo patrón: una máquina virtual en modo puente recibía una IP LAN normal, podía acceder a otros dispositivos de la LAN, pero no podía resolver ARP ni conectarse al host ZimaOS. Al cambiar a NAT, la conectividad con el host se restableció de inmediato.
Los usuarios sospechaban que la ruta «Puente a eth0» de ZVM estaba implementada mediante macvtap, cuyo comportamiento de aislamiento del host es bien conocido. El hilo público no incluía una confirmación de IceWhale sobre el backend exacto, por lo que macvtap debe considerarse una explicación sólida de la comunidad, no una afirmación oficial sobre la implementación.
Los problemas de inicio de sesión SMB pertenecen a otra capa
Un participante cambió a NAT y por fin pudo acceder al cuadro de diálogo de inicio de sesión de ZimaCube, pero las cuentas SMB seguían comportándose de forma incoherente. Su cuenta principal podía explorar algunas rutas del host, mientras que el acceso al RAID fallaba, y otras cuentas devolvían errores de permisos.
Una vez que existe conectividad IP básica, soluciona por separado los problemas de la cuenta y los permisos del recurso compartido SMB.
La documentación actual de ZimaOS contempla el uso compartido de Samba por usuario y los permisos de solo lectura o lectura y escritura. Usa el modelo actual de permisos multiusuario de Samba de ZimaOS cuando una máquina virtual puede acceder al servidor, pero la autenticación o el acceso siguen fallando.
Las entradas de uso compartido de archivos e inicio de sesión remoto de Ubuntu no usan el mismo protocolo
El usuario de la fuente observó que Ubuntu mostraba «ZimaCube (Uso compartido de archivos)» y «ZimaCube (Inicio de sesión remoto)». Su gestor de contraseñas también mostraba una conexión sftp:// para esta última.
SFTP sobre SSH y SMB son servicios diferentes. Un inicio de sesión SFTP correcto no demuestra que los permisos SMB sean correctos, y un recurso compartido SMB debe probarse con una URL SMB o con un explorador de recursos compartidos de red, no mediante la entrada SSH.
Un usuario de la comunidad creó una solución con rutas estáticas para el modo puente
Otro participante mantuvo la máquina virtual en modo puente y utilizó un tercer servidor Debian como enrutador entre la máquina virtual y el host; después añadió rutas estáticas en ambos extremos. Informó de que funcionaba, pero calificó el resultado de «poco elegante».
Esos comandos de enrutamiento de Linux fueron experimentos de la comunidad, no el diseño recomendado por IceWhale para ZVM. Además, el enrutador adicional se convierte en un cuello de botella para el rendimiento y en otro posible punto de fallo.
Elige la red según la función real de la máquina virtual
- La máquina virtual necesita principalmente acceder a servicios o recursos compartidos alojados en ZimaOS: NAT es la primera prueba recomendada por la fuente.
- La máquina virtual debe comportarse principalmente como un dispositivo independiente de la LAN: el puente puede proporcionar una dirección LAN normal.
- La máquina virtual necesita acceder tanto al host como a la LAN: prueba cuidadosamente la versión actual de ZVM; la fuente histórica muestra que esta era la limitación no resuelta.
La configuración de red actual de ZimaOS no documenta un procedimiento con br0 para ZVM
La documentación pública actual sobre redes de ZimaOS cubre las interfaces físicas, la configuración de IP mediante DHCP o manual y el acceso remoto. No publica un procedimiento compatible para crear un puente de host personalizado que evite específicamente el aislamiento del host de ZVM.
Consulta el modelo de red actual de ZimaOS antes de editar manualmente las rutas del host o los archivos de NetworkManager.
Preguntas frecuentes sobre el acceso de ZVM al host
¿NAT permitió que la máquina virtual de la fuente accediera al host ZimaOS?
Sí. Los usuarios informaron de que cambiar a NAT eliminaba la barrera de «no hay ruta al host».
¿NAT solucionó automáticamente los permisos SMB?
No. Un usuario pudo acceder al cuadro de diálogo de inicio de sesión, pero siguió teniendo problemas independientes con los permisos del recurso compartido.
¿La solución de enrutamiento mediante un tercer servidor era oficial?
No. Era una solución de la comunidad para quienes querían mantener el modo puente.
