Cuando operas un clúster en Proxmox VE, un apagón repentino o una partición en la red puede derribar múltiples nodos simultáneamente. Cuando un solo nodo sobreviviente vuelve a encenderse, típicamente se rehusará a iniciar sus Máquinas Virtuales, quedando congelado en las tareas con el mensaje “bulk start waiting for quorum” (Inicio masivo esperando quórum).
Proxmox hace esto intencionalmente: para prevenir escenarios catastróficos de “split-brain” (cerebro dividido), donde dos nodos aislados intentan ejecutar las mismas VMs al mismo tiempo y corrompen el almacenamiento compartido. El clúster exige un Quórum (una mayoría estricta de nodos activos). Si un nodo no puede comunicarse con la mayoría del clúster, se bloquea por seguridad.
Pero, ¿qué sucede si necesitas iniciar urgentemente una VM crítica, como tu Firewall pfSense, servidor DNS o el Controlador de Dominio/DHCP en Windows Server, antes de que el resto del clúster pueda ser reparado? Esta guía proporciona múltiples soluciones para esquivar el quórum de forma segura.
Solución 1: Forzar Temporalmente el Quórum (Un solo Nodo)
Si únicamente necesitas que un nodo sobreviviente funcione temporalmente mientras el resto del clúster está caído o apagado, puedes reducir manualmente la expectativa de votos de Corosync a solo uno:
pvecm expected 1
Pros: Esto engaña inmediatamente al nodo haciéndole creer que posee el quórum completo. Proxmox reanudará de inmediato sus operaciones normales y arrancará cualquier VM que tenga activada la opción “Start at boot”. Contras: Este comando es temporal y se reinicia (se borra) al reiniciar el sistema. Además, si los otros nodos sí se encienden eventualmente y no has arreglado la comunicación en la red, te arriesgas terriblemente a una corrupción por split-brain si ambos intentan correr las mismas VMs a la vez.
Solución 2: Script de Inicio de Evasión (Solo para VMs Críticas)
Si vives en un área con apagones frecuentes y sin UPS, es posible que desees que tu nodo siempre encienda la VM del Firewall o DHCP al instante tras el arranque eléctrico, eludiendo por completo la verificación del clúster Corosync.
Podemos lograr esto creando un servicio systemd de tipo “oneshot” que detenga el servicio del clúster, arranque la VM en modo de archivo local, y luego reanude las operaciones normales del clúster.
ADVERTENCIA - Lee con cuidado: Si implementas este script, solamente las VMs listadas dentro del código del script se encenderán automáticamente durante la pérdida de quórum. Cualquier otra VM en el nodo que dependa de la casilla estándar “Start at boot” (Arrancar al inicio) en la interfaz web de Proxmox no iniciará automáticamente si el clúster carece de quórum. A mí me ha pasado; esto se debe a que el administrador del clúster en segundo plano técnicamente seguirá esperando eternamente el quórum para procesar la cola general de arranque masivo.
Paso 1: Crea el script de inicio (ej., /root/start_vms.sh).
nano /root/start_vms.sh
Pega el siguiente código, reemplazando <VM-ID> con el ID numérico de tu VM crítica (por ejemplo, 100):
#!/bin/bash
systemctl stop pve-cluster # Detiene el servicio del clúster
pmxcfs -l # Activa el modo local del sistema de archivos (ignora el quorum)
qm start <VM-ID> # Reemplaza <VM-ID> con el ID de tu VM crítica (ej: qm start 100)
sleep 5
killall pmxcfs # Finaliza el modo local
systemctl start pve-cluster # Reinicia el servicio del clúster
Otorga permisos de ejecución al script:
chmod +x /root/start_vms.sh
Paso 2: Crea el servicio generador en systemd.
nano /etc/systemd/system/start_vms.service
Pega la siguiente configuración:
[Unit]
Description=Iniciar VMs críticas sin quórum
After=network.target
[Service]
Type=oneshot
ExecStart=/root/start_vms.sh
[Install]
WantedBy=multi-user.target
Paso 3: Recarga el demonio systemd y habilita tu nuevo servicio.
systemctl daemon-reload
systemctl enable start_vms.service
Este servicio arrancará limpiamente la máquina virtual especificada antes de que la rutina principal del clúster intente sincronizarse, garantizando que tu infraestructura de red (como pfSense) levante primero.
Solución 3: Deshabilitar la Alta Disponibilidad (HA)
Si utilizas el Administrador de HA de Proxmox, el clúster requerirá de forma inquebrantable el quórum para manejar la vida de las VMs. Si una VM está marcada y gobernada por HA, Proxmox se negará rotundamente a iniciarla sin un consenso.
Puedes retirar una VM del grupo de HA desde la interfaz gráfica (Datacenter > HA) o mediante la línea de comandos:
ha-manager remove vm:<VM-ID>
Esto elimina la dependencia tan estricta que ata la VM al clúster, permitiéndole a las herramientas de arranque local (como el script anterior) funcionar libremente.
Solución 4: Arreglar una Configuración de Nodo “Fantasma” (Hardware muerto)
Si tu clúster está permanentemente degradado (por ejemplo, retiraste un nodo físicamente para siempre o se quemó, pero aún aparece desconectado en la interfaz bloqueando el quórum), necesitas eliminarlo de la configuración de Corosync.
- Detén los servicios vitales del clúster:
systemctl stop pve-cluster corosync - Inicia el sistema de archivos en modo puramente local:
pmxcfs -l - Edita el archivo de red
/etc/pve/corosync.confy elimina allí todo el bloque descriptivo del nodo fantasma o muerto. - Detén el modo local y reinicia el clúster, este volverá a calcular la fórmula del quórum basándose en los nodos sobrevivientes:
killall pmxcfs systemctl start pve-cluster
Conclusión
El estricto bloqueo de “Esperando Quórum” es fundamentalmente un enorme mecanismo de seguridad diseñado para salvar tu estructura de almacenamiento de una destrucción y sobrescritura total en entornos empresariales. Sin embargo, para los laboratorios en casa (Homelabs) o sitios remotos con redes eléctricas muy inestables, esta protección de hierro te puede dejar totalmente aislado e imposibilitado si tu servidor de firewall principal o DHCP vive precisamente virtualizado dentro de ese mismo clúster caído.
Al aplicar ya sea el atajo engañoso temporal pvecm expected 1, o al implementar el permanente script oneshot de puenteo por systemd (tomando en cuenta sus salvedades de aislamiento en lote), puedes tener la absoluta confianza de asegurar que tu infraestructura crítica arranque sola, de pie, sin importar el deficiente estado en el que se encuentren los nodos vecinos en tu Proxmox.