Problema

En entornos de virtualización con Proxmox, es frecuente usar la consola integrada del dashboard para tareas rápidas: inspeccionar logs, cambiar contraseñas o depurar arranques. Un síntoma que aparece en varios homelabs es que la consola de una VM deja de responder después de unos minutos. El cursor se queda estático, las teclas no llegan al guest y la pantalla muestra el último frame del login o del prompt. Lo curioso es que el resto del dashboard sigue operativo: otras VMs pueden arrancar, el menú de navegación funciona y el propio host sigue respondiendo. Además, el guest sigue activo a nivel de red: SSH, HTTP o cualquier otro servicio siguen accesibles mientras la consola está congelada. Cuando se reinicia la VM, la pérdida de conectividad ocurre de forma abrupta y la VM no vuelve a levantar sus servicios, obligando a un hard reset desde la interfaz de Proxmox. Este patrón indica un problema de interacción entre el visor de consola (noVNC/spice) y el subsistema de gráficos del guest, más que una falla del propio sistema operativo invitado.

Causa

Los congelamientos de la consola pueden deberse a varias causas que comparten un denominador: la pérdida de sincronía entre el framebuffer del guest y el cliente de VNC/Spice que corre en el navegador. Las causas más habituales son:

  1. Drivers de pantalla virtual desactualizados o incompatibles
    Proxmox usa QEMU/KVM con un dispositivo de video VGA o QXL. Cuando el kernel del guest se actualiza (por ejemplo, de Debian Bookworm a Trixie) sin recompilar los módulos de virtio-gpu o qxl, el driver puede dejar de enviar actualizaciones de pantalla, provocando que el buffer quede estático.

  2. Configuración de vga o qemu que fuerza un modo de video no soportado
    Opciones como -vga std o -vga qxl combinadas con resoluciones altas pueden saturar el canal de actualización. Si el guest intenta cambiar a una resolución que el host no puede negociar, el cliente no recibe más frames.

  3. Problemas de CPU throttling o I/O starvation
    Cuando el host está bajo alta carga (por ejemplo, backups simultáneos o discos saturados), el proceso qemu-kvm pierde tiempo de CPU y deja de procesar los eventos de VNC. El resultado es una consola que parece “congelada” aunque el guest siga ejecutándose.

  4. Versión del visor noVNC desalineada con la versión del servidor
    Proxmox 8 y 9 incluyen versiones diferentes de noVNC. Si el navegador cachea una versión antigua o si el proxy de Apache/Nginx interfiere, la conexión WebSocket puede romperse silenciosamente.

  5. Configuración de spice con cifrado o compresión inadecuada
    En algunos casos, habilitar spice con tls=1 sin los certificados correctos genera una caída del canal después de la negociación inicial.

  6. Problemas de red interna (VLAN, firewall) que bloquean paquetes UDP de VNC
    Aunque la consola usa WebSockets sobre TCP, el backend de QEMU puede intentar usar UDP para optimizar el flujo de video. Si una regla de firewall bloquea ese tráfico, la actualización de pantalla se detiene.

Solución

La estrategia consiste en aislar la capa que falla y aplicar correcciones que no requieran reinstalar todo el host. Los pasos a seguir son los mismos, independientemente de la distribución del guest o de la versión de Proxmox.

1. Verificar y actualizar drivers de video en el guest

En la mayoría de los sistemas Debian/Ubuntu basados en linux-image-*, el driver virtio-gpu se incluye por defecto. Sin embargo, después de una actualización mayor del kernel es prudente reinstalar los paquetes de qemu-guest-agent y spice-vdagent.

apt update
apt install --reinstall qemu-guest-agent spice-vdagent
systemctl restart qemu-guest-agent spice-vdagent

En CentOS/RHEL, el paquete equivalente es virtio-win o spice-vdagent.

2. Forzar un modo de video compatible

Edita la configuración de la VM desde la UI o el archivo /etc/pve/qemu-server/<VMID>.conf. Cambia la línea vga: a std o qxl según el caso, y añade video:virtio para usar el driver más ligero.

Ejemplo:

vga: std
video: virtio

Guarda y reinicia la VM. Si la consola vuelve a responder, el problema estaba en la resolución o en el tipo de dispositivo.

