Proxmox «No se puede eliminar el nodo»: Eliminación segura de un nodo del clúster

Modelo mental: qué significa realmente «eliminar nodo»

En Proxmox VE, “eliminar un nodo” no es una sola cosa. Son al menos cuatro acciones que comparten la misma etiqueta:
membresía del clúster, el estado del sistema de ficheros del clúster, expectativas a nivel de servicio (gestor HA, programación, plugins de almacenamiento),
y las cargas de trabajo que estaban ancladas a ese nodo (VMs, contenedores, demonios de almacenamiento).

El núcleo es la membresía de Corosync más la base de datos de configuración del clúster de Proxmox (pmxcfs) distribuida bajo
/etc/pve. Cuando ejecutas pvecm delnode, le estás diciendo al clúster restante:
“Dejad de esperar que este nodo participe en las decisiones de quorum y eliminad su presencia de la configuración compartida.”
Si no tienes quorum, o los nodos restantes discrepan sobre el estado compartido, no obtienes una eliminación limpia—porque
los clústeres son alérgicos a ediciones unilaterales. Con buenas razones.

Así que la regla es simple pero molesta: los cambios de membresía requieren un clúster saludable.
Cuando el clúster no está saludable, dejas de intentar ser ingenioso y comienzas a hacer cirugía controlada:
estabiliza el quorum, congela los cambios y luego elimina el nodo. Si no estabilizas primero, puedes provocar un split brain
que parece estar bien en la interfaz hasta que deja de estarlo. Y “hasta que deja de estarlo” suele ocurrir durante el reinicio de un host.

También hay diferencia entre “nodo está offline” y “nodo ha desaparecido”. Offline significa que podría volver con configuraciones antiguas.
Desaparecido significa que debes asumir que nunca regresará y debes evitar que vuelva inesperadamente. Por eso la eliminación segura
incluye: apagarlo, borrar las configuraciones del clúster en él o al menos mantenerlo fuera de la red.

Guía de diagnóstico rápido

Cuando aparece “no se puede eliminar el nodo”, el sumidero de tiempo no es teclear comandos. Es adivinar qué subsistema te está bloqueando.
Este es el camino rápido hacia el cuello de botella.

1) Quorum y membresía primero (siempre)

• Comprueba pvecm status. Si no tienes quorum, no vas a eliminar nada limpiamente.
• Revisa journalctl -u corosync en busca de cambios de membresía, timeouts de token o “not in quorum”.
• Verifica si el nodo que quieres eliminar todavía aparece en “Expected votes” del clúster.

2) Sistema de ficheros del clúster (pmxcfs) segundo

• Confirma que pve-cluster está saludable en los nodos restantes.
• Comprueba si /etc/pve responde; montajes FUSE colgados hacen que cada comando de gestión parezca poseído.
• Busca archivos de bloqueo obsoletos (raro) o un nodo atascado con versiones de config desactualizadas.

3) Cargas de trabajo y HA tercero

• Si HA está activado, confirma que el nodo no esté todavía referenciado por grupos o recursos de HA.
• Confirma que ninguna configuración VM/CT todavía referencia el almacenamiento local del nodo como ubicación primaria.
• Si tienes Ceph, asegúrate de no confundir “eliminar nodo de Proxmox” con “eliminar host de Ceph”. Están relacionados, no son idénticos.

4) Entonces realiza la eliminación

• Ejecuta pvecm delnode desde un nodo restante saludable.
• Valida que corosync.conf y la lista de nodos se hayan replicado en /etc/pve.
• Sólo después de eso, limpia el nodo eliminado para que no pueda volver a unirse accidentalmente.

Hechos y contexto interesante (por qué Proxmox se comporta así)

