qm guest cmd network-get-interfaces tiene un nombre demasiado largo para algo que hace una pregunta bastante humana.
¿Qué IP tiene esta VM ahora mismo?
No la IP que creo que tiene. No la que apunté en una nota hace tres semanas. No la que sale en una reserva DHCP que quizá ya no aplica. La que el sistema invitado está viendo desde dentro en este momento.
En un homelab con pocas máquinas puede parecer una tontería. En cuanto empiezas a tener varias VMs, plantillas, clones, redes de pruebas, servicios movidos y algún cambio de DHCP hecho con prisa, deja de serlo. La IP de una VM es uno de esos datos que parecen obvios hasta que no lo son.
Si me pilla un problema de cluster en Proxmox y necesito una respuesta rápida a la pregunta importante, suelo ir a una frase muy concreta.
¿Hay quorum o no lo hay?
Todo lo demás viene después.
Por eso corosync-quorumtool -s me gusta tanto. No tiene el barniz cómodo de pvecm status. No intenta ser amable. Te suelta la información bastante en seco y se acabó.
Y, sinceramente, a ciertas horas eso me parece perfecto.
Cuando un cluster Proxmox empieza a oler raro, hay una tentación muy humana y muy mala.
Abrir corosync.conf, ver muchas llaves, ponerse serio y empezar a tocar cosas sin haber leído antes el mapa.
Yo intento no hacerlo.
Antes de pensar en cambios, lo que quiero es una lectura corta del cableado lógico del cluster. Qué nodo es cuál. Qué nodeid tiene cada uno. Qué dirección ring0_addr usa el cluster para hablar con él. Y si el nombre que aparece ahí sigue correspondiendo con la historia que yo me estoy contando.
Hay una clase de susto de Proxmox que siempre llega mal.
No tienes un error bonito. No tienes un botón rojo. No tienes una frase útil que te diga “mira aquí”. Lo que tienes es una sensación rara. Un nodo tarda. El cluster parece vivo pero no termina de sonar limpio. pvecm status da una foto, sí, pero te falta la película.
Por eso tiro mucho de esto.
1 journalctl -u corosync -n 40 --no-pager No es el comando con mejor marketing de la serie. Tampoco el más cómodo de leer. Pero cuando quiero entender qué está haciendo la red del cluster en los últimos segundos o minutos, pocas cosas me resultan más útiles.
Hay comandos que uso para entender el cluster. Y luego hay comandos que uso para dejar de discutir con él.
corosync-cfgtool -s está claramente en el segundo grupo.
Cuando la red del cluster da mala espina, cuando un nodo tarda en reaparecer, cuando pvecm status sale bien pero yo sigo desconfiando o cuando me planteo tocar interfaces de Corosync, este comando me ayuda a responder una pregunta muy concreta. Desde este nodo, ¿el enlace de Corosync sigue conectado a sus vecinos o solo estoy suponiéndolo?
Si solo pudiera lanzar un comando antes de reiniciar un nodo Proxmox, tocar la red del cluster o ponerme estupendo con una migración, sería pvecm status.
No porque me lo cuente todo. No lo hace. Pero sí porque me da la respuesta que manda antes de casi cualquier otra cosa. ¿El cluster tiene quorum o estoy a punto de hacer una tontería con muy mal timing?
A veces Proxmox te deja confiarte. La interfaz web abre, las VMs siguen arriba y pvecm nodes todavía te enumera miembros. Todo parece razonable. Luego miras pvecm status y te das cuenta de que la tranquilidad era más estética que real.
Hay un momento muy concreto en el que me gusta lanzar systemctl status corosync en Proxmox. Justo cuando el cluster parece suficientemente bien como para confiarse, pero no tan bien como para que yo quiera tocar algo sin mirar antes debajo del capó.
Porque una cosa es que la interfaz web cargue. Otra que pvecm nodes siga enseñando miembros. Y otra muy distinta que el servicio de Corosync esté realmente tranquilo. No medio vivo. No “bueno, parece que aguanta”. Tranquilo.
Hay fallos que se agradecen porque son honestos. El servicio no arranca, el nodo se cae o el storage sale claramente inactivo y ya sabes que toca arreglar algo. Luego están los otros, los que te miran a la cara con media verdad. Esta madrugada me encontré justo uno de esos en Proxmox.
Tenía un storage CIFS configurado en el cluster para usarlo con ISOs, backups puntuales y algún archivo compartido. Nada exótico. Lo raro fue esto. En dos nodos el recurso seguía apareciendo montado, el mount lo enseñaba sin rubor y, si te quedabas en la superficie, podías pensar que el problema era menor. Pero en cuanto intentaba tocar ese punto de montaje con df -h, la respuesta era bastante menos diplomática. Host is down.
Hay tecnologías que funcionan tan bien en una demo corta que te hacen pensar que ya has resuelto un problema entero. mDNS es una de ellas. Conectas un dispositivo, aparece con su nombre, abres equipo.local y durante un momento todo parece civilizado. Luego pasa una semana, metes un par de VLANs, pruebas desde otro sistema operativo, intentas usar el mismo nombre desde VPN o desde otra subred, y descubres que el invento no estaba roto. Simplemente estaba resolviendo un problema mucho más pequeño del que tú querías arreglar.
Hay una fase muy concreta en cualquier homelab con Proxmox en la que uno se viene arriba. Montas el cluster, ves los nodos juntos en la interfaz, pruebas una migración y piensas que ya está, que lo serio era llegar hasta ahí. Luego pasan unas semanas, metes más carga, empiezas a mover backups, storage, tráfico de servicios, alguna copia pesada, algún reinicio tonto de switch, y descubres la parte menos sexy del asunto. El cluster no vive de la ilusión. Vive de red estable.
Hace unos días publiqué mi guía base de Tailscale. Ahí contaba por qué dejé de pelearme con WireGuard puro para el acceso diario al homelab. Esa parte sigue siendo cierta. Instalar Tailscale sigue siendo ridículamente fácil. Lo que ya no me parece tan sencillo es diseñarlo bien cuando tu red deja de ser cuatro cacharros y empieza a parecer una pequeña jungla.
Ese es el punto en el que casi todas las guías se quedan cortas. Te enseñan a hacer tailscale up, ves el dispositivo en el panel y te vienes arriba. Luego pasan dos semanas, quieres acceder a un switch que no puede instalar el cliente, quieres sacar internet por casa cuando estás de viaje, o decides que igual no te hace gracia que todos los nodos hablen con todos. Ahí empieza el trabajo real.
Cuando monté mi homelab hace unos años, lo primero que quería era acceder a mis servicios desde fuera de casa sin abrir puertos al mundo. Empecé con OpenVPN, que funcionaba pero era una pesadilla de configurar. Luego me pasé a Tailscale, que sigue siendo mi opción favorita para redes mesh complejas. Pero hace unos meses descubrí wg-easy, y para casos simples es lo que uso ahora.
WireGuard en sí lleva años disponible. El problema siempre ha sido la configuración. Generar claves, editar archivos de configuración manualmente, distribuir los perfiles a los clientes… no es complicado, pero tiene fricción suficiente como para que muchos lo dejen a medias. wg-easy resuelve exactamente ese problema: es un contenedor Docker que levanta WireGuard con una interfaz web desde la que puedes gestionar clientes en dos clics.