3. Limitar la carga del host

Revisa la carga con htop o pveperf. Si los backups o snapshots están programados en el mismo nodo, desplázalos a horarios de baja actividad o usa nice/ionice para bajar la prioridad de los procesos de I/O.

nice -n 10 ionice -c2 -n7 vzdump <VMID>

4. Actualizar el visor noVNC de Proxmox

En Proxmox 8/9, el paquete pve-manager contiene noVNC. Forzar una actualización garantiza que el cliente y el servidor usen la misma versión.

apt update
apt install --only-upgrade pve-manager
systemctl restart pveproxy

Después, limpia la caché del navegador o abre la consola en modo incógnito.

5. Desactivar la compresión/encapsulado de Spice (si se usa)

En la configuración de la VM, elimina la línea spice: 1 o agrega spice: 0. Luego, vuelve a habilitarla con parámetros mínimos:

spice: 0

Si la consola se vuelve estable, el problema estaba en la negociación TLS/compresión.

6. Revisar firewall interno

Asegúrate de que el nodo Proxmox permite tráfico en los puertos 5900‑5999 (VNC) y 3128 (WebSocket). En iptables o nftables, añade reglas de aceptación:

iptables -A INPUT -p tcp --dport 5900:5999 -j ACCEPT
iptables -A INPUT -p tcp --dport 3128 -j ACCEPT

7. Habilitar el registro de eventos de VNC

Para obtener pistas cuando la consola se congela, habilita el log de QEMU:

Edita /etc/pve/qemu-server/<VMID>.conf y añade:

args: -vnc :0,debug=1

Reinicia la VM y revisa /var/log/qemu-server/<VMID>.log. Busca líneas como VNC client disconnected o framebuffer update failed.

Cuándo aplicar esta solución

  • Síntomas: la consola del dashboard se queda estática, el teclado no responde, pero SSH y otros servicios siguen activos.
  • Entorno: Proxmox VE 8 o 9, VMs Linux (Debian, Ubuntu, CentOS) con acceso a noVNC o Spice.
  • No aplica: si la VM completa se cuelga (CPU 100 %, procesos zombie) o si la red del host está caída; en esos casos el problema es de la VM o del hardware, no de la consola.

Código

# Reinstalar agentes de video y guest
apt update && apt install --reinstall qemu-guest-agent spice-vdagent

# Forzar video std y virtio
sed -i 's/^vga:.*/vga: std/' /etc/pve/qemu-server/101.conf
sed -i '/^video:/d' /etc/pve/qemu-server/101.conf
echo "video: virtio" >> /etc/pve/qemu-server/101.conf

# Actualizar noVNC y reiniciar proxy
apt install --only-upgrade pve-manager
systemctl restart pveproxy

# Añadir regla de firewall para VNC
iptables -A INPUT -p tcp --dport 5900:5999 -j ACCEPT

Verificación

  1. Consola reactiva: abre la consola desde el dashboard y escribe algo; el cursor debe moverse inmediatamente.
  2. Logs limpios: revisa /var/log/qemu-server/<VMID>.log y confirma que no aparecen errores de framebuffer o VNC client disconnected.
  3. Persistencia tras reboot: reinicia la VM y verifica que la consola sigue respondiendo después de 10 minutos de uso continuo.
  4. Servicios intactos: confirma que SSH, HTTP y cualquier otro servicio siguen accesibles durante y después del test.

Notas adicionales

  • En entornos con muchos nodos, habilitar HA para el host evita que un hard reset sea la única salida; el agente de HA migrará la VM a otro nodo antes de que el problema se manifieste.
  • Si la consola sigue congelándose, considera cambiar a Serial Console (qm terminal <VMID>) como alternativa temporal; este método no depende de VNC y funciona siempre que el kernel tenga console=ttyS0.
  • Algunas versiones de Debian Trixie introducen cambios en systemd que retrasan la inicialización del agente spice-vdagent. Un systemctl enable spice-vdagent asegura que arranque en cada boot.

Con estos pasos deberías poder diagnosticar y resolver la mayoría de los congelamientos de la consola en Proxmox, manteniendo tu entorno de homelab estable y sin depender de reinicios forzados.