Fallo de quórum en Proxmox con 2 de 3 nodos: causas

Un clúster de Proxmox de tres nodos con un voto por nodo debería sobrevivir habitualmente a la pérdida de un nodo, ya que dos votos de tres representan una mayoría. Si los dos nodos restantes pierden el quórum de todos modos, deja de contar servidores físicos y comprueba cuántos votantes cree tener Corosync.

Eso fue lo que aclaró un incidente confuso en agosto de 2026. El clúster tenía tres nodos físicos y, sin embargo, apagar uno provocó la desaparición del quórum. La causa resultó ser un QDevice inesperado que seguía activo en la configuración de votación. Corosync esperaba cuatro votos, por lo que dos nodos supervivientes no bastaban. El número de servidores en un clúster y el número de votantes pueden no coincidir.

¿Deben dos nodos mantener el quórum en un clúster Proxmox de tres nodos?

Sí. En un clúster normal de Proxmox VE de tres nodos donde cada nodo tiene un voto, dos nodos supervivientes mantienen el quórum porque dos es más de la mitad de tres.

La mayoría de los administradores parte de ese modelo mental, y en este caso la expectativa del administrador era correcta. Había tres nodos físicos a la vista, cada uno aparentemente con un voto, de modo que un nodo debería haber podido apagarse sin arrastrar consigo el quórum. La topología visible simplemente no mostraba todo el escenario.

El quórum contabiliza votos, no chasis de servidores en una estantería. Corosync registra el número esperado de votos y calcula el umbral de quórum a partir de esa configuración. Si existe otro participante con derecho a voto, incluso uno del que el administrador se haya olvidado por completo, la aritmética cambia. Así es como un clúster que aparenta tener tres nodos termina comportándose como si contara con cuatro votantes.

Si todavía te estás familiarizando con la arquitectura base, los recursos de Proxmox de Mr.PlanB explican cómo se integran la gestión de clústeres, el almacenamiento y los hosts, lo cual resulta útil antes de empezar a diagnosticar comportamientos más sutiles de alta disponibilidad (HA).

¿Qué reveló pvecm status?

La vista gráfica del clúster no mostraba el problema, pero pvecm status sí lo hizo. Con los tres nodos físicos encendidos, la salida indicaba:

• Nodes: 3
• Expected votes: 4
• Highest expected: 4
• Total votes: 3
• Quorum: 3

La sección de miembros enumeraba los tres nodos normales más una entrada para el QDevice. Eso evidenció la contradicción de inmediato: tres servidores físicos, mientras el sistema de quórum seguía calculando los umbrales sobre cuatro votos esperados.

El QDevice figuraba como no registrado, pero continuaba formando parte de la configuración esperada de votación, y eso basta para provocar un modo de fallo desagradable. Con los tres servidores en marcha, el clúster sumaba tres votos y cumplía el requisito de quórum de tres, por lo que todo parecía correcto. Al apagar un nodo físico, solo quedan dos votos de servidores frente a un umbral que sigue fijado en tres. El clúster pierde el quórum.

Por eso, cuando el comportamiento del clúster no encaja con la topología que crees haber montado, pvecm status debe ser uno de los primeros comandos que ejecutes. La interfaz gráfica te dice qué nodos están presentes, y la salida de votos muestra lo que cree el sistema de consenso.

¿Cómo puede un QDevice antiguo romper un clúster de tres nodos?

Un QDevice añade un voto externo para las decisiones de quórum. Se utiliza sobre todo cuando un número par de nodos en el clúster podría derivar en un empate. Configurado a propósito, resulta muy útil. Se vuelve confuso cuando cambia la topología del clúster y la configuración de votación no se actualiza a la par.

Proxmox documenta el soporte de QDevice como parte de la gestión de quórum de Corosync. En sus ejemplos se muestra un QDevice listado en pvecm status junto a los nodos del clúster, y la documentación explica que el QDevice puede emitir un voto durante situaciones de partición de red. La misma documentación advierte sobre los cambios de topología: si añades o quitas nodos en un clúster que utiliza un QDevice, elimina primero el QDevice y vuelve a configurarlo después si la nueva topología aún lo necesita. Este incidente es lo que ocurre cuando se omite ese paso.

El administrador comentó que el entorno había sido un clúster de dos nodos durante varios años antes de convertirse en uno de tres nodos. No recordaba haber configurado ese QDevice misterioso, por lo que en el hilo nunca se aclaró cuándo ni por qué se había añadido. Lo que importaba era que el registro de votantes todavía lo incluía.

El estado antiguo de un clúster puede sobrevivir a la memoria de cualquiera. Esto es especialmente habitual en un homelab, donde se cambia hardware, se renombran nodos, los experimentos pasan a ser infraestructura permanente y una configuración de hace años puede seguir activa mucho después de que su motivo haya desaparecido.

¿Por qué funcionó el clúster hasta que un nodo se desconectó?

La configuración obsoleta era errónea, pero no rompió nada de inmediato. Con tres servidores encendidos, el sistema registraba tres votos totales y requería tres para el quórum. Cumplía el umbral con exactitud, de modo que el clúster conservaba el quórum. Nada en el funcionamiento diario alertó al administrador de que el recuento de votos esperados era una unidad mayor que el número de nodos físicos. El problema solo se hizo visible durante una prueba de fallos.

