Monitor Proxmox en Stream Deck: montaje seguro en LXC

Si tienes un Elgato Stream Deck guardado en un cajón, puede funcionar como un panel de monitoreo sorprendentemente bueno para Proxmox. Dejas de abrir la interfaz web cada vez que quieres comprobar la carga de la CPU, el estado de los invitados, el tráfico de red o si un servicio está activo, porque esos datos están en teclas físicas junto al servidor. Sin embargo, me importa menos el hardware que cómo está planteado el montaje.

Un proyecto reciente colocó el agente de monitoreo en su propio LXC sin privilegios, le asignó un token de API de Proxmox de solo lectura, redirigió el dispositivo USB del Stream Deck hacia ese contenedor y utilizó las teclas para mostrar el estado del host y de las VMs. Puedes navegar entre métricas del host, estado de los invitados, rendimiento de red, un test de velocidad manual y comprobaciones simples de estado por HTTP. Eso es mucho mejor que ejecutar un proceso de Python cualquiera como root en el hipervisor. Si quieres un panel físico para Proxmox, procura que sea de solo lectura, aislado y fácil de desechar.

¿Qué puede mostrar realmente un Stream Deck desde Proxmox?

Casi cualquier dato de estado que exponga la API de Proxmox cabe en un mosaico pequeño. El proyecto que motiva este artículo genera actualmente cinco páginas. La página Host muestra el uso de CPU, RAM, uso de disco, swap, carga media y tiempo de actividad. La página Guests enumera las VMs y los LXC como activos o detenidos, junto con el uso de CPU. La página Network agrega el tráfico e identifica los mayores consumidores, y la página Speedtest ejecuta una prueba real de velocidad de internet desde el contenedor de monitoreo. La página Health comprueba los endpoints HTTP o HTTPS configurados y muestra cada servicio con un icono verde o rojo.

Para un panel físico, esa es aproximadamente la cantidad adecuada. Un Stream Deck no es Grafana, y atiborrar unas pequeñas teclas LCD con gráficos, registros, histogramas de latencia de almacenamiento y veinte alertas arruinaría la experiencia. Funciona mejor cuando cada casilla responde a una pregunta directa: ¿está saturado el host?, ¿sigue en marcha Home Assistant?, ¿qué VM consume ancho de banda?, ¿responde el proxy inverso?, ¿se está llenando el almacenamiento? Cuando necesites más detalles, abre tu sistema de monitoreo real; el Stream Deck es a lo que echas un vistazo antes de hacerlo.

Para ampliar ideas sobre monitoreo e infraestructura, el hub de Proxmox de Mr.PlanB cubre la plataforma más allá de este experimento de panel.

¿Por qué ejecutar el agente de monitoreo dentro de un LXC?

Porque el host de Proxmox debe mantenerse lo más simple y aburrido posible. El agente de Stream Deck es un proceso de Python de terceros. Se comunica con hardware USB, consulta APIs, genera imágenes, ejecuta comprobaciones de red e incorpora paquetes como hidapi, libusb, Pillow, Requests y una biblioteca de Stream Deck. Nada de eso pinta en el hipervisor sin una razón de peso.

En su lugar, el proyecto crea un LXC Debian sin privilegios y ejecuta el agente allí como un usuario dedicado no root. Eso le da al experimento un límite de fallo limpio. Si un paquete de Python se rompe, reinicias el contenedor. Si la configuración se vuelve un desastre, lo reconstruyes. Si pierdes el interés, lo eliminas. Y si alguien compromete el agente a través de una dependencia o un destino de comprobación de salud, aterriza en un contenedor sin privilegios, no directamente en el entorno del host de Proxmox. Se puede vulnerar el LXC, pero el radio de impacto es mucho menor.

Proxmox explica que los contenedores sin privilegios utilizan espacios de nombres de usuario (user namespaces), de modo que el UID 0 dentro del contenedor se asigna a un UID sin privilegios en el host. Para una pequeña carga de trabajo auxiliar como esta, ese es exactamente el aislamiento que buscas.

¿Qué permisos de Proxmox debería tener el panel?

Solo los necesarios para leer el estado. La implementación de referencia crea un usuario de Proxmox dedicado y le asigna el rol integrado PVEAuditor en /. Ese rol está pensado para visibilidad de solo lectura. El agente se autentica mediante un token de API y consulta la API REST de Proxmox a través de HTTPS.