• Corosync viene del mundo Linux HA, diseñado para coordinar la membresía en clústeres donde la corrección prima sobre la conveniencia.
• El quorum es una característica de seguridad, no de rendimiento: evita “dos clústeres en uno” (split brain) que ambos hagan cambios.
• Proxmox almacena la configuración del clúster en un sistema de ficheros distribuido (pmxcfs) montado en /etc/pve, por eso las ediciones ahí afectan a cada nodo.
• Históricamente, los incidentes de split brain moldearon las herramientas de clúster: muchos comportamientos estrictos son cicatrices de pilas HA antiguas donde el “mejor esfuerzo” corrompía el estado.
• Los clústeres de dos nodos son inherentemente incómodos porque la mayoría es frágil; normalmente necesitas un desempate (qdevice) o aceptar riesgo de downtime.
• Los votos importan: el quorum de Corosync se basa en votos; “expected votes” que incluyen nodos muertos pueden dejar un clúster sin quorum.
• El gestor HA de Proxmox es contundente: preferirá vallar o detener cargas antes que permitir un estado incierto, lo cual es molesto hasta que te salva.
• La membresía de Ceph es independiente de la de Proxmox: eliminar un nodo de Proxmox no elimina automáticamente OSDs/monitores de Ceph, y mezclar esos pasos a ciegas es receta clásica para una caída.
• Los cambios de clúster se serializan mediante quorum: si no consigues consenso, Proxmox prefiere rechazar la operación antes que adivinar.

Antes de tocar nada: medidas de seguridad

Define el tipo de eliminación: planificada vs no planificada

Eliminación planificada: el nodo es accesible, puedes migrar cargas, puedes detener servicios de clúster de forma ordenada.
Eliminación no planificada: el nodo está muerto, el disco está frito o está en bucle de reinicio y ya no hay negociación posible.
Los pasos se solapan, pero las decisiones difieren: la eliminación planificada optimiza la migración limpia; la no planificada optimiza restaurar quorum
y evitar que el cadáver vuelva a unirse a la conversación.

Asegúrate de no estar a punto de borrar tu única copia de nada

El almacenamiento local es la trampa. Si usaste ZFS local, LVM-Thin o almacenamiento por directorio y nunca replicaste, entonces “eliminar nodo”
puede ser sinónimo de “borrar el único sitio donde existían esos discos”. La membresía del clúster es fácil. Los datos son difíciles.

Reglas operativas (anótalas en una nota adhesiva)

• Una sola persona conduce. Todos los demás observan. Los cambios de membresía no son un ejercicio de mecanografía grupal.
• Congela otros cambios: sin actualizaciones, sin reconfiguración de red, sin movimientos de almacenamiento mientras haces esto.
• Mantén el nodo eliminado apagado (o aislado) hasta que lo hayas limpiado. “Uy, volvió” no es un género divertido de incidente.
• Conoce el tamaño de tu clúster: los modos de fallo en clústeres de 2 y 3 nodos son distintos.

Una cita que la gente de operaciones aprende por las malas:
“La esperanza no es una estrategia.” — Gen. Gordon R. Sullivan

Chiste #1: Un clúster es como un grupo de chat—eliminar a alguien es fácil hasta que te das cuenta que era la única persona que conocía la contraseña.

Tareas prácticas (comandos, salidas, decisiones)

Estas son las comprobaciones y acciones que realmente mueven la pelota. Cada tarea incluye un comando ejecutable, qué significa su salida
y qué decisión tomar en función de ella. Los comandos asumen que eres root o usas sudo; el prompt abajo es un marcador.

Task 1 — Confirmar quorum del clúster y votos esperados

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-pve
Config Version:   27
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 13:10:43 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2f
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Significado: “Quorate: Yes” significa que los cambios de clúster están permitidos. “Expected votes” debería coincidir con el número de nodos que pretendes tener.
Decisión: Si no hay quorum, para aquí y arregla el quorum (ver Tareas 2–4). Si hay quorum, procede con los pasos de eliminación planificada.

Task 2 — Listar nodos conocidos por el clúster

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 pve01
0x00000002          1 pve02
0x00000003          1 pve03

Significado: Esta es la membresía del clúster tal como la ve Corosync.
Decisión: Si el nodo muerto todavía aparece y quieres que desaparezca, lo eliminarás con pvecm delnode <name> desde un nodo saludable.

Task 3 — Comprobar salud del servicio Corosync en los nodos restantes

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-12-26 10:02:11 UTC; 3h 8min ago
       Docs: man:corosync
   Main PID: 1320 (corosync)
      Tasks: 11
     Memory: 38.4M
        CPU: 2.112s
     CGroup: /system.slice/corosync.service
             └─1320 /usr/sbin/corosync -f

