Hay días en los que abro pvecm status porque quiero una foto completa del cluster. Y hay días en los que no necesito toda la película. Necesito saber una cosa muy concreta y la necesito ya. Qué nodos siguen dentro del cluster, con qué voto aparecen y desde cuál estoy consultando. Para eso pvecm nodes me parece bastante mejor de lo que mucha gente le concede.
No vende humo. No da métricas elegantes. No pretende ser un panel de salud. Es una comprobación corta, seca y muy útil cuando el objetivo no es admirar el cluster, sino evitar una tontería antes de tocarlo.
Yo lo lanzo mucho antes de mantenimiento, después de levantar un nodo que acaba de volver, cuando sospecho que mi memoria del quorum va un poco alegre y también cuando quiero confirmar rápido si el problema está en la membresía o en otra parte. Me gusta porque no me hace perder tiempo y porque no me deja esconderme detrás de un montón de texto.
A veces eso es exactamente lo que hace falta.
por qué me gusta tanto un comando tan pequeño#
Porque la membresía del cluster es la base de un montón de decisiones posteriores.
Si no tengo claro qué nodos están realmente presentes, qué votos aparecen y cuál es el nodo local, cualquier decisión que tome después arranca torcida. Da igual que vaya a reiniciar un host, revisar HA, tocar red de cluster o simplemente comprobar si una caída ya quedó atrás. Si el reparto real de miembros no es el que yo tenía en la cabeza, ya voy tarde.
En homelab esto pasa más de lo que parece. El cluster lleva semanas fino, te acostumbras a cierta normalidad, y un día tocas algo rápido pensando que los tres nodos siguen tan tranquilos como siempre. Igual sí. Igual no. pvecm nodes me sirve para no operar con ese “igual”.
una salida real que resume lo que busco#
Esta captura sale de una comprobación real en uno de mis nodos Proxmox. Está saneada en nombres internos, pero refleja bastante bien por qué sigo usando este comando aunque ya conozca otros más completos.
La salida apenas ocupa unas líneas y aun así me responde tres preguntas muy útiles.
- qué miembros ve ahora mismo el cluster
- qué voto tiene cada uno
- cuál es el nodo local desde el que estoy leyendo
Eso parece poca cosa hasta que dejas de tenerla clara.
Cuando veo los tres nodos con un voto cada uno y uno marcado como (local), ya sé que la membresía básica del cluster se parece a la que espero. No he demostrado que todo esté perfecto. No he validado el storage. No he revisado HA. Pero sí he resuelto una duda fundamental antes de seguir.
Y a veces esa duda es la que separa un mantenimiento razonable de una chapuza con confianza.
qué leo exactamente en pvecm nodes#
Nodeid#
No es la parte más glamurosa, pero sí me importa.
El Nodeid es el identificador interno del miembro dentro de Corosync. Yo no vivo pendiente de esos números, pero me gusta verlos estables y coherentes. Cuando estás acostumbrado a un cluster concreto, acabas reconociendo rápido qué IDs corresponden a qué nodos. Eso ayuda bastante cuando comparas salidas, revisas logs o intentas entender por qué algo no cuadra con lo que esperabas.
No hace falta aprendérselos de memoria como si fuera una oposición. Basta con respetar que existen y que no son adorno.
Votes#
Esta columna me interesa mucho más de lo que parece.
En un cluster casero de tres nodos, ver 1 en cada miembro es justo lo que quiero cuando la configuración está simple y limpia. Si aquí ya aparece algo extraño, no necesito mucha más poesía. El reparto de quorum merece atención antes de seguir con cualquier operación medianamente sensible.
La palabra clave aquí es “antes”. No después.
Name#
Aquí es donde la salida se vuelve especialmente práctica. Ver el nombre del nodo y la marca (local) me evita un error bastante humano. Creer que estoy mirando desde el host que creo cuando llevo demasiadas pestañas, varias sesiones SSH abiertas y cero ganas de revisar el prompt con atención.
Parece una tontería hasta que haces una acción sobre el nodo incorrecto. Yo prefiero reírme de este riesgo en el artículo que sufrirlo de verdad a las dos de la mañana.
por qué no me basta con pvecm status#
pvecm status me gusta mucho. De hecho lo uso constantemente. Pero cumple otro papel.
Cuando quiero ver quorum, transport, votos esperados, ring ID y una foto más completa de Corosync, tiro de pvecm status. Ya conté parte de ese flujo en Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada.
pvecm nodes, en cambio, lo uso cuando quiero resolver una duda puntual de membresía sin meterme en toda la salida larga.
Dicho de forma menos elegante, que a veces es mejor. pvecm status es el informe. pvecm nodes es la mirada rápida que hago antes de tocar la puerta.
No compiten. Se complementan.
en qué momentos me resulta más útil#
antes de reiniciar un nodo#
Si voy a reiniciar un host, quiero confirmar quién está dentro del cluster y desde cuál estoy hablando. No porque pvecm nodes me diga si el reinicio es buena idea, sino porque me evita arrancar la decisión sobre una premisa falsa.
después de que un nodo vuelva#
Este es un caso muy práctico. El host ya está arriba, la interfaz web puede incluso cargar, pero yo quiero una confirmación rápida de que la membresía del cluster lo ha recuperado como toca. pvecm nodes me da esa respuesta sin rodeos.
cuando algo no cuadra con mi memoria#
En homelab acumulamos mucho contexto y a veces demasiado folclore técnico. “Este nodo suele ser el local”, “aquí normalmente veo esto”, “creo que el ID era tal”. Cuando me escucho hablar así en mi cabeza, lanzo el comando y listo.
cuando sospecho de quorum, pero todavía no sé si el problema va por ahí#
Antes de entrar en una revisión más larga, me gusta ver si la membresía básica ya enseña algo raro. Si no lo hace, perfecto. Si lo hace, ya sé por dónde empezar.
lo que este comando no me resuelve#
Y esto conviene decirlo claro porque, si no, acabamos usando herramientas pequeñas como si fueran oráculos.
pvecm nodes no me dice esto.
- si el cluster está quorate en ese instante con todo el detalle de
pvecm status - si HA está cómoda o tensa
- si el storage compartido responde bien
- si la red del cluster viene limpia de latencias o cortes
- si las VMs relevantes están repartidas donde toca
O sea, no es un chequeo total. Es una comprobación concreta.
A mí me gusta precisamente por eso. Hace una sola cosa y la hace rápido. El error es pedirle más.
el matiz de los votos importa bastante más de lo que parece#
He visto a mucha gente mirar la columna Votes como si fuera una formalidad. Para mí no lo es. En clusters pequeños cualquier rareza aquí cambia el tono de la operación.
Si tienes tres nodos y esperas un voto por cada uno, eso es lo que quieres ver. Si no lo ves, no hace falta que dramatices, pero sí que pares un segundo. Puede ser un cambio previsto, una configuración especial o simplemente un contexto que no recordabas bien. Lo que no haría es seguir como si nada.
Con quorum y votos tengo una postura bastante simple. Si hay que improvisar la explicación, mala señal.
cómo lo cruzo con otros comandos sin perder tiempo#
Mi secuencia rápida suele ser esta.
pvecm nodespvecm statusha-manager statussi el nodo o los servicios lo justificanqm listypct listsi voy a tocar reinicio o mantenimiento
El orden no es casual.
Primero quiero saber si la membresía básica me sonríe o me frunce el ceño. Luego voy al detalle de quorum y transporte. Después miro HA, y solo después me meto en la carga concreta del nodo. Esto me evita dispersarme demasiado pronto.
Cuando hago el proceso al revés, corro el riesgo de perderme en detalles de VMs o de storage mientras la pregunta básica sobre el cluster todavía no está resuelta.
una trampa bastante humana, el (local)#
La marca (local) parece una tontería hasta que te salva de una estupidez.
Yo trabajo mucho con varias sesiones abiertas a la vez. Terminales, pestañas, SSHs saltando entre nodos, notas de mantenimiento, comparaciones entre hosts. En ese escenario es demasiado fácil asumir que estás donde crees estar. pvecm nodes te lo recuerda en una sola línea.
Por eso no desprecio esa etiqueta. Me parece de esas pequeñas ayudas que evitan errores caros y vergonzosos a partes iguales.
Y sí, todos preferimos decir que eso no nos pasaría. Ya. Claro.
cuándo me hace frenar#
si falta un miembro que esperaba ver#
Esto es el caso más obvio. Si el cluster no ve a un nodo que yo daba por presente, la conversación ya ha cambiado. No sigo con mantenimiento alegre.
si los votos no son los que esperaba#
No tengo problema en revisar por qué, pero desde luego no lo ignoro.
si la membresía me dice una cosa y mi sensación general me dice otra#
Cuando el comando contradice mi narrativa interna, casi siempre gana el comando. Me ha demostrado ser bastante menos fantasioso que yo.
si estoy tan cansado que necesito releer tres veces la salida#
Esto también cuenta. En homelab el cansancio técnico existe y se nota. Si tengo que interpretar demasiado un comando tan corto, igual el problema no es el cluster. Igual soy yo y toca bajar revoluciones.
relación directa con Corosync, sin ponerse místico#
pvecm nodes me gusta porque aterriza algo que a veces tratamos como magia. El cluster no es una nube abstracta. Son nodos concretos con una membresía concreta y unos votos concretos. Corosync no “siente” el cluster. Lo compone a partir de eso.
Por eso este comando encaja tan bien con lo que conté en Corosync en Proxmox: por qué la red del cluster no puede ir mezclada con todo. Si la base de red del cluster se complica, la membresía es una de las primeras cosas que deja de parecer estable. A veces no necesitas empezar por un análisis profundo. Necesitas ver si los miembros siguen siendo los que deberían.
Ahí pvecm nodes entra de maravilla.
el error clásico, usarlo como certificado de buena salud#
No lo es.
Que los miembros aparezcan como esperas no significa que todo el cluster esté sano. Significa solo eso, que la membresía básica encaja con tu expectativa en ese momento. Nada más y nada menos.
Yo no tomaría una salida limpia de pvecm nodes como permiso para actualizar, reiniciar o hacer bricolaje de red sin mirar nada más. Lo tomo como el primer sí condicional. El que me permite seguir comprobando con una base razonable.
Esto puede sonar poco romántico, pero es que el romanticismo y el quorum no suelen llevarse bien.
dónde me ha resultado más rentable de verdad#
Curiosamente, no en las averías grandes. Me ha sido más rentable en los momentos grises. Esos en los que no sabes si hay un problema real o solo una sensación incómoda. El cluster responde, la web abre, las VMs siguen ahí, pero tú quieres una confirmación muy rápida de que la membresía no se ha torcido mientras estabas mirando otra cosa.
En esos momentos pvecm nodes me da una respuesta inmediata y me permite decidir si sigo bajando al detalle o si la base de miembros ya está bien y el problema va por otro lado.
Eso ahorra tiempo, pero sobre todo ahorra ruido mental. Y el ruido mental es uno de los recursos que más se comen los homelabs cuando crecen.
mi conclusión#
pvecm nodes no es el comando más completo de Proxmox, ni falta que le hace. A mí me gusta porque resuelve una duda muy concreta en muy poco tiempo. Qué miembros ve el cluster, qué voto tienen y cuál es el nodo local desde el que estoy mirando.
Antes de tocar nada delicado, esa comprobación me parece baratísima y muy rentable. Si la salida cuadra, sigo con pvecm status, HA, inventario local y el resto del preflight. Si la salida ya me chirría, no necesito más excusas para parar y entender qué ha cambiado.
En un homelab maduro, donde los problemas serios suelen empezar con detalles pequeños, este tipo de comando vale oro. No porque resuelva todo, sino porque te obliga a no dar por obvia la pieza más básica del cluster.
Y en Proxmox, dar cosas por obvias suele salir peor de lo que promete.
referencias#
- Documentación oficial de Cluster Manager en Proxmox VE
- Cluster Manager en la wiki oficial de Proxmox
- Post relacionado: Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada
- Post relacionado: Corosync en Proxmox: por qué la red del cluster no puede ir mezclada con todo
- Post relacionado: ha-manager status en Proxmox: cómo leo la alta disponibilidad antes de tocar un nodo