Proxmox “pmxcfs is not mounted”: por qué /etc/pve está vacío y cómo recuperarlo

enero 14, 2026 • febrero 3, 2026 • Lectura: 27 min • Views: 13

¿Te fue útil?

Inicias sesión en un nodo Proxmox y la interfaz web parece haber olvidado todo lo que creaste. No hay VMs. No hay definiciones de almacenamiento. No hay ajustes de clúster. Abres un shell y encuentras el verdadero horror: /etc/pve está vacío. Luego ejecutas un comando al azar (porque eso es lo que hacemos bajo estrés) y dice: pmxcfs is not mounted.

Esta falla se siente como “mis configuraciones se han perdido”. Normalmente no es así. La mayoría de las veces estás frente a un sistema de archivos de clúster (pmxcfs) caído o sin montar, no a un disco borrado. La tarea es identificar cuál de los tres sospechosos habituales lleva el cuchillo: pve-cluster, corosync o el quórum. Luego recuperar de una manera que no bifurque silenciosamente el estado del clúster hacia un desastre futuro.

Qué es realmente pmxcfs (y por qué /etc/pve es especial)

/etc/pve en Proxmox no es un directorio normal como tu memoria muscular espera. Es un sistema de archivos montado con FUSE llamado pmxcfs (Proxmox cluster filesystem). El proceso que lo monta y lo sirve forma parte de pve-cluster. Guarda la configuración a nivel de clúster en una pequeña base de datos y la expone como archivos.

Así que cuando ves “pmxcfs is not mounted” y /etc/pve parece vacío, típicamente significa:

pmxcfs no se montó (servicio caído, crash, permisos, problema FUSE).
pmxcfs está montado pero es dañino (bloqueo de base de datos, corrupción o incapacidad para lograr quórum del clúster).
estás mirando el punto de montaje sin el montaje (por eso ves un directorio vacío en el sistema de archivos raíz subyacente).

Y sí: puedes empeorarlo. La “solución” equivocada puede crear split-brain, sobrescribir una configuración buena con una obsoleta o divergir permanentemente los estados del clúster. Evita la improvisación.

Verdad cruda: La configuración de Proxmox son “solo archivos” y “no solo archivos”. pmxcfs lo hace parecer simple mientras depende silenciosamente de la membresía de corosync y de las reglas de quórum.

Datos interesantes y contexto histórico

pmxcfs usa FUSE: no es un sistema de archivos del kernel; funciona en espacio de usuario, lo que significa que los crash y fallos de montaje parecen “mi directorio desapareció”.
/etc/pve tiene alcance de clúster: incluso en un nodo único, Proxmox usa la abstracción del sistema de archivos de clúster para herramientas y comportamiento de UI uniformes.
El quórum bloquea escrituras: en clústeres multinodo, pmxcfs puede rechazar escrituras sin quórum para evitar split-brain.
Corosync viene del mundo HA: es un sistema de comunicación grupal usado históricamente en clústeres de alta disponibilidad; Proxmox lo aprovecha para membresía y mensajería.
Proxmox heredó la mentalidad “archivos como API”: editar archivos bajo /etc/pve es básicamente invocar la API de configuración; la UI y la CLI convergen allí.
pmxcfs mantiene una copia local de la base de datos: los nodos llevan estado localmente, por eso un nodo puede a menudo recuperar configuraciones incluso cuando la red está ardiendo.
Los clústeres de dos nodos son históricamente incómodos: la aritmética del quórum penaliza los números pares. Proxmox soporta dos nodos, pero debes comprender los modos de fallo.
QDevice existe porque la física existe: un tercer participante de quórum puede ser virtual (qnetd/qdevice) para no tener que comprar un tercer servidor completo.

Una cita que sigue aplicando en operaciones, especialmente cuando la UI está en blanco y tu pulso no: la esperanza no es una estrategia. — atribuida a Gordon R. Sullivan (parafraseada).

Síntomas que parecen pérdida de datos (pero normalmente no lo son)

Cuando pmxcfs no está montado, no solo pierdes un listado de directorio. Los componentes de Proxmox que esperan archivos de configuración de clúster comienzan a fallar en cascada:

La UI web no muestra VMs/CTs, o falla al cargar la configuración.
pvesm status muestra los almacenamientos como ausentes porque /etc/pve/storage.cfg está “desaparecido”.
Los archivos de configuración de VM bajo /etc/pve/qemu-server/*.conf parecen faltantes.
Comandos de clúster como pvecm status fallan o muestran “no quorum”.
Los trabajos de backup, replicación y la gestión HA se quejan porque leen el estado del clúster.

La pregunta diagnóstica clave: ¿Perdimos las VMs, o perdimos la vista de la configuración? En la mayoría de los casos, los discos/LVM/datasets ZFS siguen presentes; solo la capa de configuración está sin servicio.

Broma #1: Si /etc/pve está vacío, no es “minimalismo”, es tu sistema de archivos de clúster tomándose un día de baja.

Guía rápida de diagnóstico

Cuando la producción está caída, no necesitas una lección. Necesitas un bucle cerrado: identifica si esto es un problema de montaje, un problema de servicio o un problema de quórum. Hazlo en este orden.

Primero: ¿/etc/pve está realmente montado?

Si no está montado: céntrate en pve-cluster y problemas de FUSE/montaje.
Si está montado pero vacío/ilegible: céntrate en la salud de pmxcfs y en los logs.

Segundo: ¿pve-cluster está en ejecución y sano?

Si pve-cluster está caído o reiniciando: revisa logs por bloqueos de DB/corrupción, problemas de permisos o fallos de FUSE.

Tercero: ¿corosync está en ejecución y tienes quórum?

Si corosync está caído: pmxcfs puede no formar la membresía del clúster correctamente.
Si corosync está activo pero sin quórum: decide si estás en una interrupción multinodo (necesitas restaurar quórum) o en un entorno de nodo único donde puedes forzar temporalmente votos esperados (con precaución).

Cuarto: ¿los discos de las VMs siguen ahí?

Confirma datasets ZFS, volúmenes LVM o contenidos de directorios de almacenamiento. Si existen, probablemente estés enfrentando disponibilidad de configuración, no pérdida de datos.

Quinto: decide la vía de recuperación

Vía clúster: restaura la conectividad de corosync/quórum; evita cualquier paso de “reconstrucción” hasta que el quórum vuelva.
Vía independiente: arregla servicios locales; considera restaurar /etc/pve desde backups si la DB de pmxcfs está dañada.

Tareas prácticas: comandos, salidas esperadas y decisiones

Debajo hay tareas reales con comandos, qué significa su salida y la decisión siguiente. Ejecútalas como root o vía sudo. Toma notas. Bajo estrés olvidarás lo que ya comprobaste.

Tarea 1: Confirmar si pmxcfs está montado

cr0x@server:~$ mount | grep -E '/etc/pve|pmxcfs' || true
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Significado: Si ves pmxcfs on /etc/pve, el montaje existe. Si no ves nada, no está montado.

Decisión: Si no está montado, salta a verificaciones a nivel de servicio (Tarea 3). Si está montado pero vacío, revisa el quórum y los logs de pmxcfs (Tareas 4–7).

Tarea 2: Comprobar si /etc/pve está vacío porque no está montado

cr0x@server:~$ ls -la /etc/pve
total 0
drwxr-xr-x  2 root root  40 Dec 25 11:03 .
drwxr-xr-x 98 root root  80 Dec 25 10:58 ..

Significado: Un /etc/pve “vacío” con solo . y .. es clásico de un punto de montaje sin montar en el sistema de archivos raíz.

Decisión: Trátalo como un problema de montaje/servicio, no como configuraciones perdidas. No empieces a recrear configuraciones de VMs de memoria todavía.

Tarea 3: Verificar el estado del servicio pve-cluster

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: failed (Result: exit-code) since Thu 2025-12-25 10:59:33 UTC; 2min ago
    Process: 2210 ExecStart=/usr/bin/pmxcfs (code=exited, status=1/FAILURE)
     Main PID: 2210 (code=exited, status=1/FAILURE)

Significado: Si está fallado, pmxcfs no está sirviendo /etc/pve. Si está activo, continúa a corosync/quórum.

Decisión: Servicio fallado significa que lees logs y corriges la causa raíz antes de reiniciar a ciegas.

Tarea 4: Verificar el estado del servicio corosync

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Thu 2025-12-25 10:55:02 UTC; 6min ago
       Docs: man:corosync
   Main PID: 1020 (corosync)
      Tasks: 9 (limit: 15400)
     Memory: 23.4M

Significado: corosync es tu transporte de membresía de clúster. Si está caído, el quórum y el comportamiento de pmxcfs estarán fuera de lugar.

Decisión: Si corosync está inactivo/fallado, arréglalo primero (red, configuración, certificados no son el problema aquí; corosync es).

Tarea 5: Verificar el quórum rápidamente con pvecm

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

Quorum information
------------------
Date:             Thu Dec 25 11:01:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.23
Quorate:          No

Significado: “Quorate: No” suele ser la razón por la que pmxcfs se niega a comportarse en un clúster, especialmente para escrituras. Las lecturas también pueden degradarse dependiendo de las circunstancias.

Decisión: Si estás en un clúster multinodo y no hay quórum, céntrate en restaurar la conectividad de los nodos o el qdevice. Evita pasos de “reconstruir pmxcfs” hasta que el quórum vuelva.

Tarea 6: Comprobar la membresía de corosync desde este nodo

cr0x@server:~$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
	addr	= 10.10.10.11
	status:
		nodeid:          1:	connected
		nodeid:          2:	disconnected
		nodeid:          3:	disconnected

Significado: Este nodo no puede ver a los pares. Comúnmente es un problema de red o firewall, o los pares están caídos.

Decisión: Si los pares deberían estar arriba, revisa rutas de red y MTU. Si los pares están caídos, decide si traerlos de vuelta o (con cuidado) usar una solución de quórum de emergencia.

Tarea 7: Leer los logs de pve-cluster para la razón real

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager -n 80
Dec 25 10:59:33 server pmxcfs[2210]: [main] notice: starting pmxcfs
Dec 25 10:59:33 server pmxcfs[2210]: [main] crit: Unable to acquire pmxcfs lock: Resource temporarily unavailable
Dec 25 10:59:33 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=1/FAILURE
Dec 25 10:59:33 server systemd[1]: pve-cluster.service: Failed with result 'exit-code'.

Significado: La contención de bloqueo puede ocurrir tras un crash o si hay un proceso obsoleto en ejecución. Esto es accionable.

Decisión: Busca procesos pmxcfs huérfanos o estado de bloqueo residual; no hagas rm -rf en directorios al azar como terapia.

Tarea 8: Buscar procesos pmxcfs obsoletos

cr0x@server:~$ ps aux | grep -E 'pmxcfs|pve-cluster' | grep -v grep
root       1987  0.0  0.1  45620  9400 ?        Ss   10:58   0:00 /usr/bin/pmxcfs

Significado: Si pmxcfs ya está en ejecución, iniciarlo de nuevo puede fallar con un error de bloqueo. Si hay múltiples pmxcfs, tienes un lío.

Decisión: Si hay un pmxcfs huérfano, detén el servicio limpiamente y asegúrate de que salga antes de reiniciarlo.

Tarea 9: Reiniciar servicios en orden controlado

cr0x@server:~$ systemctl restart corosync
cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ systemctl restart pvedaemon pveproxy

Significado: corosync primero (membresía), luego pmxcfs, luego los daemons que sirven UI/API.

Decisión: Si pve-cluster sigue fallando, vuelve a los logs. Si arranca pero el quórum sigue ausente, no empieces a editar configuraciones.

Tarea 10: Confirmar el montaje y contenido de /etc/pve tras el reinicio

cr0x@server:~$ mount | grep /etc/pve
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
cr0x@server:~$ find /etc/pve -maxdepth 2 -type f | head
/etc/pve/corosync.conf
/etc/pve/storage.cfg
/etc/pve/user.cfg
/etc/pve/domains.cfg
/etc/pve/qemu-server/101.conf

Significado: Si ves estos archivos, pmxcfs está montado y sirviendo datos de nuevo.

Decisión: Ahora puedes seguir con la corrección del estado del clúster o problemas de runtime de VMs. Si sigue vacío, detente y reevalúa.

Tarea 11: Validar salud del sistema de archivos de clúster y operaciones de archivo

cr0x@server:~$ pvecm status | grep -E 'Quorate|Nodes|Name'
Name:             prod-cluster
Nodes:            3
Quorate:          Yes
cr0x@server:~$ test -r /etc/pve/storage.cfg && echo "read ok"
read ok

Significado: Quórum “Yes” más configuración legible significa que el sistema de archivos de clúster está en un estado estable.

Decisión: Si quórum es “No”, evita cambios de configuración. Si es “Yes”, procede con operaciones normales y limpieza.

Tarea 12: Confirmar que los discos de VM siguen existiendo (ejemplo ZFS)

cr0x@server:~$ zfs list -o name,used,avail,mountpoint | grep -E 'rpool/data|vm-'
rpool/data                 128G  1.72T  /rpool/data
rpool/data/vm-101-disk-0   64G   1.72T  -
rpool/data/vm-102-disk-0   64G   1.72T  -

Significado: Los discos existen. Probablemente “perdiste” solo la capa de configuración, no los datos de VM.

Decisión: Si los discos están presentes, céntrate en recuperar las configuraciones; no inicialices el almacenamiento.

Tarea 13: Confirmar que los discos de VM siguen existiendo (ejemplo LVM-thin)

cr0x@server:~$ lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent
LV              VG   Attr       LSize   Data%  Meta%
data            pve  twi-aotz--  <1.80t  42.11  3.02
vm-101-disk-0    pve  Vwi-a-tz--  64.00g
vm-102-disk-0    pve  Vwi-a-tz--  64.00g

Significado: Tus volúmenes de VM están intactos.

Decisión: No toques el thin pool. Tu urgencia es la configuración + salud del clúster.

Tarea 14: Buscar copias de seguridad de /etc/pve

cr0x@server:~$ ls -la /var/lib/pve-cluster/
total 20
drwxr-xr-x  5 root root 4096 Dec 25 10:59 .
drwxr-xr-x 50 root root 4096 Dec 25 10:58 ..
drwxr-xr-x  2 root root 4096 Dec 25 10:58 backup
drwxr-xr-x  2 root root 4096 Dec 25 10:59 config
drwx------  2 root root 4096 Dec 25 10:59 db
cr0x@server:~$ ls -la /var/lib/pve-cluster/backup | head
total 64
-rw------- 1 root root 65536 Dec 24 02:05 config-2025-12-24_02_05_01.tar

Significado: Proxmox a menudo guarda backups de configuración de clúster localmente. Ese es tu paracaídas “aburrido pero efectivo”.

Decisión: Si la DB de pmxcfs está corrupta, restaurar desde estos backups suele ser más seguro que reconstruir manualmente storage.cfg, usuarios, permisos y configs de VM.

Tarea 15: Confirmar ruta de red básica para corosync (knet)

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.10.11/24
eno2             DOWN
cr0x@server:~$ ping -c 2 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.398 ms

--- 10.10.10.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Significado: Si la conectividad básica a peers está rota, corosync no formará membresía. Si ping funciona pero corosync no, piensa en firewall, MTU o filtrado de puertos.

Decisión: Arregla la red antes de tocar la configuración del clúster. Los problemas de corosync rara vez se resuelven editando archivos al azar durante una caída.

Tarea 16: Buscar problemas de sistema de archivos o disco que puedan provocar crash de pmxcfs

cr0x@server:~$ dmesg -T | tail -n 20
[Thu Dec 25 10:57:10 2025] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[Thu Dec 25 10:57:10 2025] EXT4-fs (sda2): Remounting filesystem read-only

Significado: Si el sistema de archivos raíz se remonta como solo lectura, pmxcfs puede fallar al actualizar su DB/estado de bloqueo y los servicios se desmoronan.

Decisión: Deja de tratar esto como “Proxmox está raro”. Esto es un problema de almacenamiento. Arregla el disco, remonta y reinicia si es necesario.

Rutas de recuperación (nodo único vs clúster)

Camino A: Nodo único (o “no me importa la membresía del clúster, necesito mis configuraciones”)

En un sistema Proxmox de un solo nodo real (o un nodo que has desacoplado intencionadamente), te interesa principalmente conseguir que pve-cluster monte pmxcfs y presente /etc/pve. El quórum normalmente no es la puerta de control como en clústeres multinodo.

Causas típicas en un nodo único:

pve-cluster no arrancó debido a contención de bloqueo o procesos huérfanos.
el sistema de archivos raíz está en solo lectura tras un problema de disco.
corrupción de la base de datos de pmxcfs tras un crash o pérdida de energía.

Lo primero que hago: arreglar el FS raíz y los servicios. Solo si los logs apuntan a una DB de pmxcfs rota, restauro desde un tar de backup local.

Cuando pmxcfs no se monta por bloqueo/proceso huérfano

Si journalctl menciona incapacidad para adquirir el lock de pmxcfs, identifica el proceso huérfano, detén servicios y reinicia limpiamente. No uses “kill -9” salvo que hayas intentado una detención normal y siga atascado.

cr0x@server:~$ systemctl stop pve-cluster
cr0x@server:~$ pkill -TERM pmxcfs || true
cr0x@server:~$ sleep 2
cr0x@server:~$ ps aux | grep pmxcfs | grep -v grep || echo "no pmxcfs running"
no pmxcfs running
cr0x@server:~$ systemctl start pve-cluster
cr0x@server:~$ mount | grep /etc/pve
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Punto de decisión: Si eso lo arregla, ya está. Si vuelve a fallar, buscas un problema más profundo: disco en solo lectura, falta de soporte FUSE o corrupción de DB.

Cuando el sistema de archivos raíz pasó a solo lectura

Esto es clásico: “todo falla, pero la causa raíz es una línea en dmesg”. Si ext4 se remonta como solo lectura, no puedes confiar en pmxcfs ni en corosync.

Arregla el problema de disco subyacente. Puede implicar comprobar SMART, programar fsck y reiniciar. Si este nodo es virtualizado (sí, hay gente que lo hace), arregla el almacenamiento del hipervisor también.

Cuando la DB de pmxcfs está dañada y necesitas restaurar configuración

Si tienes backups locales en /var/lib/pve-cluster/backup, restaurar suele ser más seguro que reconstruir storage.cfg, usuarios, permisos y configs de VM a mano.

Sé estricto: haz esto solo cuando estés seguro de que la configuración local del nodo es la fuente de la verdad, no una copia obsoleta frente a otros nodos.

Un método práctico es extraer el tar de backup en un lugar seguro y comparar lo que vas a restaurar. Luego procede con el método de restauración menos invasivo posible.

cr0x@server:~$ mkdir -p /root/pve-restore
cr0x@server:~$ tar -tf /var/lib/pve-cluster/backup/config-2025-12-24_02_05_01.tar | head
etc/pve/corosync.conf
etc/pve/storage.cfg
etc/pve/user.cfg
etc/pve/qemu-server/101.conf
etc/pve/lxc/103.conf

Punto de decisión: Si el tar contiene la configuración esperada, puedes restaurar archivos seleccionados una vez pmxcfs esté montado. Si pmxcfs no monta, primero debes reparar pmxcfs; volcar archivos en un /etc/pve no montado solo escribe en el directorio vacío del FS raíz y no resuelve nada.

Camino B: Nodo en clúster (aquí es donde la gente pierde fines de semana)

En un clúster, pmxcfs está entrelazado con la membresía de corosync y las reglas de quórum. La recuperación correcta depende de si:

Este nodo está aislado pero los otros están bien.
El clúster entero está parcialmente caído (nodos perdidos, red perdida, qdevice perdido).
Realmente existe riesgo de split-brain (dos mitades creen ser primarias).

Regla que impongo: Si puedes restaurar quórum trayendo nodos/red de vuelta, haz eso. No “forces” el quórum como primer movimiento. Forzar el quórum es como puentear un fusible con un clavo. Funciona. También te enseña nuevas clases de fallo.

Restaura la conectividad de corosync antes de tocar /etc/pve

Corosync es sensible a:

Particiones de red y cambios de firewall
Desajustes de MTU (especialmente si moviste a jumbo frames “por rendimiento”)
Vinculación a interfaz incorrecta tras renombre de NIC o reemplazo de hardware
Nombres de host rotos o cambios de IP (especialmente si reconstruiste un nodo desde una plantilla)

Pon a los nodos a hablar. Luego verifica el quórum. Luego confirma la salud del montaje de pmxcfs.

Clústeres de dos nodos y qdevice: las matemáticas no cuidan tu optimismo

Los clústeres de dos nodos son posibles, pero están llenos de trampas si los tratas como clústeres de tres nodos. Si un nodo cae, pierdes quórum a menos que tengas un qdevice o ajustes temporalmente los votos esperados.

Los cambios temporales de expected-votes pueden sacarte del apuro, pero son maniobras de emergencia. Deben revertirse cuando el clúster vuelva a la normalidad. Si no, “arreglaste” el quórum redefiniendo la realidad, lo cual es una estrategia audaz en ingeniería de sistemas.

Broma #2: El quórum es como una reunión: nada se decide hasta que vienen suficientes personas, y la única que vino siempre está enfadada.

Cuando es (más o menos) seguro usar una solución de quórum de emergencia

Usa una solución solo si:

Estás seguro de que los nodos faltantes están caídos, no vivos y particionados.
Aceptas el riesgo de que los cambios de configuración hechos ahora puedan entrar en conflicto cuando los nodos vuelvan.
Intentas restaurar servicio a VMs que viven en este nodo y necesitas que pmxcfs sea escribible.

Si tienes dudas, no. Arregla la red. Trae los nodos arriba. Restaura el quórum normal.

Tres micro-historias del mundo corporativo

Micro-historia 1: El incidente causado por una suposición equivocada

Tenían un clúster Proxmox de tres nodos y una ventana de cambios ordenada. Un nodo necesitaba una actualización de firmware. El plan: sacarlo, parchearlo, devolverlo. Estándar.

Alguien notó que el clúster todavía parecía “saludable” en la UI después del reinicio del nodo, así que procedieron a reiniciar un segundo nodo para actualizarlo también. La suposición fue simple: “Si la UI está arriba, el clúster está bien”.

El segundo reinicio hizo caer el quórum. pmxcfs en el nodo restante no se montó correctamente, y /etc/pve quedó vacío. La UI pasó de “más o menos sana” a “parece una instalación nueva” en menos de un minuto. El pánico siguió, naturalmente.

La siguiente jugada equivocada: un ingeniero empezó a recrear definiciones de almacenamiento en la UI. Sin quórum, algunas escrituras se bloquearon, otras quedaron inconsistentes y algunas se hicieron en un nodo que más tarde resultó no ser la mejor fuente de la verdad.

Cuando el segundo nodo volvió y el quórum se restableció, el estado del clúster convergió —pero no de la manera deseada. Pasaron el resto de la noche desenredando almacenamientos duplicados, configs de VM obsoletas y definiciones conflictivas. Nada se “perdió”, pero tampoco estaba “correcto”.

Lo que lo arregló: revertir las ediciones improvisadas, restaurar la configuración original desde un tar de backup conocido y luego reintroducir nodos uno por uno verificando quórum y salud de montaje pmxcfs. La lección no fue “nunca reiniciar nodos”. Fue “nunca tratar la UI como un oráculo de quórum”.

Micro-historia 2: La optimización que salió mal

Un equipo quería menor latencia entre nodos para corosync, tráfico Ceph y migraciones en vivo. Consolidaron el tráfico de clúster en una VLAN “más rápida” y activaron jumbo frames. Funcionó en laboratorio. Por supuesto que sí.

En producción, una ruta de switch no soportaba silenciosamente el MTU extremo a extremo. El ping funcionaba porque los paquetes pequeños no importan. Corosync a veces funcionaba, luego flapeaba, luego declaraba peers muertos. Los nodos aparecían y desaparecían como compañeros de trabajo poco fiables.

En uno de los nodos, pmxcfs se desmontaba intermitentemente o se negaba a operar debido a membresía/quórum inestable. Las operaciones veían el síntoma: /etc/pve vacío, VMs ausentes en la UI, “pmxcfs is not mounted.” Los ingenieros de almacenamiento veían el síntoma más profundo: una capa de membresía de clúster oscilando bajo carga.

La “optimización” creó un patrón de caída peor que una falla limpia. Fue una falla a cámara lenta: lo bastante estable para que la gente cambiara cosas, lo bastante inestable para corromper su modelo mental.

La solución fue aburrida: revertir MTU a 1500 en el anillo de corosync, separar tráfico de corosync del tráfico de almacenamiento a granel y validar con tamaños de paquete reales. El equipo luego reintrodujo jumbo frames solo donde se comprobó soporte extremo a extremo, con monitorización para estadísticas de enlace de corosync. El rendimiento volvió luego. La estabilidad volvió de inmediato.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Otra organización tenía la costumbre: cada nodo tenía un job nocturno que copiaba /var/lib/pve-cluster/backup a un objetivo de almacenamiento fuera del clúster. No era sofisticado. Solo consistente.

También mantenían un pequeño “cuaderno de desastre”: inventario de nodos, nombre del clúster, direcciones del anillo corosync y una página “cómo confirmar quórum” tipo checklist. Lo escribió alguien que claramente no confiaba en la memoria, incluida la propia.

Durante un evento de energía, un nodo arrancó con errores en el sistema de archivos raíz y pmxcfs se negó a montar. La UI no mostraba nada. Pero no se apresuraron a reconstruir. Comprobaron montajes, corosync y confirmaron que los otros nodos todavía tenían quórum.

Reconstruyeron el nodo roto como una nueva instalación del OS, luego lo volvieron a unir al clúster usando la información almacenada. Después de eso, restauraron los bits específicos del host necesarios y validaron que pmxcfs mostraba la configuración correcta del clúster. Las VMs no se vieron afectadas porque su almacenamiento estaba en backends compartidos.

Lo que “salvó el día” no fue un truco ingenioso. Fue tener un backup de configuración consistente más un runbook aburrido. No “heroizaron” la caída. Siguieron el proceso y se fueron a casa a una hora razonable, que es el verdadero lujo.

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

Esta sección es opinada porque los mismos errores se repiten entre equipos. Algunos son comprensibles. La mayoría son evitables.

Error 1: “/etc/pve está vacío, así que las configs fueron borradas”

Síntoma: ls /etc/pve no muestra nada; la UI no muestra VMs.

Causa raíz: pmxcfs no está montado. Estás viendo el directorio del punto de montaje vacío en el sistema de archivos subyacente.

Solución: Comprueba mount | grep /etc/pve, luego arregla pve-cluster y corosync/quórum.

Error 2: Recrear configuraciones mientras falta quórum

Síntoma: Las cosas “vuelven” pero ahora los almacenamientos/VMs están duplicados o los permisos son extraños.

Causa raíz: Cambiaste la configuración del clúster en un estado degradado/sin quórum. Más tarde, el clúster se reconcilió con otros nodos y obtuviste una configuración Frankenstein.

Solución: Restaura el quórum primero. Si debes cambiar la configuración en modo de emergencia, documenta cada cambio y planea reconciliar cuando el quórum vuelva.

Error 3: Reiniciar servicios al azar y esperar

Síntoma: A veces funciona, a veces no; reinicios de pveproxy no ayudan.

Causa raíz: pveproxy/pvedaemon dependen de pmxcfs para la configuración. Reiniciar la UI no monta el sistema de archivos.

Solución: Empieza con corosync y pve-cluster. Luego reinicia los daemons de UI.

Error 4: Editar archivos bajo /etc/pve cuando no está montado

Síntoma: “Arreglaste” /etc/pve/storage.cfg pero nada cambia en la UI.

Causa raíz: Escribiste en el directorio plano del sistema de archivos raíz, no en pmxcfs.

Solución: Verifica el montaje primero. Si pmxcfs no está montado, tus ediciones fueron al lugar equivocado. Elimina los archivos falsos después de la recuperación para evitar confusiones.

Error 5: Tratar un clúster de dos nodos como si tuviera redundancia de quórum

Síntoma: Pierdes un nodo y el nodo restante queda sin quórum, el comportamiento de pmxcfs se degrada.

Causa raíz: Los clústeres de dos nodos necesitan qdevice o una gestión cuidadosa de votos.

Solución: Añade qdevice, o acepta que perder un nodo implique pérdida de quórum y planifica las operaciones en consecuencia.

Error 6: “Arreglar” borrando la DB de pmxcfs sin un plan

Síntoma: pmxcfs arranca, pero la configuración se restablece o es inconsistente; la identidad del clúster cambia; los nodos no concuerdan.

Causa raíz: Borraste el estado local del clúster sin entender si ese nodo era autoritativo o cómo se resincniría.

Solución: Solo realiza acciones destructivas en la DB cuando hayas identificado el nodo(s) autoritativo(s) y tengas backups. Prefiere restaurar desde /var/lib/pve-cluster/backup cuando corresponda.

Error 7: Ignorar errores de disco subyacentes

Síntoma: pmxcfs/corosync flapean, sistema de archivos raíz en solo lectura, servicios fallan de formas extrañas.

Causa raíz: Problemas reales de almacenamiento o corrupción de sistema de archivos.

Solución: Detén y arregla el disco. Ningún reinicio de servicios curará un sistema de archivos remonto en solo lectura.

Listas de verificación / plan paso a paso

Checklist 1: Triaging inmediato (10 minutos, sin heroísmos)

Comprueba el montaje: mount | grep /etc/pve.
Comprueba pve-cluster y corosync estado.
Comprueba el quórum: pvecm status.
Revisa logs: journalctl -u pve-cluster -b -n 80 y journalctl -u corosync -b -n 80.
Confirma que los discos existen (ZFS/LVM). Esto evita pánicos destructivos.

Checklist 2: Si pmxcfs no está montado

Verifica que el FS raíz sea escribible: revisa dmesg -T | tail por eventos de remount a solo lectura.
Detén pve-cluster limpiamente; busca procesos pmxcfs huérfanos.
Arranca corosync (si es clúster) y luego pve-cluster.
Confirma que /etc/pve está montado y no está vacío.
Sólo después de que pmxcfs esté montado: reinicia pveproxy/pvedaemon.

Checklist 3: Si corosync/quórum es el problema

Confirma la alcanzabilidad de la red y las IPs correctas en el anillo corosync.
Comprueba la membresía: corosync-cfgtool -s.
Trae de vuelta los nodos faltantes si es posible; restaura la membresía normal.
Si es clúster de dos nodos: asegúrate de que el qdevice sea accesible, o reconoce que necesitas un cambio de expected-votes de emergencia (y apunta lo que cambiaste).
Tras restaurar el quórum: valida que /etc/pve muestre los archivos esperados y que los nodos concuerden en el estado del clúster.

Checklist 4: Si la DB de pmxcfs parece corrupta

Detén y captura evidencias: logs, estados de servicios y copias de tars de backup.
Identifica el nodo autoritativo (en un clúster: el que tenga quórum sano y la configuración esperada).
Usa backups desde /var/lib/pve-cluster/backup cuando proceda; evita reconstrucciones manuales salvo que te gusten los errores sutiles.
Valida archivos críticos: corosync.conf, storage.cfg, qemu-server/*.conf, configs de ACL/usuarios.
Pon los servicios arriba, valida la UI y luego valida los mapeos reales de discos de VM antes de arrancar cargas de trabajo.

Preguntas frecuentes

1) ¿Por qué /etc/pve queda vacío en vez de mostrar archivos antiguos?

Porque /etc/pve es un punto de montaje. Cuando pmxcfs no está montado, estás viendo el directorio subyacente en el sistema de archivos raíz, que normalmente está vacío.

2) ¿Mis discos de VM se borran cuando /etc/pve está vacío?

Normalmente no. Los discos de VM viven en datasets ZFS, volúmenes LVM, Ceph RBD o directorios en otro lugar. Valida con zfs list, lvs o tus herramientas de backend de almacenamiento antes de asumir pérdida de datos.

3) ¿Puedo simplemente reiniciar para arreglar “pmxcfs is not mounted”?

A veces. Pero si la causa es errores de disco, partición de red o configuración rota de corosync, reiniciar es solo una forma que consume tiempo para obtener el mismo fallo con tiempo de inactividad extra.

4) Si corosync está caído, ¿pmxcfs aún puede montarse?

En un nodo de clúster, el comportamiento de pmxcfs está fuertemente acoplado al estado del clúster. Puede montarse pero degradado, rechazar escrituras o comportarse de forma inconsistente. Trata a fallos de corosync como primarios hasta demostrar lo contrario.

5) ¿Cuál es el comando más seguro al ver este error?

mount | grep /etc/pve y systemctl status pve-cluster corosync. Quieres saber si es un problema de montaje, de servicio o de quórum/membresía.

6) ¿Puedo editar archivos en /etc/pve directamente para recuperar?

Sí—cuando pmxcfs está montado y el clúster está sano/quorate. No—cuando no está montado, porque editarás el lugar equivocado y crearás confusión.

7) ¿Y si solo un nodo muestra /etc/pve vacío pero otros están bien?

Ese nodo probablemente esté aislado, mal configurado en red o tenga un problema local de servicio/disco. Compara la membresía de corosync y los logs. No “repares el clúster” desde el nodo roto.

8) ¿Cómo evito que esto sea un incidente mayor la próxima vez?

Mantén backups de configuración fuera del nodo, monitoriza quórum y estado de enlace de corosync, evita optimizaciones de red riesgosas sin validación extremo a extremo y ensaya procedimientos de pérdida de nodos.

9) ¿“no quorum” siempre significa que /etc/pve estará vacío?

No. “No quorum” suele afectar la capacidad de confirmar cambios de forma segura, y puede provocar comportamiento degradado, pero un /etc/pve vacío sugiere fuertemente que pmxcfs no está montado o no está en ejecución.

10) ¿Debo eliminar y volver a añadir el nodo al clúster?

Sólo después de confirmar si el estado local del nodo está corrupto y si el clúster es estable. Volver a unir a veces es la respuesta correcta, pero es un paso final, no el primer intento.

Siguientes pasos que realmente deberías hacer

Si lograste montar pmxcfs otra vez y /etc/pve está poblado, no te detengas allí. La fase de “todo parece bien” es donde se esconden problemas latentes.

Confirma la estabilidad de quórum y membresía durante unos minutos. Si corosync está flapeando, no has terminado.
Valida la consistencia de configuración entre nodos: definiciones de almacenamiento, configs de VM y permisos.
Confirma que los discos de VM están mapeados correctamente antes de arrancar cargas críticas. Una discrepancia de configuración puede apuntar una VM al disco equivocado.
Exporta backups fuera del nodo de /var/lib/pve-cluster/backup si aún no lo haces.
Escribe la causa raíz y la solución exacta que aplicaste. El tú del futuro es un desconocido con menos sueño.

El objetivo no es “recuperar la UI”. El objetivo es restaurar un plano de control consistente, quorate y duradero para que cómputo y almacenamiento no deriven hacia la leyenda urbana.