La alta disponibilidad en homelab tiene una capacidad especial para volvernos optimistas cuando no toca. Montas HA, ves que una VM arranca en otro nodo, te vienes arriba y empiezas a pensar que el cluster ya se cuida solo. Luego llega una noche cualquiera, abres una shell, ves cuatro líneas en verde y decides reiniciar un host porque total, para eso está la magia. Ahí suele empezar la parte divertida.
Yo uso ha-manager status justo para evitar ese autoengaño. No es un comando espectacular. No te da gráficas bonitas ni vende ninguna épica. Pero sí me da una foto muy útil de cómo está respirando la capa HA de Proxmox antes de tocar nada serio.
Y digo “útil” con intención. No “suficiente”. Esa es la clave. ha-manager status me ayuda mucho, pero solo cuando lo leo con mala leche y sin concederle más inteligencia de la que realmente tiene.
por qué lo miro siempre antes de tocar un nodo#
Porque HA no arregla el contexto. Arregla ciertas caídas. Y no siempre de la forma que más te conviene.
Si voy a actualizar un host, reiniciarlo o mover carga, quiero saber tres cosas.
- si la capa HA está realmente operativa
- qué recursos están bajo gestión HA
- dónde están viviendo ahora mismo esos recursos
La tentación normal es mirar solo pvecm status, ver quorum y dar el resto por bueno. Eso es quedarse a medio camino. El cluster puede estar quorate y, aun así, la foto de HA no ser la que te interesa para esa ventana de mantenimiento.
A mí ha-manager status me aporta justo ese segundo nivel. No me dice todo, pero me dice bastante como para decidir si sigo o si cierro la terminal y me hago un favor.
una salida real que resume bien lo que busco#
Esta captura sale de una comprobación real en uno de mis nodos. Está saneada para no enseñar nombres internos ni direcciones del lab.
Lo primero que miro es la primera línea. quorum OK.
Suena obvio, pero no lo trato como decoración. Si HA no tiene quorum, no estoy delante de un sistema tranquilo. Estoy delante de un sistema que ya viene con una condición importante encima de la mesa.
Después miro el master. Proxmox divide HA entre un gestor de cluster y gestores locales por nodo. La documentación oficial lo explica bastante bien. El CRM toma decisiones de cluster y los LRM ejecutan acciones locales sobre los recursos que les tocan. ha-manager status me da una versión digerible de esa jerarquía.
Por eso me interesa ver un master activo y luego las líneas lrm de los nodos que participan. Si veo un nodo en idle, no me pongo nervioso solo por eso. El contexto importa. Puede ser perfectamente normal según dónde estén los recursos gestionados en ese momento. Lo que sí me interesa es que no haya incoherencias raras o una ausencia que no esperaba.
Luego viene la parte de verdad útil. Las líneas service.
Ahí veo qué recursos están bajo HA, dónde viven ahora y en qué estado aparecen para el gestor. Eso ya me cambia mucho el tono de la operación. No es lo mismo tocar un nodo con cero servicios HA relevantes que hacerlo sabiendo que hay recursos arrancados y repartidos entre dos hosts concretos.
cómo leo cada bloque sin contarme películas#
quorum OK me tranquiliza, pero no me relaja#
La primera trampa es pensar que quorum OK equivale a “todo bien”. No. Equivale a que el mecanismo de quorum está bien en ese instante. Es una diferencia importante.
Quorum correcto no te dice si el servicio de dentro va fino. Tampoco te dice si el storage que usa una VM está donde tiene que estar, ni si te interesa forzar una migración ahora mismo. Solo te dice que la capa de cluster no está rota en algo muy básico. Ya es bastante, pero no es toda la historia.
A mí me sirve como puerta de entrada. Si esa línea no sale bien, no sigo con el resto como si nada. Si sale bien, entonces sí paso a la siguiente pregunta.
quién es el master y por qué me importa bastante más de lo que parece#
En HA de Proxmox el master es el nodo que lleva la batuta a nivel de decisiones del cluster. No me obsesiona que sea un host concreto, pero sí quiero saber cuál es en ese momento.
¿Por qué? Porque cuando empiezo mantenimiento me gusta entender desde dónde se está coordinando todo. Si iba a tocar justamente el nodo que aparece como master, no significa que esté prohibido hacerlo. Significa que me conviene ir un poco menos a ciegas.
En homelab solemos tener pocos nodos y bastante confianza en nuestra intuición. A veces demasiada. Cuando el nodo que vas a tocar además hace de master, yo al menos subo un poco el nivel de respeto. No por dramatismo, sino porque ya no estoy moviendo una caja aislada. Estoy tocando una pieza con papel activo dentro de la gestión HA.
qué me dicen las líneas lrm#
Las líneas lrm me ayudan a comprobar que los gestores locales siguen presentes y en un estado coherente. La documentación de Proxmox describe el LRM como el encargado de controlar los servicios en su nodo local. Eso encaja muy bien con cómo leo este bloque.
Si veo dos nodos en activo y otro en idle, no saco conclusiones rápidas por reflejo. Primero miro dónde están realmente los servicios HA. Un LRM idle puede ser completamente normal si en ese host no hay nada que gestionar ahora mismo.
Lo que sí me huele mal es una ausencia inesperada, un patrón raro o un nodo que debería estar participando y no aparece como espero. Ese tipo de señales no siempre significan avería grave, pero sí me bastan para no tratar el momento como rutinario.
Mi regla aquí es muy simple. Si tengo que interpretar demasiado, prefiero no tocar todavía.
las líneas service son la parte que más valor me da#
Aquí es donde realmente me compensa lanzar el comando.
Cada línea service me dice tres cosas que quiero saber antes de tocar mantenimiento.
- qué recurso gestiona HA
- en qué nodo está en ese momento
- si el estado pedido por HA es
startedostopped
Esto es útil por una razón muy humana. Yo no confío en mi memoria para recordar dónde acabó cada servicio después del último movimiento. Confío bastante más en una foto fresca.
En la captura, por ejemplo, se ve enseguida que varios recursos HA están repartidos y que algunos viven fuera del nodo desde el que consulté. Esa sola lectura ya me da una conclusión práctica. Si mi idea era reiniciar este host porque “seguro que hoy lleva poca cosa”, mejor comprobarlo dos veces.
También me ayuda a ver si hay servicios que están stopped por diseño. Eso evita la confusión típica de creer que toda línea parada es un problema. No necesariamente. Puede ser simplemente el estado deseado para ese recurso.
Ahora bien, aquí hay una trampa importante. started en HA no significa que la aplicación de dentro esté feliz. Significa que, para HA, el recurso está arrancado. Son dos conceptos distintos. Si un servicio crítico me importa de verdad, después de esta comprobación yo sigo validando la aplicación o la VM con sus herramientas normales.
el cruce que hago siempre con pvecm status#
ha-manager status me gusta mucho más cuando lo miro al lado de pvecm status. Esta segunda captura también viene de una revisión real y está saneada.
Aquí ya veo la parte más estructural del cluster. Nombre, votos esperados, votos presentes, nodos miembros y quorum. Esta salida me sirve para validar que la lectura optimista de HA no se apoya en un cluster medio cojo.
Si ha-manager status me da una foto razonable y pvecm status confirma quorum limpio con todos los votos esperados, entonces sí empiezo a sentir que el cluster está en una zona cómoda.
Pero no me quedo ahí. En esa misma revisión suelo lanzar también inventario local con qm list y pct list. Lo conté con más detalle en qm list y pct list en Proxmox: el inventario rápido que miro antes de reiniciar un nodo, porque me parece una comprobación infravalorada. HA me dice qué gestiona HA. El inventario local me dice qué corre de verdad en el nodo, con o sin HA.
Las dos miradas juntas son mucho más útiles que cualquiera por separado.
lo que este comando no me resuelve#
Aquí es donde más fácil es equivocarse. ha-manager status no me responde estas preguntas.
- si el storage compartido está fino de verdad
- si la migración que quiero hacer será buena idea ahora mismo
- si la aplicación dentro de la VM responde como debe
- si el nodo destino tiene el margen que yo creo que tiene
Por eso no lo trato como oráculo. Lo trato como una pieza del preflight.
Si voy a actualizar paquetes o reiniciar, además de este comando miro salud del cluster, inventario local, estado del storage implicado y, cuando toca, la tanda de paquetes pendientes. Ese flujo lo conté en Actualizar Proxmox sin ir a ciegas: el preflight real que hago antes de un apt full-upgrade.
Mi obsesión no es lanzar más comandos porque sí. Mi obsesión es no dejarle huecos peligrosos a la imaginación.
las meteduras de pata más normales al leer ha-manager status#
creer que started equivale a servicio sano#
No. Equivale a recurso arrancado bajo la lógica HA. Si quieres comprobar salud real de la app, toca mirar más allá.
ver idle y asumir problema#
A veces no hay ningún problema. A veces solo significa que ese LRM no tiene trabajo activo en ese momento. El contexto manda.
olvidar que HA es asíncrona#
Esto sale también en la documentación oficial. Los cambios no siempre se reflejan al instante porque hay coordinación entre nodos. Si acabas de pedir una acción, dale unos segundos antes de interpretar demasiado.
usarlo como excusa para no revisar inventario local#
Error clásico. HA te enseña recursos HA. Tu nodo puede seguir llevando carga que no está bajo HA y que también te fastidie un reinicio.
cuándo me hace frenar en seco#
Hay varias señales que para mí significan “hoy no me pongo creativo”.
falta de quorum o foto rara en los nodos#
Esto es obvio. Si la capa base ya viene dudosa, no necesito razones extra para posponer cambios.
servicios HA donde no esperaba verlos#
Si varios recursos relevantes han acabado en un nodo que pensaba tocar, cambio el plan. Primero entiendo el reparto real.
diferencias entre la foto HA y la foto local#
Si ha-manager status me cuenta una historia cómoda y qm list o pct list me cuentan otra más incómoda, me quedo con la incómoda. Suele ser la verdadera.
storage o red con pinta dudosa#
HA es menos tranquilizadora cuando sé que el storage compartido o la red de cluster vienen renqueando. Ahí no me interesa probar suerte.
cómo lo uso yo en la práctica#
Mi orden habitual antes de tocar un nodo Proxmox pequeño es este.
ha-manager statuspvecm statusqm listpct list- revisión rápida del storage que me importa
Con eso no tengo toda la verdad del universo, pero sí una foto bastante honesta de si el cluster está en una postura cómoda o en una postura engañosamente cómoda. Y esa diferencia importa mucho.
A veces el mejor resultado de este comando no es que me anime a seguir. Es justo lo contrario. Me da motivos suficientes para no tocar nada todavía. En homelab eso también es una victoria.
mi conclusión#
ha-manager status me parece de los comandos más rentables de Proxmox cuando lo lees con cabeza. No porque te resuelva todo, sino porque te da una pista muy clara de cómo está la capa HA en ese momento, quién coordina, qué gestores locales participan y dónde viven los recursos que HA está manejando.
Yo lo uso como filtro de realidad. Si la salida es limpia, sigo comprobando con más contexto. Si la salida me obliga a interpretar demasiado, paro. Me sale mucho más barato pecar de desconfiado que descubrir a mitad de mantenimiento que la alta disponibilidad estaba menos relajada de lo que parecía.
HA en casa funciona bien cuando la tratas como red de seguridad, no como licencia para improvisar. Y ha-manager status, leído con un poco de mala leche, ayuda bastante a no olvidar eso.
referencias#
- Documentación oficial de High Availability en Proxmox VE
- Cluster Manager en Proxmox VE
- Post relacionado: qm list y pct list en Proxmox: el inventario rápido que miro antes de reiniciar un nodo
- Post relacionado: Actualizar Proxmox sin ir a ciegas: el preflight real que hago antes de un apt full-upgrade
- Post relacionado: Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada