¿Por qué una máquina virtual de Proxmox pierde el acceso a la red después de migrar a otro puente?
Una máquina virtual de Proxmox puede perder el acceso a la red después de migrar de bridge cuando el nuevo bridge está conectado a una VLAN, un enlace ascendente o una ruta de Capa 2 diferente.
El guest puede conservar la misma dirección MAC, IP y puerta de enlace mientras el host cambia silenciosamente la forma en que sus tramas llegan al switch. Compara la configuración del bridge antiguo y del nuevo, los ajustes de VLAN-aware, los enlaces ascendentes físicos o agrupados y la visibilidad de los paquetes en el tap y la interfaz del host antes de cambiar nada dentro de la máquina virtual.
Compara el bridge antiguo y el nuevo como rutas de Capa 2
Registra el modelo de NIC de la máquina virtual, la dirección MAC, el nombre del bridge, la etiqueta VLAN, la configuración IP y la puerta de enlace antes y después de la migración. El nombre del bridge por sí solo no demuestra que la red que hay detrás sea equivalente.
Un caso real de homelab con Proxmox muestra cómo los cambios en la asignación de bridges y VLAN en Proxmox determinan qué tráfico llega realmente a la red física, incluso cuando la configuración de la máquina virtual sigue pareciendo sintácticamente válida.
Si el mismo guest funciona inmediatamente al volver a moverlo al bridge original, conserva ambas configuraciones de bridge y compara la ruta en lugar de restablecer el sistema operativo del guest.
Verifica el etiquetado de VLAN de extremo a extremo
Comprueba si la NIC de la máquina virtual está etiquetada, si el bridge reconoce VLAN y si el puerto del switch espera tramas etiquetadas o sin etiquetar para esa red. Mantén sin cambios la IP del guest durante esta prueba.
Una guía práctica sobre la configuración de VLAN en Proxmox ayuda a separar la pertenencia al bridge de la semántica de las VLAN; el guest puede estar conectado correctamente y aun así enviar tramas a la VLAN equivocada.
Captura tráfico en el bridge del host y en el enlace ascendente físico. Ver que ARP sale de la máquina virtual pero nunca aparece en la VLAN prevista identifica un límite en el host o en el switch antes de llegar al guest.
Demuestra que el nuevo bridge tiene el enlace ascendente correcto
Inspecciona qué NIC física, interfaz agrupada o interfaz virtual utiliza el nuevo bridge. Confirma el estado del enlace, la velocidad negociada y si otro servicio del host ya está utilizando o filtrando esa interfaz.
El comportamiento del bridge de Linux es importante aquí porque un bridge de Linux solo reenvía tramas a través de los puertos que realmente están conectados a él; un bridge sin un enlace ascendente utilizable puede seguir pareciendo correcto en la configuración.
Haz ping a la puerta de enlace desde el host a través de la red prevista cuando corresponda y, después, compara las capturas de paquetes en el tap de la máquina virtual y en el enlace ascendente. Corrige la pertenencia que falta al puerto o al grupo en lugar de cambiar el DNS del guest.
Limpia el estado obsoleto de los vecinos solo después de corregir la ruta
Después de cambiar de bridge, la máquina virtual conserva la misma MAC, mientras que los dispositivos ascendentes pueden haberla aprendido en otro puerto o VLAN. Comprueba las entradas ARP o de vecinos y el estado de reenvío del switch.
Los ejemplos de VLAN etiquetadas en Proxmox muestran cómo las decisiones de etiquetado del bridge y del switch determinan dónde se aprende esa MAC, por lo que un estado obsoleto de Capa 2 es un problema secundario plausible después de una migración correcta.
Limpia únicamente la entrada relevante de vecinos o de reenvío, o espera a que caduque normalmente, después de corregir la configuración. Borrar las cachés antes de corregir la ruta puede crear un éxito temporal que vuelva a desaparecer.
Verifica por separado la comunicación del guest con la puerta de enlace y la del cliente con el guest
Prueba la comunicación del guest con la puerta de enlace, del guest con un cliente de la LAN, del cliente de la LAN con el guest y el acceso a la aplicación. Esto permite distinguir entre una ruta predeterminada ausente y problemas de firewall, de ruta de retorno o de asociación del servicio.
La guía relacionada de configuración de un servidor doméstico Proxmox de ZimaSpace proporciona el contexto de virtualización complementario para mantener reproducibles los cambios del bridge, el almacenamiento y las máquinas virtuales en un servidor doméstico.
La migración solo se completa cuando la máquina virtual sobrevive a un reinicio en el nuevo bridge y ambas direcciones del flujo original de la aplicación funcionan sin borrar manualmente ARP ni alternar el bridge.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