Lo importante es lo que el panel no puede hacer. No puede iniciar ni detener una VM, no puede borrar almacenamiento, no puede cambiar un puente de red, no puede modificar un contenedor ni alterar la configuración del clúster. Ese es el valor por defecto correcto. Un panel de monitoreo no tiene por qué tener permisos de administrador solo porque la API los ofrezca.

Alguien en la comunidad describió otra configuración con Stream Deck donde un botón abre Escritorio remoto o PuTTY según la VM. Eso sigue siendo bastante inofensivo, ya que el botón lanza una aplicación cliente y no cambia el estado de la infraestructura mediante la API de Proxmox.

Sin embargo, ya se ve hacia dónde va esto. En cuanto hay botones físicos, alguien querrá una tecla para "reiniciar VM", una tecla para "apagar nodo" o un botón rojo gigante que ponga "no pulsar". Muy bien para un laboratorio, pero esas acciones no deberían usar las credenciales del servicio de monitoreo. Si añades acciones de escritura, crea una ruta de control separada con sus propias credenciales y salvaguardas explícitas. No cueles permisos de administrador dentro del token de monitoreo.

¿Cómo funciona el passthrough de USB?

Esta es la parte menos elegante del montaje. El Stream Deck se conecta al host de Proxmox, pero el agente de Python se ejecuta dentro de un LXC sin privilegios, de modo que el contenedor necesita acceder al dispositivo USB. El proyecto autoriza dispositivos de caracteres USB y monta mediante bind el árbol /dev/bus/usb del host dentro del contenedor. La configuración del LXC incluye el equivalente a:

lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb dev/bus/usb none bind,optional,create=dir

Una regla de udev en el host establece después los permisos para los dispositivos Elgato utilizando el vendor ID de USB 0fd9.

¿Por qué montar todo el árbol del bus USB y no una única ruta de dispositivo? Los números de los dispositivos USB cambian. Un Stream Deck que aparece bajo una ruta /dev/bus/usb/... puede reaparecer en otra distinta después de desconectarlo y volverlo a conectar. Montar todo el árbol permite al contenedor ver el dispositivo reenumerado sin tener que editar la configuración cada vez.

Eso resulta cómodo, y también expone más de lo que expondría pasar un único nodo de dispositivo fijo. En este diseño, la restricción práctica proviene de los permisos de los dispositivos en el host y del hecho de que el LXC no tiene privilegios. Si el host tiene otros dispositivos USB sensibles conectados, revisa bien lo que estás exponiendo antes de copiar la configuración.

En un host de homelab dedicado con un solo Stream Deck conectado, puedo convivir con ese compromiso. En un servidor de producción con llaves de seguridad USB, dongles de licencias, medios de backup u otros periféricos con privilegios, tendría muchísimo más cuidado.

¿Por qué puede desaparecer el Stream Deck al desconectarlo?

Las bibliotecas USB no siempre se recuperan limpiamente cuando se retira un dispositivo. El autor se topó con esto en hidapi y libusb: tras desconectar y volver a conectar el Stream Deck, el proceso podía dejar de encontrar el dispositivo. Reiniciar el servicio de monitoreo completo limpiaba el estado obsoleto, por lo que el proyecto añadió un comportamiento tipo watchdog. Si no se detecta ningún Stream Deck durante un periodo configurado, el proceso finaliza y systemd lo inicia de nuevo con un estado limpio en la biblioteca USB.

En un mundo ideal, la pila de bibliotecas gestionaría cada reconexión a la perfección. En la práctica, la solución es "si el dispositivo lleva demasiado tiempo ausente, reinicia el pequeño servicio", y esa es una forma sensata de construir para el hardware real que tienes. Para un dispositivo de monitoreo es una estrategia de recuperación aceptable, porque el servicio guarda tan poco estado que reiniciarlo apenas cuesta nada.

¿Por qué se atenúa el panel tras un periodo de inactividad?

Principalmente para que las imágenes estáticas no estén encendidas todo el tiempo. El montaje atenúa el Stream Deck tras 25 segundos sin pulsar ningún botón y lo reactiva en cuanto se toca una tecla. El repositorio señala que el ahorro energético no es la razón principal, ya que los dispositivos Stream Deck consumen muy poca energía de todas formas. El objetivo es evitar que los mismos mosaicos brillantes estén iluminados día y noche.

Es un detalle menor, pero hace que el proyecto se perciba como un electrodoméstico dedicado y menos como una demo. Cuando todo está normal, el panel pasa a un segundo plano. Tócalo cuando quieras información. Cuando algo requiera atención, los colores de las teclas deberían hacerlo evidente sin que tengas que pulsar nada.

¿Es esto mejor que Grafana o la interfaz de Proxmox?

No, cumple una función distinta. Grafana es superior para métricas históricas, paneles detallados, correlaciones, alertas y tendencias. La interfaz de Proxmox es donde realmente administras el entorno. Una pila de monitoreo en condiciones se encarga de las notificaciones. El Stream Deck te ofrece conciencia ambiental del entorno.

Resulta más útil cuando el host de Proxmox está en la misma habitación que tu mesa, rack, banco de pruebas u oficina. Puedes ver que todos los invitados están en verde sin cambiar de ventana, notar que una VM consume un ancho de banda inusual o pulsar una tecla para una prueba rápida de velocidad. No reemplazará a tu monitoreo, pero lo abrirás con menos frecuencia. Parece poca cosa hasta que cuentas cuántas veces al día los administradores de homelabs revisan los mismos valores de estado.

¿Qué haría que el panel fuera más útil?

Probablemente ganaría más con mejores señales que con más métricas en bruto. Una casilla de backup podría mostrar la antigüedad de la última copia de seguridad exitosa, y una de almacenamiento podría ponerse en ámbar cuando un pool ZFS pasa a estado degradado. Un mosaico de Ceph podría resumir HEALTH_OK, HEALTH_WARN o HEALTH_ERR. Un icono de SAI (UPS) podría mostrar la alimentación de red, el porcentaje de batería y la autonomía restante, mientras que uno de clúster podría reflejar el estado del quórum. Un mosaico de PBS podría indicar si la última verificación del datastore terminó con éxito. Una casilla de certificados podría advertir cuando a un certificado TLS importante le quedan menos de 30 días, y una de parches podría señalar actualizaciones pendientes de Proxmox sin instalarlas.

Cada una de ellas sigue siendo de solo lectura, que es donde yo las mantendría. Un panel físico que te indica qué merece una mirada más atenta, y que no puede cambiar nada, sigue siendo útil y de bajo riesgo. En cuanto se transforma en una consola de control, cada botón exige pensarlo mucho más.

¿Conviene copiar los scripts de instalación directamente?

Léelos primero. El proyecto incluye dos scripts que crean el LXC, configuran el passthrough de USB, generan el usuario y el token de la API, instalan dependencias y configuran el servicio de systemd. Resulta práctico para un proyecto de homelab, pero también es automatización a nivel de root ejecutándose en un host de Proxmox.

Según el autor, los scripts se escribieron con ayuda de IA. Eso no es bueno ni malo por sí mismo. Lo que ayuda es que el repositorio es lo bastante pequeño como para leerlo de una sentada.

Antes de ejecutar como root cualquier script de configuración de la comunidad, revisa las partes que:

• modifican /etc/pve/lxc
• crean usuarios o tokens de Proxmox
• editan reglas de udev
• cambian permisos de dispositivos USB
• instalan paquetes
• descargan dependencias de Python
• crean unidades de systemd

No hace falta desconfiar del autor. Lo que sí hace falta es saber qué le estás pidiendo hacer a tu hipervisor, y eso aplica a cualquier script de comodidad.

Un Proxmox Health Check resulta útil para revisar el propio host, pero conviene entender la automatización de la comunidad antes de que pase a formar parte de ese host.

El mejor panel físico para Proxmox debe ser aburrido

El Stream Deck es la parte llamativa, y las buenas decisiones de ingeniería son mucho más difíciles de percibir. El agente se ejecuta en su propio LXC sin privilegios como usuario no root. Utiliza un token de API de solo lectura y consulta mediante peticiones GET. Puedes reconstruirlo sin tocar el hipervisor. Cuando las reconexiones USB fallan, reinicia un pequeño servicio sin estado y deja en paz al host.

Por eso esto resulta más interesante que un panel de adorno. Muestra un patrón que vale la pena aplicar a las herramientas de homelab en general: coloca las herramientas de comodidad cerca de tu infraestructura, pero no les des la misma autoridad que a la infraestructura.

Un Stream Deck lleno de botones verdes y rojos es entretenido; uno que no pueda romper nada por accidente es todavía mejor.