Significado: Corosync está en ejecución. Si está flapeando, tienes un problema de membresía, no un problema de “eliminar nodo”.
Decisión: Si no está activo, arregla la red/timeouts/firewall del host antes de intentar la eliminación.

Task 4 — Leer logs de Corosync por pérdida de quorum o problemas de anillo

cr0x@server:~$ journalctl -u corosync -n 50 --no-pager
Dec 26 13:02:18 pve01 corosync[1320]:   [KNET  ] link: host: 2 link: 0 is up
Dec 26 13:02:19 pve01 corosync[1320]:   [QUORUM] Members[2]: 1 2
Dec 26 13:02:19 pve01 corosync[1320]:   [QUORUM] This node is within the primary component and will provide service.
Dec 26 13:05:31 pve01 corosync[1320]:   [TOTEM ] Token has not been received in 3000 ms
Dec 26 13:05:31 pve01 corosync[1320]:   [TOTEM ] A processor failed, forming new configuration.
Dec 26 13:05:33 pve01 corosync[1320]:   [QUORUM] Members[3]: 1 2 3

Significado: “Token has not been received” indica jitter en la red, desacuerdo de MTU o host sobrecargado.
Decisión: Si ves reconfiguraciones frecuentes, pospón la eliminación y estabiliza primero la red del clúster. Eliminar nodos durante churn es la forma de ganarse trabajo de fin de semana.

Task 5 — Confirmar que pmxcfs (/etc/pve) responde

cr0x@server:~$ pvesh get /cluster/status
[
  {
    "id":"cluster",
    "name":"prod-pve",
    "quorate":1,
    "version":27
  },
  {
    "id":"node/pve01",
    "ip":"10.10.10.11",
    "local":1,
    "name":"pve01",
    "online":1,
    "type":"node"
  },
  {
    "id":"node/pve02",
    "ip":"10.10.10.12",
    "local":0,
    "name":"pve02",
    "online":1,
    "type":"node"
  }
]

Significado: La API lee el estado del clúster rápidamente; pmxcfs probablemente está bien.
Decisión: Si esto cuelga o da error, puede haber problemas en pmxcfs; atiende el servicio pve-cluster y el quorum antes de hacer cualquier otra cosa.

Task 6 — Comprobar referencias de HA al nodo

cr0x@server:~$ ha-manager status
quorum OK
master pve01 (active, Fri Dec 26 13:12:19 2025)
lrm pve01 (active, Fri Dec 26 13:12:19 2025)
lrm pve02 (active, Fri Dec 26 13:12:17 2025)
service vm:101 (started)
service vm:203 (started)

Significado: HA está habilitado; tiene LRMs (gestores de recursos locales) para cada nodo.
Decisión: Si el nodo eliminado sigue listado como LRM y está muerto, la eliminación debería limpiarlo. Si servicios están fijados a ese nodo, migra o desactiva HA para esos recursos primero.

Task 7 — Encontrar VMs/CTs todavía configurados en el nodo que vas a eliminar

cr0x@server:~$ pvesh get /nodes/pve03/qemu --output-format yaml
- vmid: 310
  name: build-runner-03
  status: stopped
- vmid: 311
  name: legacy-db-test
  status: running

Significado: El nodo objetivo todavía tiene VMs definidas allí. Incluso si están en almacenamiento compartido, su asociación de configuración importa.
Decisión: Migra o mueve esos invitados. Si el nodo está muerto, verifica dónde residen sus discos antes de “eliminar el nodo” y asumir que aparecerán en otro sitio.

Task 8 — Comprobar dependencias de almacenamiento (¿algo es local al nodo?)

cr0x@server:~$ pvesm status
Name             Type     Status           Total        Used       Avail
local            dir      active        19632040     3921040    14750212
local-zfs        zfspool  active        247463936   90218496   157245440
ceph-rbd         rbd      active       104857600    52428800    52428800
nfs-backup       nfs      active       209715200    73400320   136314880

Significado: “local-zfs” es local al nodo a menos que sea un ZFS compartido sobre algo (raro). “ceph-rbd” y NFS son compartidos.
Decisión: Si las cargas dependen de almacenamiento local, replica o mueve discos antes de la eliminación. Si el nodo ya está muerto y los discos eran locales, tu tarea ahora es “restaurar desde backup”.

Task 9 — Verificar trabajos de replicación (si usas replicación ZFS)

cr0x@server:~$ pvesh get /cluster/replication
[
  {
    "id":"101-0",
    "source":"pve03",
    "target":"pve01",
    "schedule":"*/15",
    "last_sync":1735218600,
    "duration":42,
    "comment":"critical VM replication"
  }
]

Significado: Existe replicación y tiene una marca de tiempo de último sync.
Decisión: Si el nodo es accesible, fuerza un sync final antes del desmantelamiento. Si no es accesible, confirma que el destino tiene una réplica reciente y sabes cómo promoverla.

Task 10 — Eliminación planificada: migrar invitados fuera del nodo

cr0x@server:~$ qm migrate 311 pve01 --online
migration started
migration status: active
migration status: completed

Significado: La VM se movió con éxito.
Decisión: Repite hasta que el nodo no aloje invitados en ejecución. Si las migraciones fallan por almacenamiento, pausa y arregla eso—no improvises con discos medio migrados.

Task 11 — Eliminar el nodo del clúster (la eliminación real)

cr0x@server:~$ pvecm delnode pve03
Removing node 'pve03' from the cluster
Stopping pve-cluster on removed node if reachable...
Updating corosync config
Waiting for quorum...

Significado: El clúster está actualizando la membresía y sincronizando la configuración.
Decisión: Si se completa, valida las Tareas 12–13. Si da error con quejas de quorum, debes restaurar el quorum primero—no sigas intentando como si fuera una descarga inestable.

Task 12 — Confirmar que el nodo ha desaparecido de la membresía y votos esperados actualizados

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-pve
Config Version:   28
Transport:        knet
Secure auth:      on

Quorum information
------------------
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   2
Total votes:      2
Quorum:           2
Flags:            Quorate

Significado: El clúster ahora espera 2 votos. Eso es correcto para un clúster de 2 nodos, pero también es una etiqueta de advertencia.
Decisión: Si has quedado con 2 nodos, decide de inmediato si vas a añadir un tercer nodo o un qdevice. Dos nodos sin desempate es una apuesta por la fiabilidad.

Task 13 — Confirmar que no queda un directorio de nodo obsoleto en /etc/pve/nodes

cr0x@server:~$ ls -1 /etc/pve/nodes
pve01
pve02

Significado: La configuración compartida ya no rastrea el nodo eliminado.
Decisión: Si el directorio del nodo eliminado persiste, pmxcfs puede estar atascado o el quorum nunca fue real. Revisa las Tareas 1–5 y evita la eliminación manual a menos que estés en recuperación controlada.

Task 14 — Confirmar que el nodo eliminado ya no está en corosync.conf (desde cualquier nodo restante)

cr0x@server:~$ grep -R "pve03" -n /etc/pve/corosync.conf || echo "no references"
no references

Significado: La configuración de Corosync está limpia.
Decisión: Si quedan referencias, no lo eliminaste realmente, o tienes problemas de propagación de configuración. Arregla pmxcfs/quorum y vuelve a intentarlo.

Task 15 — Limpieza en el nodo eliminado (si aún es accesible)

cr0x@server:~$ systemctl stop pve-cluster corosync
cr0x@server:~$ rm -f /etc/pve/corosync.conf
cr0x@server:~$ rm -f /etc/corosync/authkey
cr0x@server:~$ rm -f /var/lib/corosync/*
cr0x@server:~$ systemctl disable corosync pve-cluster
Removed "/etc/systemd/system/multi-user.target.wants/corosync.service".
Removed "/etc/systemd/system/multi-user.target.wants/pve-cluster.service".

Significado: El nodo no volverá a unirse casualmente al clúster con credenciales obsoletas.
Decisión: Haz esto antes de reutilizar el host. Si lo omites, el nodo puede volver más tarde y confundir al clúster como un ex empleado cuyo pase aún funciona.

Task 16 — Si la eliminación falla por “no quorate”: identifica los nodos restantes que están de acuerdo

cr0x@server:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Fri Dec 26 13:18:22 2025
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1.30
Quorate:          No

Votequorum information
----------------------
Expected votes:   3
Total votes:      2
Quorum:           2

Significado: Tienes dos nodos arriba, pero expected votes sigue siendo 3, así que no estás en quorum.
Decisión: Tu arreglo inmediato es restaurar quorum (traer el tercero de vuelta, o usar un qdevice si eso era tu diseño). Sólo en una emergencia puedes ajustar temporalmente los votos esperados para recuperar quorum—ver la sección paso a paso para reglas de seguridad.

Chiste #2: La manera más rápida de aprender matemáticas de quorum es romperlo una vez, preferiblemente en un laboratorio y no durante la nómina.

Listas de verificación / plan paso a paso

Plan A: Desmantelamiento planificado (el nodo es accesible)

1. Anuncia una ventana de cambio. Manténla corta, pero no hagas esto durante un mantenimiento de red en los mismos switches.
2. Verifica la salud del clúster y el quorum desde un nodo restante.
   Usa las Tareas 1–5. Si algo flapea, para y arregla la estabilidad primero.
3. Drena el nodo.
   • Migra o apaga VMs/CTs (Tarea 10, además del equivalente para CT pct migrate si hace falta).
   • Desactiva expectativas de programación: si tienes HA, confirma que los recursos no estén fijados al nodo (Tarea 6).
4. Revisa dependencias de almacenamiento.
   Usa la Tarea 8. Si hay almacenamiento local, replica o mueve discos primero (Tarea 9).
5. Ejecuta la eliminación desde un nodo restante saludable: Tarea 11.
6. Valida la eliminación: Tareas 12–14.
7. Limpia el nodo eliminado: Tarea 15.
8. Reequilibra y fortalece.
   Si te quedaste con dos nodos, decide: añade un tercer nodo o añade un qdevice. No lo “dejes para después” a menos que ya esté programado.

Plan B: Pérdida no planificada (nodo muerto o inalcanzable)

1. Aísla física o lógicamente el nodo muerto.
   Si está flapeando en la red, puede perturbar Corosync. Desconecta su NIC, desactiva su puerto de switch o mantenlo apagado.
2. Estabiliza el quorum en los nodos supervivientes.
   Usa la Tarea 1 y la Tarea 4. Si no hay quorum, tu prioridad es restaurar quorum, no la estética de la limpieza.
3. Confirma las cargas y la ubicación de los datos del nodo muerto.
   Usa las Tareas 7 y 8 desde los nodos supervivientes. Decide:
   • Si los discos están en almacenamiento compartido (Ceph/NFS/iSCSI), puedes reiniciar invitados en otros nodos.
   • Si los discos eran sólo locales, entra en modo restauración: backups, réplicas o reconstrucción.
4. Elimina el nodo sólo después de estar en quorum.
   Tarea 11. Si el clúster se niega por quorum, no hagas ediciones aleatorias dentro de /etc/pve a menos que estés deliberadamente entrando en recuperación.
5. Tras la eliminación, confirma el estado de membresía y configuración limpio.
   Tareas 12–14.

Plan C: Recuperación de emergencia cuando el quorum es imposible (usar con moderación)

A veces tienes un clúster de 3 nodos, pierdes 2 nodos y la dirección quiere que “el último nodo en pie” sirva cargas.
Eso no es modo clúster. Es modo supervivencia. Puedes hacerlo, pero trátalo como energía de emergencia: ruidoso, oloroso, temporal.

El consejo seguro: restaura suficientes nodos para recuperar quorum o usa un dispositivo de quorum si tu entorno lo soporta.
Si absolutamente debes proceder con un único nodo restante, estás eligiendo anular el mecanismo de seguridad que evita el split brain.
Toma esa decisión explícitamente, escríbela y programa una limpieza para volver a un estado soportado.

Si necesitas forzar temporalmente los votos esperados para operaciones de recuperación (no para “operaciones normales”), hazlo con los ojos abiertos:

cr0x@server:~$ pvecm expected 1
Setting expected votes to 1
WARNING: forcing expected votes can lead to split-brain if other nodes are active

Significado: Le estás diciendo a Corosync que acepte un solo nodo como quorate.
Decisión: Hazlo sólo cuando estés seguro de que otros nodos no están realizando cambios simultáneamente (apágalos / aíslalos). Una vez recuperes nodos, revierte los votos esperados dejando que la membresía se normalice (o reincorpora nodos limpiamente).

Tres microhistorias corporativas desde el campo

Incidente causado por una suposición errónea: «offline significa seguro para borrar»

Una empresa mediana operaba un clúster Proxmox de tres nodos para servicios internos. Un nodo empezó a lanzar errores ECC.
Seguía accesible, pero se reiniciaba de forma impredecible. El ingeniero de guardia hizo una suposición razonable:
“Si está offline en la interfaz, eliminarlo es solo limpieza.”

Ejecutaron pvecm delnode mientras Corosync ya experimentaba timeouts intermitentes de token.
El clúster era técnicamente quorate en el momento del comando. Diez minutos después, el nodo inestable volvió,
se reincorporó brevemente con estado antiguo y luego volvió a caer. Los nodos restantes discreparon sobre la membresía el tiempo suficiente como para que pmxcfs
empezara a retrasarse, y una operación rutinaria de arranque de VM se quedó colgada.

El modo de fallo no fue dramático. Fue peor: una hemorragia lenta. La UI agotó tiempo, luego las llamadas API colgaron, y finalmente
el equipo tuvo que programar un mantenimiento de emergencia para restabilizar Corosync. El “regreso de entre los muertos” del nodo eliminado no
resucitó cargas; solo creó desacuerdo sobre quién podía cambiar la configuración compartida.

La corrección post-incidente fue aburrida: aislar primero el nodo (puerto de switch deshabilitado) y luego repetir la eliminación mientras el clúster estaba estable.
También implementaron una política: “Si un nodo es inestable, trátalo como malicioso hasta que esté totalmente en cuarentena.”

Optimización que salió mal: «vamos a operar con 2 nodos un tiempo»

Otra organización tuvo presión de presupuesto y falta de espacio en rack. Decidieron retirar temporalmente un nodo Proxmox,
operar con dos nodos durante un trimestre y luego añadir capacidad. En papel, todo parecía bien:
la mayor parte del almacenamiento estaba en iSCSI compartido y las VMs eran ligeras.

Eliminaron el nodo limpiamente. El quorum seguía mostrando “Yes”, porque los votos esperados coincidían con los dos nodos.
Y en el día a día funcionó—hasta el primer incidente de red real.
Un switch top-of-rack se reinició y los dos nodos perdieron conectividad de Corosync el tiempo suficiente como para que ambos
decidieran que estaban en problemas. HA se volvió conservador. Algunos servicios fallaron, otros se detuvieron y algunos quedaron en “unknown”.

El problema no fue que los clústeres de dos nodos nunca funcionen. Es que funcionan hasta que no funcionan, y entonces descubres que construiste tu modelo de fiabilidad sobre una moneda. Sin un tercer voto (qdevice o tercer nodo),
una partición puede convertirse en una parada dura para operaciones de gestión.

La “optimización” se revirtió: añadieron un dispositivo de quorum ligero en un dominio de fallo separado.
Después de eso, el mantenimiento rutinario de nodos dejó de ser un proyecto dramático. La lección no fue “nunca operar con dos nodos”.
Fue “no finjas que dos nodos se comportan como tres”.

Práctica aburrida pero correcta que salvó el día: «runbook de desmantelamiento + limpieza»

Un equipo relacionado con finanzas (es decir: todo auditado y nadie autorizado a divertirse) tenía una checklist estricta de desmantelamiento.
Cada eliminación de nodo requería: drenar cargas, verificar dependencias de almacenamiento, cuarentena explícita y un paso de limpieza en el nodo eliminado.
Parecía lento. La gente se quejó. Claro que sí.

Entonces un nodo retirado fue reutilizado por otro grupo. Reinstalaron el SO, lo reconectaron a la misma red de gestión
y lo encendieron. Eso habría sido un clásico incidente de “nodo zombi reaparece”—excepto que las credenciales antiguas del clúster y
el estado de Corosync se habían borrado durante el desmantelamiento original.

El nodo arrancó como un host Debian normal sin identidad de clúster. Nada intentó reincorporarse. Ningún voto cambió.
El clúster ni siquiera lo notó. El sonido más fuerte fue alguien dándose cuenta de que la checklist realmente tenía una razón.

La gracia salvadora no fue ingeniería brillante. Fue el hábito operativo más poco sexy: limpia después de ti para que el futuro-tú
no tenga que reconstruir tu intención a partir de una máquina medio configurada.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: pvecm delnode falla con “cluster not ready” o “not quorate”

Causa raíz: No hay quorum (expected votes aún incluye nodo faltante, o inestabilidad del anillo Corosync).

Solución: Restaura quorum (trae nodos de vuelta, estabiliza la red). Si es sólo emergencia, fuerza temporalmente los votos esperados (Plan C),
pero aísla todos los demás nodos primero para evitar split brain.

2) Síntoma: El nodo desaparece de pvecm nodes pero sigue apareciendo en la UI / /etc/pve/nodes

Causa raíz: Retardo en la replicación de pmxcfs, pve-cluster atascado o un nodo que no está realmente en quorum.

Solución: Verifica el servicio pve-cluster, confirma la capacidad de respuesta de la API (Tarea 5), confirma quorum (Tarea 1),
y vuelve a ejecutar la eliminación. Evita borrar manualmente dentro de /etc/pve a menos que estés en recuperación controlada.

3) Síntoma: Tras la eliminación, el clúster se vuelve frágil y las acciones de gestión cuelgan durante eventos de red menores

Causa raíz: Ahora tienes un clúster de 2 nodos sin desempate, o un diseño de red que no tolera particiones.

Solución: Añade un tercer nodo o configura un dispositivo de quorum. No aceptes “funciona la mayoría del tiempo” para el quorum.

4) Síntoma: HA sigue intentando recuperar recursos “en el nodo eliminado”

Causa raíz: La configuración de HA todavía referencia el nodo/grupos; restricciones de colocación obsoletas.

Solución: Revisa el estado de ha-manager, actualiza grupos HA, desactiva/elimina recursos que referencien el nodo y vuelve a verificar.

5) Síntoma: Los invitados no arrancan en otros hosts tras la pérdida del nodo

Causa raíz: Los discos estaban en almacenamiento local del nodo; el “clúster” no implicaba almacenamiento compartido.

Solución: Restaura desde backup, promueve réplicas o reconstruye el almacenamiento. Para el futuro: replica datasets ZFS o usa almacenamiento compartido (Ceph/NFS/iSCSI) para cargas críticas.

6) Síntoma: El nodo eliminado vuelve después y “se reincorpora” o causa confusión de membresía

Causa raíz: Lo eliminaste del clúster pero no limpiaste credenciales/estado en el host; conservó /etc/corosync/authkey y configuraciones antiguas.

Solución: Realiza la limpieza (Tarea 15) o reinstala. También aísla los nodos eliminados hasta que estén borrados.

7) Síntoma: Las operaciones en /etc/pve son lentas/colgadas durante intentos de eliminación

Causa raíz: pmxcfs está bloqueado debido a pérdida de quorum o inestabilidad de corosync; el montaje FUSE depende de la salud del clúster.

Solución: Estabiliza Corosync primero. No trates esto como un bug del sistema de ficheros; normalmente es protección del estado del clúster.

Preguntas frecuentes

1) ¿Por qué Proxmox se niega a eliminar un nodo cuando está offline?

Porque “offline” no equivale a “consenso”. Eliminar un nodo actualiza el estado compartido del clúster. Sin quorum, Proxmox no puede garantizar
que los nodos restantes estén de acuerdo con el cambio, así que te bloquea para evitar split brain.

2) ¿Puedo simplemente borrar el directorio del nodo bajo /etc/pve/nodes?

No lo hagas, a menos que estés deliberadamente en un procedimiento de recuperación y entiendas las consecuencias.
/etc/pve no es un sistema de ficheros normal; es estado gestionado por el clúster. Las ediciones manuales pueden desincronizar nodos o enmascarar el verdadero problema (quorum).

3) ¿Cuál es el orden más seguro: migrar cargas primero o eliminar nodo primero?

Migra primero, elimina segundo, limpia el host al final. Si el nodo está muerto, no puedes migrar, así que verificas la ubicación de los discos y restauras/promocionas en otro sitio antes de la eliminación.

4) Eliminé un nodo y ahora tengo un clúster de 2 nodos. ¿Eso está “soportado”?

Puede funcionar, pero es operativamente frágil. Añade un tercer voto (tercer nodo o dispositivo de quorum) si te importa el comportamiento predecible durante particiones y mantenimiento.

5) ¿Cómo sé si los discos de mi VM están en almacenamiento compartido o local?

Revisa las definiciones de almacenamiento (pvesm status) y la config de la VM (qm config <vmid>) para ver los backends de disco.
Si aparece local-zfs o local, asume que es local al nodo a menos que hayas construido algo exótico a propósito.

6) ¿Eliminar un nodo de Proxmox también lo quita de Ceph?

No. Ceph es un clúster propio. Debes eliminar por separado OSDs, monitores y entradas CRUSH si ese host participó en Ceph.
Coordina la secuencia para no dejar datos sin ubicación o perder quorum en Ceph mientras arreglas el quorum en Proxmox.

7) ¿Qué me dice «Expected votes»?

Indica cuántos votos Corosync cree que deberían existir. Si expected votes incluye nodos que ya no están, puedes perder quorum incluso si suficientes nodos están en línea.
Arregla los votos esperados restaurando la membresía propiamente (lo mejor) o forzándolo temporalmente para recuperación (lo peor, pero a veces necesario).

8) ¿Y si más tarde se reutiliza el nombre del nodo?

No reutilices el nombre hasta que el nodo antiguo esté completamente eliminado y limpio. Las herramientas de clúster suelen basarse en nombres de nodos en rutas de configuración.
Si debes reutilizarlo, asegúrate de que la membresía anterior haya desaparecido y que el nuevo host se una limpiamente con claves nuevas.

9) ¿Por qué la UI a veces sigue mostrando el nodo eliminado por un tiempo?

El estado de la UI puede retrasarse respecto al estado del clúster, especialmente si pmxcfs o la API tuvieron problemas durante el cambio.
Valida con pvecm nodes y /etc/pve/nodes; no confíes en la GUI como fuente de la verdad en un incidente de clúster.

10) ¿Cuál es la razón más común por la que la eliminación de nodo sale mal?

Hacerlo mientras el clúster está inestable: enlaces Corosync flapeando, particiones parciales o quorum degradado.
La gente culpa al comando. El comando está bien. El clúster está discutiendo.

Conclusión: siguientes pasos que no te perseguirán

La eliminación segura de un nodo en Proxmox no se trata del comando de borrado. Se trata de secuencia y certidumbre:
quorum, colocación de cargas, realidad del almacenamiento, luego el cambio de membresía y finalmente la limpieza para que el nodo antiguo no pueda volver.

Si haces una cosa después de leer esto: estandariza un runbook de desmantelamiento que incluya (1) verificación de quorum,
(2) comprobaciones de dependencias de almacenamiento y (3) limpieza en el host eliminado. Esa es la práctica aburrida que evita que “no se puede eliminar el nodo”
se convierta en “no se puede gestionar el clúster”.

Siguientes pasos prácticos:

• Ejecuta las Tareas 1–5 en tu clúster ahora y registra cómo se ve “saludable” para tu entorno.
• Si alguna vez operas con dos nodos, decide una estrategia de tercer voto y prográmala.
• Audita qué cargas aún dependen de almacenamiento local y o bien réplicalas o acepta explícitamente el dolor de restauración.
• Haz que “aislar nodos eliminados” sea innegociable: apagar, puerto deshabilitado o borrado. Preferiblemente las tres.