Los despliegues de alta disponibilidad fallan con frecuencia de este modo. Una configuración puede parecer correcta mientras todos los componentes estén levantados, y el fallo solo sale a la luz cuando algo cae y el sistema se ve forzado a utilizar la redundancia que creías tener. En este caso, el diseño de tres nodos estaba pensado para tolerar la pérdida de un nodo, y ese cuarto voto esperado obsoleto eliminó esa tolerancia sin aviso. Sobre el papel el clúster seguía pareciendo redundante, pero el cálculo matemático de los votos decía lo contrario.

Por esa razón merece la pena realizar pruebas planificadas de fallos. Apaga un nodo mientras todo lo demás funcione con normalidad y observa qué ocurre. Comprueba que los nodos restantes conserven el quórum, que las acciones de HA respondan como se espera y que el almacenamiento y la red sigan estables. Hasta que no pruebas un diseño de redundancia, parte de él no es más que una suposición.

¿Cómo se eliminó el QDevice obsoleto?

El comando de limpieza recomendado era pvecm qdevice remove, y no terminó limpiamente. Indicó que corosync-qdevice.service no estaba cargado y devolvió un error al intentar detener el servicio en un nodo. Aun así, el administrador vio que Expected votes bajó de 4 a 3, lo que confirmó que la corrección había surtido efecto.

Al esperar el clúster tres votos, el umbral de quórum pasó a ser dos. Otro participante señaló que, con los votos esperados en tres, dos nodos supervivientes deberían bastar. El administrador confirmó a continuación que el problema estaba resuelto y actualizó la publicación original indicando el QDevice desconocido como la causa. La guía de administración actual de Proxmox documenta el mismo comando de eliminación para un QDevice configurado mediante pvecm.

El fallo al detener el servicio recuerda oportunamente que no se debe juzgar un comando de mantenimiento únicamente por su código de salida. Tras cualquier cambio en la pertenencia al clúster o en el quórum, ejecuta pvecm status de nuevo y comprueba el estado que de verdad importa: si Expected votes cambió, si el QDevice no deseado desapareció y si el clúster conserva el quórum. Si las respuestas son correctas, el cambio funcionó.

¿Por qué el quórum de Proxmox da tanta importancia a las mayorías?

El quórum evita que partes desconectadas de un clúster decidan que cada una es el bando con autoridad al mismo tiempo. Un servidor averiado es el fallo evidente. Una partición de red es el caso más complejo. Dos máquinas pueden seguir encendidas y perder el contacto entre sí, y desde la perspectiva de cualquiera de los dos nodos puede ser imposible saber si el otro host murió o si solo falló el enlace de red entre ambos. Si ambos lados continúan ejecutando los mismos recursos por su cuenta, pueden generarse instancias en conflicto y estados divergentes, lo que resulta mucho más grave que una caída temporal. Por eso el consenso de clúster es deliberadamente prudente. Una partición debe reunir suficientes votos para demostrar que es el bando con autoridad antes de continuar con la operativa normal del clúster.

El hilo de la comunidad sobre este incidente se enredó porque varios participantes se centraron en la regla general de que los clústeres con un número par de nodos pueden sufrir problemas de empates. Esa regla es real, pero aquí no era la causa. Dos nodos representan la mayoría en un clúster de tres votos bien configurado, y el cuarto voto esperado imprevisto fue lo que alteró el resultado. Cuando diagnostiques problemas de quórum, haz el cálculo aritmético exacto en lugar de apoyarte en reglas orientativas.

¿Qué debes comprobar antes de confiar en un clúster de Proxmox?

Ver el nombre de cada nodo en la interfaz del clúster no es suficiente. Comprueba el estado de votación mientras todo esté funcionando bien.

Ejecuta pvecm status y revisa atentamente cuatro elementos:

• Expected votes
• Total votes
• Quorum
• Membership information

Para un clúster básico de tres nodos con un voto por nodo y sin QDevice, esos números deben cuadrar de forma evidente. Si tienes tres nodos y cuatro votos esperados, localiza al cuarto votante antes de dar por hecho que vas a sobrevivir a la pérdida de un nodo.

Repite la comprobación tras cualquier modificación de topología. Añadir o quitar un nodo, retirar un nodo testigo antiguo, reconstruir un host o transformar un clúster de dos nodos en uno de tres puede invalidar las premisas sobre las que descansaba tu diseño inicial de quórum.

Si mereció la pena montar alta disponibilidad, merece la pena probarla. El Proxmox Health Check de Mr.PlanB puede integrarse en la rutina de comprobación del estado del clúster antes de que una caída te obligue a hacerlo.

La cifra en la que confiar es Expected votes

Lo que me llamó la atención de este incidente es que la interpretación del administrador sobre un clúster de tres nodos era básicamente acertada. Un nodo debería haber podido fallar sin consecuencias críticas. El error consistió en asumir que tres nodos equivalían a tres votantes, cuando Corosync estaba esperando cuatro.

Esa única cifra explica todo el fallo. Con cuatro votos esperados, el quórum era tres, y con un servidor apagado solo quedaban dos votos. Eliminar el QDevice obsoleto devolvió los votos esperados a tres y restableció la tolerancia a la pérdida de un nodo.

Cuando un clúster de Proxmox no se comporte como marca el esquema que tienes en la cabeza, comprueba la tabla de votos antes de rediseñar nada. El problema puede estar en la configuración mientras el hardware funciona perfectamente.