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.
Por eso me gusta tanto este comando. Es seco. Bastante feo. Muy poco dado al teatro. Y precisamente por eso suele ser útil.
Me enseña nombre del cluster, versión de configuración, transporte, proveedor de quorum, número de nodos, votos esperados, votos reales y el dichoso Quorate: Yes o No que separa una mañana normal de una tarde bastante peor.
por qué lo miro antes que otras cosas#
Porque responde a una pregunta fundacional. No si el nodo local va más o menos bien. No si Ceph está contento. No si la CPU va holgada. Responde a si el cluster, como cluster, tiene base para seguir funcionando con cabeza.
La documentación de Proxmox insiste en dos ideas muy razonables. La comunicación de Corosync necesita latencia baja y una red estable. Y para HA fiable, tres nodos siguen siendo la referencia lógica, salvo que metas un QDevice en escenarios pequeños. Todo eso está muy bien sobre el papel. pvecm status es donde yo compruebo si la teoría se está cumpliendo hoy y ahora.
Dicho de forma más de andar por casa. Este comando me baja los humos.
Si me estaba viniendo arriba con un reinicio rápido, una actualización simpática o una prueba de red “que serán dos minutos”, pvecm status me recuerda que el cluster no se gobierna por optimismo.
una salida real que me gusta porque es tranquila, pero no muda#
He preparado esta captura con una salida real de mi cluster, saneada en nombre y miembros para no publicar detalles internos que no aportan nada.
Esta captura me gusta por un motivo muy simple. Es una salida sana. No hay drama. No hay Quorate: No. No faltan votos. Nadie se ha caído del mapa. Y aun así, si la lees con calma, te cuenta bastantes cosas.
- el cluster usa
knet - la autenticación segura está activa
- hay 3 nodos y se esperan 3 votos
- el quorum está en 2
- los 3 votos están presentes
- el nodo local ve a los otros miembros con normalidad
Justo esa es la clase de salida que yo quiero antes de tocar nada importante. Una que no solo sea verde, sino coherente.
qué leo primero en Cluster information#
Empiezo por arriba del todo.
Name#
No tiene mucha ciencia, pero me gusta comprobarlo igual. En laboratorios donde conviven varios clusters o donde has heredado cacharros montados hace tiempo, confirmar el nombre nunca sobra. Hay pocas cosas más ridículas que revisar el cluster correcto a medias y tocar luego el que no era.
Config Version#
Esta línea me interesa bastante más de lo que parece.
La versión de configuración no es una nota de salud por sí sola, pero sí me da una referencia útil de si ha habido cambios recientes en la configuración del cluster. Si estoy viendo comportamientos raros y además la Config Version saltó hace nada, ya tengo una pista para tirar del hilo.
No me obsesiono con el número aislado. Me importa su contexto. Lo normal es que me pase desapercibido. Si de pronto no me cuadra con la historia reciente del cluster, entonces sí levanto una ceja.
Transport: knet#
Aquí suele salir knet en clusters actuales de Proxmox, y me gusta verlo claro porque me recuerda qué capa de transporte está sosteniendo la comunicación entre nodos. No es una línea decorativa. Si luego aparecen problemas de conectividad, avisos en Corosync o síntomas de latencia rara, esta parte de la foto importa.
Además enlaza bien con algo que Proxmox repite, y con razón. La red del cluster no debería ir mezclada a lo loco con tráfico pesado, live migration y storage como si nada. Ya lo conté en Corosync en Proxmox: por qué la red del cluster no puede ir mezclada con todo. pvecm status no te diseña la red, pero sí te recuerda que el cluster vive sobre ella.
Secure auth: on#
No es la línea más sexy del comando, pero verla bien siempre suma. Si estoy mirando la salud básica del cluster, agradezco no encontrarme también una sorpresa de autenticación o de configuración torcida.
la parte que manda, Quorum information#
Aquí es donde me quedo más rato.
Nodes#
Si espero 3 nodos y salen 3, bien. Si espero 3 y no salen 3, la conversación ya cambia aunque todavía no haya mirado nada más.
La gracia de esta línea es que me obliga a contrastar la teoría con la realidad presente. No con lo que yo recuerdo. No con lo que vi ayer. Con lo que el cluster reconoce ahora mismo.
Node ID#
No es una cifra que use a diario para presumir de nada, pero sí me ayuda a ubicar el nodo local dentro de la salida. Cuando comparas varias capturas o revisas varios hosts, saber quién está hablando evita confusiones tontas.
Ring ID#
Esta es de mis favoritas porque mucha gente la ve y pasa de largo.
No es una métrica de salud en plan semáforo. Pero sí es una pista muy útil sobre cambios de membresía o eventos de configuración. Si el Ring ID ha cambiado, algo se ha movido. A veces será completamente normal. Un reinicio controlado, un rejoin, un cambio previsto. Otras veces te ayuda a casar una rareza con un momento concreto del cluster.
Yo no hago drama con el Ring ID. Tampoco lo ignoro.
Quorate: Yes#
Aquí está la frase que manda.
Si sale Yes, respiro un poco mejor. Solo un poco. Porque tener quorum no significa que todo lo demás esté perfecto. Pero sí significa que la base mínima del cluster sigue en pie.
Si sale No, se acabó la discusión amable. Ya no estoy pensando en mantenimiento fino. Estoy pensando en por qué el cluster ha perdido quorum y en no empeorarlo con una decisión impulsiva.
por qué Expected votes me importa casi más que Quorate#
Esto lo aprendí a base de dejar de mirar solo el color general de la situación.
En la captura aparece esto.
Expected votes: 3Highest expected: 3Total votes: 3Quorum: 2Flags: Quorate
La foto es muy buena porque todo encaja. Se esperan 3 votos y hay 3. El quorum está en 2, como toca. El cluster está quorate de forma limpia.
Ahora bien, si yo viera un Quorate: Yes pero con otros números más raros, me frenaría igual. Por ejemplo, si el cluster espera menos votos de los que debería o si vienes de una situación donde se ha rehecho la expectativa de votos tras una incidencia. Ahí la foto cambia.
Por eso no me quedo solo con el Yes. Quiero ver si el quorum se sostiene sobre una situación normal o sobre una excepción que debería entender mejor antes de seguir.
Expected votes me parece una de esas líneas que separan a quien está leyendo el cluster de quien solo está buscando permiso para tocarlo.
pvecm nodes es el complemento perfecto, pero no el sustituto#
Debajo de pvecm status suelo lanzar también pvecm nodes.
La diferencia entre ambos me parece importante.
pvecm nodes me da la lista de miembros y me resulta muy cómodo para confirmar de un vistazo quién sigue dentro. De hecho ya hablé de esa comprobación en pvecm nodes en Proxmox: la comprobación corta que hago para confirmar quién sigue dentro del cluster.
Pero no lo uso como reemplazo de pvecm status.
Porque una lista de miembros no me da el contexto de quorum completo. No me enseña votos esperados, no me enseña el umbral de quorum y no me explica la foto global del cluster con la misma claridad.
Para mí la pareja buena es esta.
pvecm statuspara saber si el cluster se sostienepvecm nodespara ver quién aparece y cómo aparece
Con las dos juntas, la lectura gana bastante.
lo que me hace parar en seco#
Hay varias situaciones en las que este comando, por sí solo, ya me cambia el plan del día.
Quorate: No#
La más obvia.
Si el cluster no tiene quorum, no sigo con el guion original como si nada. Antes de tocar más cosas, necesito entender por qué se ha perdido y qué riesgo hay de empeorarlo.
Total votes por debajo de lo que espero#
Aunque el cluster siga respirando, ver menos votos de los previstos ya me hace revisar. Puede ser un nodo fuera, un problema de red, un enlace raro o una situación temporal. Da igual. La foto ya no es la de un cluster tranquilo.
discrepancia entre Nodes, Expected votes y la historia reciente#
Esta es más sutil, pero me parece muy útil. Si los números no cuentan la historia que yo creía estar viviendo, dejo de fiarme de mi memoria y me fío del comando.
cambios del Ring ID en un momento inoportuno#
Si estoy revisando algo después de un susto o de una ventana de mantenimiento y veo que el Ring ID ha cambiado, no saco conclusiones locas, pero sí lo apunto. A veces te ayuda a encajar el cuándo del problema.
cómo lo cruzo con otras comprobaciones#
Mi rutina corta suele ser esta.
pvecm statuspvecm nodessystemctl status corosyncha-manager statussi ese nodo participa en HA sensible- revisión de storage si el problema apunta hacia ahí
Ese orden me funciona porque empieza por la pregunta más importante. ¿El cluster tiene suelo bajo los pies?
Luego bajo a membresía. Después miro el estado local de Corosync, que ya expliqué en systemctl status corosync en Proxmox: cómo confirmo si el servicio del cluster está bien antes de tocar red o quorum. Y solo después sigo con HA o con storage.
Cuando lo hago al revés, a veces gasto demasiados minutos en detalles secundarios mientras el cluster ya me estaba enseñando la respuesta básica al principio.
lo que pvecm status no me cuenta#
Tampoco le pido más de la cuenta.
pvecm status no me dice si Ceph está sano. No me dice si una migración concreta irá fina. No me cuenta si el nodo local tiene problemas de disco, ni si Corosync viene arrastrando avisos KNET en el journal, ni si una VM va lenta por otra razón completamente distinta.
Pero no le hace falta.
Su trabajo es otro. Darme la verdad corta sobre la estructura del cluster. Quorum, votos, membresía, contexto de la configuración. Esa verdad corta es la que necesito antes de decidir si reinicio con calma o si mejor cierro la terminal y me pongo a investigar en serio.
dónde me ha sido más útil de verdad#
No tanto en las caídas completas. Ahí el problema suele ser tan obvio que todo apunta al cluster desde el minuto uno.
Donde más valor le saco es en situaciones grises. Las que más tiempo roban.
Un nodo parece bien, pero hubo un aviso raro. La web sigue abriendo, pero algo huele a inestable. Quiero tocar red, pero antes necesito saber si el cluster viene cómodo o ya va justo. En esos casos, pvecm status me evita un montón de confianza mal colocada.
Si la salida es limpia como la de esta captura, avanzo con otro cuerpo. Si no lo es, ya sé que el siguiente paso no es improvisar. Es entender el problema antes de regalarle otro.
mi conclusión#
pvecm status me parece uno de los comandos más rentables de Proxmox porque no pierde el tiempo. Te dice si el cluster tiene quorum, cuántos votos espera, cuántos tiene de verdad y bajo qué contexto está funcionando. Eso, antes de tocar nada serio, vale oro.
La salida real de esta captura no es espectacular. Y precisamente por eso me gusta. No enseña fuegos artificiales. Enseña lo que quiero ver antes de reiniciar un nodo o tocar la red del cluster. Números coherentes, quorum limpio y membresía estable.
Si administras Proxmox y no tienes pvecm status en la rutina previa a mantenimiento, yo lo metería ya. No porque vaya a resolver todos los problemas, sino porque te evita empezar por el sitio equivocado.
Y en un cluster, empezar por el sitio equivocado suele ser la forma más rápida de convertir una tarea rutinaria en una historia bastante más pesada.
referencias#
- Documentación oficial de Proxmox VE sobre Cluster Manager
- Manpage de Corosync en Debian
- Post relacionado: pvecm nodes en Proxmox: la comprobación corta que hago para confirmar quién sigue dentro del cluster
- Post relacionado: systemctl status corosync en Proxmox: cómo confirmo si el servicio del cluster está bien antes de tocar red o quorum
- Post relacionado: Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada