Sistema de archivos de Proxmox en modo solo lectura: por qué ocurre y cómo recuperar

Qué significa realmente “solo lectura” en Proxmox

“Solo lectura” no es una sola cosa. En un host Proxmox puedes tener:

• El sistema de archivos raíz (normalmente ext4 o root ZFS, a veces XFS) montado en solo lectura por el kernel tras errores.
• Un sistema de archivos de datos (dataset ZFS, ext4/XFS sobre LVM, montaje NFS/Ceph) que pasa a solo lectura mientras el host sigue pudiendo escribir en otros sitios.
• pmxcfs (el sistema de archivos de clúster de Proxmox montado en /etc/pve) que se niega a aceptar escrituras cuando no hay cuórum o hay problemas en la base de datos local.
• Comportamiento a nivel de aplicación que parece un problema de sistema de archivos (por ejemplo, dataset ZFS con readonly=on, o un backend de almacenamiento devolviendo EROFS).

El kernel cambia un montaje a modo solo lectura cuando cree que continuar con las escrituras puede corromper los metadatos. Eso no es Linux dramatizando; es Linux negándose a ser tu cómplice.

Regla #1: identifica qué montaje está en solo lectura y qué está generando la ruta de error (VFS, controlador de sistema de archivos, capa de bloques o servicio de clúster). Si te saltas esto, pasarás una hora remontando lo equivocado y te sentirás productivo mientras nada mejora.

Guion de diagnóstico rápido (primero/segundo/tercero)

Primero: confirma qué está en solo lectura y dónde fallan las escrituras

• ¿Es /? ¿/var? ¿/etc/pve? ¿Un dataset ZFS como rpool/data? ¿Un recurso NFS montado?
• Prueba una pequeña escritura en la ruta que falla (no “arregles” nada todavía). Es una sonda.

Segundo: captura la historia del kernel antes de que se pierda

• dmesg -T y journalctl -k -b te dicen si el kernel vio errores I/O, corrupción de sistema de archivos, suspensión de pool ZFS o un apagado forzado.
• Busca: Buffer I/O error, EXT4-fs error, XFS (…): Corruption detected, blk_update_request, reinicios ata/nvme, ZFS: pool I/O suspended.

Tercero: decide si esto es “almacenamiento enfermo” o “sistema de archivos enfermo”

• Almacenamiento enfermo: errores I/O, timeouts, resets, advertencias SMART, errores de medios NVMe. Repara hardware/cableado/controlador primero. Ejecutar fsck sobre un disco que falla activamente es cómo conviertes un raspón en una amputación.
• Sistema de archivos enfermo: salud del dispositivo limpia, pero errores en metadatos. Entonces repara (fsck/xfs_repair/zpool clear según la pila).
• Clúster/cuórum enfermo: solo /etc/pve está en solo lectura y los logs muestran pérdida de cuórum. Eso es político, no físico.

Toma una decisión rápido: estabiliza, preserva evidencia y luego repara. Tu objetivo es evitar daños en cascada (discos de VM, logs, bases de datos) mientras recuperas el servicio.

Por qué los sistemas de archivos pasan a solo lectura (modos reales de fallo)

1) Errores reales de I/O en disco (la causa “real” más común)

Cuando la capa de bloques no puede completar escrituras, los sistemas de archivos suelen responder remountando en solo lectura para evitar metadata medio escrita. Esto puede venir de:

• Sectores defectuosos en HDDs o desgaste de NAND en SSDs
• Reinicios del controlador NVMe o bugs de firmware
• Problemas con cables SATA (sí, aún existen)
• Fallos del controlador RAID o problemas con caché/batería
• Pérdida de energía que provoca panics internos del dispositivo

En Proxmox, la primera pista suele estar en dmesg mucho antes de que veas “solo lectura” en la capa de montaje.

2) Corrupción de metadatos del sistema de archivos (ext4/XFS)

ext4 tiene una política de comportamiento ante errores. Valores por defecto comunes: remount read-only al detectar errores. XFS tiende a forzar un apagado si detecta corrupción. Ambos te están haciendo un favor—aunque inconveniente.

3) Problemas en un pool ZFS: I/O suspendido, vdevs faulted o desaparición de dispositivos

ZFS no “remonta solo lectura” del mismo modo que ext4. En su lugar puede suspender I/O para proteger la consistencia cuando no puede garantizar las escrituras. Desde la perspectiva de la VM es similar: operaciones cuelgan o fallan y Proxmox empieza a registrar fallos de almacenamiento.

4) Sistema de archivos lleno o agotamiento de inodos (parece solo lectura si no lees el error)

Un sistema de archivos lleno suele mostrar No space left on device, no “solo lectura”. Pero mucha gente interpreta “no puedo escribir” como “solo lectura”. En un host Proxmox, /var se llena por logs, backups, volcados de kernel o escrituras descontroladas de contenedores.

5) pmxcfs (/etc/pve) en solo lectura por pérdida de cuórum

/etc/pve es un sistema de archivos basado en FUSE (pmxcfs). Cuando el clúster pierde cuórum, Proxmox te protege de split-brain haciendo que la configuración del clúster sea de solo lectura. La gente lo diagnostica mal como fallo de disco porque la cadena de error es idéntica.

6) “Optimizaciones” que crean fragilidad

Cachés de escritura sin protección contra pérdida de energía, configuraciones agresivas de discard, deshabilitar barriers, modos RAID exóticos, dispositivos USB baratos para el arranque… todo eso puede producir remounts “sorprendentes” en eventos de estrés o energía. La sorpresa solo existe para quien lo configuró.

Broma #1: El almacenamiento es como lanzarse en paracaídas—la mayor parte del tiempo es aburrido, y las partes emocionantes rara vez se repiten de manera positiva.

Hechos e historia interesantes que puedes usar

1. La herencia de “errors=remount-ro” de ext4 viene de la era ext2/ext3: si los metadatos son sospechosos, deja de escribir rápido para preservar la recuperabilidad.
2. XFS nació en SGI para cargas de trabajo de gran envergadura; su comportamiento de “force shutdown” es una postura deliberada de “mejor muerto que corrupto”.
3. Linux VFS usa EROFS (“Error Read-Only File System”) como señal genérica—por eso causas totalmente diferentes pueden parecer idénticas desde el espacio de usuario.
4. /etc/pve de Proxmox no es “un directorio” en el sentido normal. Es una tienda de configuración distribuida expuesta como sistema de archivos vía FUSE (pmxcfs).
5. Las reglas de cuórum son anteriores a Proxmox: los sistemas distribuidos llevan décadas usando votación por mayoría para evitar split-brain. Proxmox solo lo hace dolorosamente visible.
6. ZFS trata la corrupción silenciosa como un enemigo de primera clase; el modelo de checksum extremo a extremo es la razón por la que ops lo adoran—y por qué puede ponerse estricto cuando los dispositivos fallan.
7. SMART no fue diseñado para predicción perfecta; es más bien “pronóstico meteorológico para discos”. Aun así útil, pero no mágico.
8. Los cachés de escritura cambiaron el juego de fallos: los SSD modernos y controladores pueden reconocer escrituras antes de que sean duraderas. Sin protección contra pérdida de energía, es un impuesto en integridad que pagas después.
9. Los sistemas de archivos FUSE pueden volverse “solo lectura” por razones no relacionadas con discos, porque el daemon puede decidir rechazar escrituras cuando su modelo de consistencia está amenazado.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son las tareas que realmente ejecuto cuando un nodo Proxmox empieza a negarse a aceptar escrituras. Cada tarea incluye: comando, qué significa la salida y qué decides después.

Tarea 1: Demuestra qué montaje está en solo lectura

cr0x@server:~$ mount | egrep ' on / | on /var | on /etc/pve |type zfs|type ext4|type xfs'
/dev/mapper/pve-root on / type ext4 (ro,relatime,errors=remount-ro)
/dev/fuse on /etc/pve type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)

Significado: root está montado (ro,...). /etc/pve sigue en rw.

Decisión: trata esto como un problema del sistema de archivos del host, no de cuórum. Pasa a los logs del kernel y la salud del almacenamiento de inmediato.

Tarea 2: Intenta una escritura controlada en la ruta que falla

cr0x@server:~$ touch /root/.rw-test
touch: cannot touch '/root/.rw-test': Read-only file system

Significado: el error es real y viene del VFS/FS, no de permisos.

Decisión: detén las escrituras no esenciales (backups, tormentas de logs) y recopila evidencia antes de reiniciar.

Tarea 3: Lee los mensajes del kernel para encontrar el desencadenante

cr0x@server:~$ dmesg -T | tail -n 40
[Thu Dec 26 10:41:09 2025] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Thu Dec 26 10:41:09 2025] blk_update_request: I/O error, dev sda, sector 312492800 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 10:41:09 2025] EXT4-fs error (device dm-0): ext4_journal_check_start:83: Detected aborted journal
[Thu Dec 26 10:41:09 2025] EXT4-fs (dm-0): Remounting filesystem read-only

Significado: esto empezó como un error en la capa de bloques (dev sda) que luego provocó el aborto del journal de ext4 y el remount ro.

Decisión: asume problema en la ruta de hardware hasta demostrar lo contrario. Haz SMART, revisa cableado/controlador; evita fsck hasta que el dispositivo sea estable.

Tarea 4: Confirma el arranque actual y guarda logs persistentes

cr0x@server:~$ journalctl -k -b | egrep -i 'error|ext4|xfs|nvme|ata|timeout|reset|zfs|I/O' | tail -n 60
Dec 26 10:41:09 server kernel: blk_update_request: I/O error, dev sda, sector 312492800 op 0x1:(WRITE)
Dec 26 10:41:09 server kernel: EXT4-fs error (device dm-0): ext4_journal_check_start: Detected aborted journal
Dec 26 10:41:09 server kernel: EXT4-fs (dm-0): Remounting filesystem read-only

Significado: misma historia que en dmesg, pero ahora en el journal (útil después de reiniciar).

Decisión: procede con las comprobaciones de salud del dispositivo; planifica una ventana de mantenimiento si el disco subyacente está fallando.

Tarea 5: Identifica la pila de dispositivos de bloque (dm-0 → LVM → disco físico)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,UUID
NAME           TYPE   SIZE FSTYPE      MOUNTPOINTS                UUID
sda            disk  1.8T
├─sda1         part  1007K
├─sda2         part     1G vfat        /boot/efi                 2B1A-9C3D
└─sda3         part   1.8T LVM2_member                          1dGk2A-...
  ├─pve-root   lvm     96G ext4        /                         4d9a7a0e-...
  ├─pve-swap   lvm      8G swap        [SWAP]                    0f19...
  └─pve-data   lvm    1.7T LVM2_member
    └─pve-vm--data-lvpool lvm 1.7T

Significado: el sistema de archivos root reside en el volumen lógico LVM pve-root respaldado por sda3.

Decisión: comprueba primero el disco físico (/dev/sda). Una pila LVM bonita no salvará un disco moribundo.

Tarea 6: Comprueba el estado SMART (SATA/SAS) para “este disco me está mintiendo?”

cr0x@server:~$ smartctl -a /dev/sda
SMART overall-health self-assessment test result: FAILED!
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always   FAILING_NOW 2048
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       128
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       128

Significado: este disco no está “degradado”, está fallando activamente. Sectores pendientes e incorrregibles se correlacionan fuertemente con errores I/O.

Decisión: deja de confiar en el dispositivo. Prioriza la evacuación de datos y el reemplazo. No ejecutes reparaciones intensivas en escritura salvo que sea imprescindible.

Tarea 7: Salud NVMe (si arrancas desde NVMe)

cr0x@server:~$ nvme smart-log /dev/nvme0
critical_warning                    : 0x00
media_errors                        : 12
num_err_log_entries                 : 58
percentage_used                     : 87%

Significado: alto desgaste (percentage_used) y errores de medios registrados. No es automáticamente fatal, pero tampoco para ignorar.

Decisión: programa el reemplazo y revisa firmware/temperatura. Si el sistema de archivos ya remonteó ro, trátalo como urgente.

Tarea 8: Comprueba si /etc/pve es lo que está en solo lectura (detección de cuórum)

cr0x@server:~$ touch /etc/pve/.pmxcfs-test
touch: cannot touch '/etc/pve/.pmxcfs-test': Read-only file system

Significado: pmxcfs está rechazando escrituras (a menudo por cuórum, a veces por problemas de pmxcfs).

Decisión: haz comprobaciones de clúster, no de disco, a menos que otros montajes también fallen.

Tarea 9: Salud del clúster y cuórum

cr0x@server:~$ pvecm status
Quorum information
------------------
Date:             Thu Dec 26 11:02:18 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          No

Significado: no hay cuórum. Proxmox protegerá las escrituras de configuración del clúster.

Decisión: arregla la red de corosync / trae los nodos de vuelta / ajusta los votos esperados para operar en emergencia (con cuidado). No intentes “chmod”ar la salida.

Tarea 10: Comprueba servicios pmxcfs / corosync

cr0x@server:~$ systemctl status pve-cluster corosync --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Active: active (running)
● corosync.service - Corosync Cluster Engine
     Active: active (running)

Significado: los servicios están activos, pero el cuórum aún puede estar perdido. No confundas “activo” con “saludable”.

Decisión: soluciona conectividad y votos; valida pvecm status de nuevo después de los cambios.

Tarea 11: Comprobación rápida de ZFS (si usas ZFS)

cr0x@server:~$ zpool status -x
pool 'rpool' is DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
action: Replace the device using 'zpool replace'.

Significado: un miembro del vdev desapareció o es ilegible. En pools mirror/raidz podrías seguir funcionando, pero estás en tiempo prestado.

Decisión: identifica el dispositivo faltante, revisa cableado/backplane y reemplaza. Si I/O está suspendido, prioriza limpiar esa condición con seguridad.

Tarea 12: Estado detallado de ZFS con errores y mapeo de dispositivos

cr0x@server:~$ zpool status -v rpool
  pool: rpool
 state: DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
config:

        NAME                        STATE     READ WRITE CKSUM
        rpool                       DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       UNAVAIL      0     0     0  cannot open

errors: No known data errors

Significado: un miembro del mirror desapareció. Aún no hay errores de checksum, pero la resiliencia quedó reducida a cero redundancia.

Decisión: trátalo como un incidente. Encuentra por qué el dispositivo está UNAVAIL (¿reset del HBA? ¿backplane? ¿SSD muerto?). Reemplaza y luego realiza un scrub.

Tarea 13: Busca un evento ZFS de “I/O suspendido” en los logs

cr0x@server:~$ journalctl -k -b | egrep -i 'zfs|suspend|zio|I/O' | tail -n 40
Dec 26 10:55:01 server kernel: ZFS: vdev IO failure, zio pipeline stalled
Dec 26 10:55:01 server kernel: ZFS: pool rpool has encountered an uncorrectable I/O failure and has been suspended.

Significado: ZFS suspendió el pool para prevenir más daños. Las escrituras pueden fallar o colgar.

Decisión: detén las escrituras de VM/CT, asegura la ruta de hardware y luego limpia/reemplaza según corresponda. Reinicios sin arreglar hardware pueden producir bucles.

Tarea 14: Detecta rápidamente “está lleno”

cr0x@server:~$ df -hT /
Filesystem          Type  Size  Used Avail Use% Mounted on
/dev/mapper/pve-root ext4   94G   94G     0 100% /

Significado: root está lleno. Esto por sí solo no debería remountar ro, pero causará fallos generalizados de escritura.

Decisión: libera espacio de forma segura (limpieza de logs, eliminar kernels antiguos, podar caches), y luego reevalúa. Si también ves errores ext4, el disco lleno puede ser un síntoma (por ejemplo, spam de logs por hardware fallando).

Tarea 15: Confirma la política de errores de ext4 y las opciones de montaje

cr0x@server:~$ tune2fs -l /dev/mapper/pve-root | egrep -i 'Filesystem state|Errors behavior|Last error'
Filesystem state:         clean
Errors behavior:          Remount read-only
Last error time:          Thu Dec 26 10:41:09 2025

Significado: ext4 está configurado para remount ro en errores; la hora del último error coincide con el incidente.

Decisión: planifica un fsck fuera de línea después de estabilizar hardware. No “arregles” cambiando la política de errores; eso es como quitar las pilas del detector de humo porque el pitido te molesta.

Tarea 16: Confirma detalles de apagado forzado de XFS (si es XFS)

cr0x@server:~$ journalctl -k -b | egrep -i 'xfs|shutdown|metadata|corrupt' | tail -n 40
Dec 26 10:39:12 server kernel: XFS (dm-0): Corruption detected. Unmount and run xfs_repair
Dec 26 10:39:12 server kernel: XFS (dm-0): xfs_do_force_shutdown(0x2) called from xfs_reclaim_inodes+0x2b0/0x2f0

Significado: XFS detectó corrupción y forzó un apagado para evitar más daños.

Decisión: programa una ventana de mantenimiento para desmontar y ejecutar xfs_repair (a menudo desde modo rescue). De nuevo: verifica hardware primero.

Ese es el núcleo del diagnóstico. Ahora hablemos de recuperación sin empeorar las cosas.

Recuperación por pila de almacenamiento: ext4/XFS, ZFS, LVM, pmxcfs

Caso A: ext4 root o sistema de datos remountado en solo lectura

ext4 pasa a solo lectura cuando detecta inconsistencia interna (a menudo desencadenado por errores I/O). Tus prioridades:

1. Detener servicios con alta escritura para reducir churn.
2. Capturar logs (kernel y syslog).
3. Confirmar salud del almacenamiento subyacente (SMART, reinicios en dmesg).
4. Reparar fuera de línea (fsck) después de que puedas confiar en la capa de bloques.

Intentar remount en lectura-escritura (solo como medida temporal)

Si el kernel remonteó ro por errores de ext4, remount rw puede fallar—o tener éxito brevemente y volver a fallar. Trátalo como “obtén logs y copia configuraciones críticas”, no como “reanudar operaciones normales”.

cr0x@server:~$ mount -o remount,rw /
mount: /: cannot remount /dev/mapper/pve-root read-write, is write-protected.

Significado: el kernel está rechazando rw porque el sistema de archivos está en estado de error.

Decisión: necesitas reparación fuera de línea. No luches contra el kernel. Ganará él y perderás datos.

Prepárate para fsck fuera de línea (enfoque relativamente seguro)

Normalmente no puedes fsckear el sistema raíz montado. Planea arrancar en un entorno de rescate o en modo single-user con root desmontado.

En términos de Proxmox eso suele ser: arrancar desde ISO/medio virtual IPMI, o usar la recuperación de grub si sabes lo que haces.

Una vez en rescue, ejecuta:

cr0x@server:~$ fsck.ext4 -f -y /dev/mapper/pve-root
e2fsck 1.47.0 (5-Feb-2023)
/dev/mapper/pve-root: recovering journal
/dev/mapper/pve-root: Clearing orphaned inode 131082
/dev/mapper/pve-root: FIXED.

Significado: el journal se recuperó; inodos huérfanos fueron corregidos; fsck reporta reparaciones.

Decisión: reinicia y vigila los logs. Si los errores se repiten, la ruta de disco sigue fallando o tienes problemas de RAM/controlador.

Cuando fsck no es el primer paso correcto

Si SMART falla o dmesg muestra reinicios/timeouts, fsck puede acelerar la falla debido a lecturas/escrituras intensivas. En ese caso:

• Imagina/copia lo que puedas (discos de VM, configuraciones) a un dispositivo sano.
• Reemplaza hardware.
• Después repara si es necesario.

Caso B: XFS forzó el apagado

La reparación de XFS es xfs_repair. Debe ejecutarse con el sistema de archivos desmontado. Si es el root, estarás otra vez en rescue.

cr0x@server:~$ xfs_repair /dev/mapper/pve-root
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
Phase 7 - verify and correct link counts...
done

Significado: el log fue reseteado y se corrigió metadata.

Decisión: reinicia y luego realiza una comprobación de carga. Si la corrupción se repite, frecuentemente es hardware (RAM, controlador, disco) y no que XFS sea frágil.

Caso C: Problemas en pool ZFS (degradado, faulted, I/O suspendido)

ZFS no se anda con rodeos. Si piensa que no puede asegurar escrituras, puede suspender I/O. Ahí es cuando Proxmox empieza a actuar como poseído: discos de VM cuelgan, tareas no se completan y tienes timeouts por todas partes.

Paso 1: estado, no adivinar

cr0x@server:~$ zpool status -v
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
errors: Permanent errors have been detected in the following files:
        rpool/data/vm-101-disk-0

Significado: tienes errores permanentes afectando un disco de VM. ZFS te dice que no pudo reparar desde redundancia.

Decisión: detén esa VM, restaura desde backup/replica. No “haz el scrub con más ganas”. Scrub no inventa bits faltantes.

Paso 2: reemplaza dispositivo faltante/faulted (ejemplo)

cr0x@server:~$ zpool replace rpool ata-SAMSUNG_SSD_2 /dev/disk/by-id/ata-SAMSUNG_SSD_NEW

Significado: ZFS comienza a resilver hacia el nuevo dispositivo.

Decisión: monitoriza el progreso del resilver y la carga del sistema. Si esto es producción, quizá quieras pausar migraciones y backups pesados.

Paso 3: limpiar errores después de arreglar hardware

cr0x@server:~$ zpool clear rpool

Significado: limpia conteos de errores; no “repara” datos por sí solo.

Decisión: ejecuta un scrub para validar y reparar desde redundancia.

Paso 4: scrub e interpretar resultados

cr0x@server:~$ zpool scrub rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
scan: scrub repaired 0B in 00:12:31 with 0 errors on Thu Dec 26 12:03:44 2025

Significado: scrub no encontró errores (bueno). Si reparó datos, verías bytes reparados; si no pudo reparar, verías errores.

Decisión: si los errores persisten: revisa cableado/HBA y considera pruebas de memoria (ZFS muestra problemas de RAM claramente).

Caso D: Problemas de LVM o device-mapper causando comportamiento solo lectura

A veces el sistema de archivos es inocente; el dispositivo de bloque subyacente cambia a estado de error. Comprueba mensajes de dm y LVM:

cr0x@server:~$ dmsetup info -C
Name             Maj Min Stat Open Targ Event  UUID
pve-root         252   0 L--w   1    1      0  LVM-...

Significado: las banderas en Stat pueden dar pistas (esto varía). Más importante, combínalo con logs del kernel para “device mapper: thin: …” o “I/O error on dm-0”.

Decisión: si metadata de thin-pool está llena o corrupta, necesitarás arreglos específicos de LVM-thin y probablemente downtime. No improvises.

Caso E: /etc/pve es solo lectura (pmxcfs / cuórum)

Esta es la trampa clásica de Proxmox: todo lo demás es escribible, pero no puedes editar una configuración de VM, la configuración de almacenamiento o añadir un nodo. El error dice solo lectura. La gente culpa a los discos. Mientras tanto, el clúster simplemente no tiene cuórum.

Confirma montaje de pmxcfs y cuórum

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

cr0x@server:~$ pvecm status | egrep 'Quorate|Nodes|Expected votes|Total votes'
Nodes:            2
Expected votes:   3
Total votes:      2
Quorate:          No

Significado: el montaje pmxcfs dice rw, pero el estado del clúster no es quórum; Proxmox seguirá rechazando escrituras de configuración.

Decisión: restaura cuórum trayendo nodos de nuevo o arreglando la red de corosync. Solo cambia votos esperados si entiendes las implicaciones de split-brain.

Emergencia: ajustar expected votes (usar con respeto)

cr0x@server:~$ pvecm expected 2

Significado: indicas a corosync que espere menos votos para que los nodos restantes puedan ser quorate.

Decisión: haz esto solo cuando estés seguro de que los nodos ausentes no volverán y no escribirán configuraciones divergentes. Es una palanca para recuperar producción, no una comodidad diaria.

Broma #2: El cuórum es la reunión corporativa donde nada se aprueba a menos que suficiente gente aparezca, y de alguna forma eso sigue siendo mejor que el caos.

Tres micro-historias de la vida corporativa

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

El equipo vio “Read-only file system” mientras editaban una configuración de VM. Naturalmente, culparon al SSD de arranque. Alguien abrió un ticket de cambio para reemplazar la unidad. Mientras tanto, el nodo seguía sirviendo VMs sin problema y SMART estaba limpio.

Un administrador sénior intentó crear un archivo en /tmp y funcionó. Hicieron lo mismo en /etc/pve y falló. Ese detalle debería haber terminado el debate, pero la suposición ya estaba arraigada: “solo lectura significa disco”.

Finalmente ejecutaron pvecm status y encontraron que el clúster no era quórum tras un cambio de red: el tráfico de corosync iba por la misma interfaz bondada que una VLAN de backups ruidosa, y la pérdida de multicast/UDP hacía que la pertenencia fluctuara. pmxcfs protegió el estado del clúster rechazando escrituras. Exactamente para lo que fue diseñado.

La solución fue aburrida: mover corosync a su propia VLAN y verificar MTU y pérdida de paquetes de extremo a extremo. No fue necesario cambiar discos. La mejor línea del postmortem fue la más simple: “tratamos un problema de sistema distribuido como si fuera un disco”. Esa es la suposición equivocada en una frase.

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

Un equipo de virtualización quiso almacenamiento más rápido para VMs. Habilitaron caché de escritura agresiva en un controlador RAID y, para más seguridad, deshabilitaron barriers porque “tenemos batería”. Los benchmarks quedaron bonitos. Todos aplaudieron. Alguien puso los gráficos en una presentación, lo sabes, es serio.

Meses después, un evento de mantenimiento causó una breve perturbación de energía. La batería del caché del RAID existía pero no estaba realmente sana; había estado reportando advertencias que nadie miró. El controlador reconoció escrituras que no eran durables, y tras el reinicio, el sistema de archivos del host apareció con problemas de journal. ext4 lo detectó y remonteó root en solo lectura durante el arranque.

La recuperación fue desagradable: arranque en rescue, fsck y luego días persiguiendo síntomas sutiles de corrupción a nivel de VM. No todo se perdió, pero la confianza sí. La “optimización” ahorró milisegundos y costó fines de semana.

El cambio duradero no fue tuning de rendimiento; fue gobernanza: cualquier cambio que afecte al orden de escritura necesitaba un modelo explícito de pérdida de energía y monitorización del estado de la batería/flash del controlador. La velocidad está bien. La velocidad con mentiras es cómo consigues desarrollo de carrera no pedido.

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

Otra organización ejecutaba Proxmox sobre mirrors ZFS, mantenía scrubs semanales y hacía algo profundamente poco glamoroso: probaban restauraciones. No una vez. Regularmente. Los backups no eran “una casilla”, eran parte del ritmo operativo.

Una mañana, un nodo empezó a registrar errores de media NVMe. ZFS informó un dispositivo inestable, pero el pool siguió en línea gracias al mirroring. El equipo no esperó a un fallo heroico. Migraron las VMs más activas fuera del nodo, reemplazaron el NVMe y resilverizaron.

Durante el resilver, un disco de VM mostró un error permanente en un bloque específico. Ese es el titular de pesadilla, excepto que no lo fue. Pararon la VM, restauraron desde el backup de la noche anterior y siguieron. El downtime se limitó a una carga y el radio del desastre se mantuvo pequeño.

La jugada salvadora no fue un comando ingenioso. Fue la memoria muscular practicada: scrub, monitorizar, migrar, reemplazar, restaurar. Sin drama. Sin arqueología nocturna en dmesg. Lo aburrido ganó porque lo aburrido estaba preparado.

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

1) “No puedo editar configuración de VM” → problema pmxcfs/cuórum → arreglar cuórum del clúster

• Síntomas: las escrituras fallan solo bajo /etc/pve; las VMs siguen corriendo; las comprobaciones de disco están bien.
• Causa raíz: clúster no quórum, o inestabilidad de corosync.
• Solución: pvecm status, restaura conectividad de nodos; en emergencias, ajusta votos esperados deliberadamente. Luego valida escrituras en /etc/pve.

2) Root filesystem pasó a ro tras errores I/O → disco/cable/HBA moribundo → arreglar ruta de hardware primero

• Síntomas: blk_update_request, timeouts, reinicios ATA, reinicios NVMe; aborto del journal ext4.
• Causa raíz: ruta de dispositivo de bloque inestable.
• Solución: logs SMART/NVMe; reseat/reemplazar cable; actualizar firmware; reemplazar dispositivo. Solo entonces fsck/repair.

3) Pool ZFS “suspendido” → errores repetidos de dispositivo → detener escrituras, reemplazar, clear, scrub

• Síntomas: tareas cuelgan; logs ZFS muestran pool suspendido; zpool status muestra UNAVAIL/FAULTED.
• Causa raíz: ZFS encontró I/O incorrregible y suspendió para proteger la consistencia.
• Solución: estabiliza hardware; reemplaza vdev fallado; zpool clear; scrub. Restaura discos de VM afectados si hay errores permanentes.

4) “Solo lectura” pero en realidad disco lleno → crecimiento de logs/backups → liberar espacio, arreglar la fuente

• Síntomas: escrituras fallan; df -h muestra 100%; logs enormes.
• Causa raíz: sistema de archivos lleno o agotamiento de inodos.
• Solución: elimina grandes ofensores (/var/log, ISOs antiguas, kernels viejos), rota logs, mueve backups y añade umbrales de monitorización.

5) Bucle de reparación: fsck “arregla” pero vuelve ro → errores subyacentes continúan → para y arregla la raíz

• Síntomas: después de reinicio/reparación, en horas vuelve a montarse ro.
• Causa raíz: hardware fallando, RAM defectuosa, controlador inestable o problemas de energía.
• Solución: diagnóstico de hardware, memtest en ventana de mantenimiento, actualizaciones de firmware y revisión de la ruta de energía (PSU/UPS).

6) Intentar forzar rw en producción → más corrupción → acepta downtime y repara correctamente

• Síntomas: recuperación intermitente con mount -o remount,rw, luego errores empeoran.
• Causa raíz: tratar el síntoma; ignorar la protección de integridad.
• Solución: toma outage, repara fuera de línea, restaura desde backup si es necesario. No negocias con la física.

Listas de verificación / plan paso a paso

Checklist A: Cuando el sistema raíz del host Proxmox está en solo lectura

1. Estabilizar: pausa tareas intensivas. Si hay VMs corriendo, detén backups/migraciones. Evita tormentas de logs.
2. Identificar montajes: confirma qué montaje está ro (mount, findmnt).
3. Recopilar evidencia: dmesg -T, journalctl -k -b, guarda copias fuera del host si es posible.
4. Comprobar salud del almacenamiento: smartctl o nvme smart-log; anota reinicios/timeouts.
5. Decidir:
   • Si el hardware está enfermo: evacua datos y reemplaza hardware.
   • Si el hardware está limpio: planifica fsck/xfs_repair fuera de línea.
6. Reparar fuera de línea: arranca rescue, ejecuta la herramienta de reparación del sistema de archivos, reinicia.
7. Validar: vigila logs por recurrencia; ejecuta una carga controlada; agenda seguimiento.

Checklist B: Cuando solo /etc/pve actúa como solo lectura

1. Verificar alcance: prueba de escritura en /tmp y /etc/pve.
2. Comprobar cuórum: pvecm status.
3. Comprobar salud de corosync: pérdida de paquetes, VLAN, consistencia de MTU, modo de bonding, configuración de switches.
4. Recuperar cuórum: trae nodos de vuelta, arregla la red. Usa expected votes solo como palanca de emergencia.
5. Validar: crea/edita un cambio de configuración inocuo (o toca un archivo) bajo /etc/pve.

Checklist C: Cuando ZFS está molesto (degradado/suspendido/errores)

1. Obtener estado: zpool status -v y captura la salida.
2. Detener el daño: pausa escrituras de VM si el pool está suspendido o lanzando errores.
3. Confirmar mapeo de dispositivos: mapa by-id a bahía física; revisa logs del HBA/backplane.
4. Reemplazar/arreglar dispositivo: reseat, reemplaza, zpool replace según corresponda.
5. Clear y scrub: zpool clear, luego zpool scrub.
6. Tratar errores permanentes: restaura discos de VM afectados desde backup/replica; no finjas que no pasó.

Un principio operativo único (vale la pena memorizar)

“Reparar” no es una meta; “recuperar el servicio sin corromper datos” sí lo es. Muchos incidentes malos ocurren porque alguien optimizó para lo primero.

Una cita, porque es lo más parecido a una escritura sagrada que tiene nuestro campo:

“La esperanza no es una estrategia.” — Gen. Gordon R. Sullivan

Preguntas frecuentes

1) ¿Por qué Linux remonta ext4 en solo lectura en lugar de colapsar?

Porque continuar escribiendo tras la corrupción de metadatos puede hacer la recuperación imposible. Remontar en solo lectura es una medida de contención: preservar lo que aún es consistente.

2) ¿Puedo simplemente ejecutar mount -o remount,rw / y seguir?

A veces funciona brevemente. Si el kernel marcó errores de ext4, a menudo no permitirá el remount. Incluso si funcionara, estarías escribiendo sobre un sistema de archivos que ya admitió que no puede garantizar la consistencia. Usa remount rw solo para extraer datos o logs, no como “solución”.

3) Si /etc/pve está en solo lectura, ¿significa eso que mi disco está roto?

No necesariamente. pmxcfs puede bloquear escrituras por pérdida de cuórum o problemas de estado del clúster. Prueba escrituras en otro sitio (como /tmp) y luego revisa pvecm status.

4) ¿Cuál es la forma más rápida de distinguir “problema de cuórum” vs “problema de disco”?

Si solo falla /etc/pve y el resto del sistema es escribible, suele ser cuórum/pmxcfs. Si root o /var está en ro, normalmente es sistema de archivos/hardware. Confirma con mount y pvecm status.

5) ZFS dice “permanent errors”. ¿Puede scrub arreglar eso?

No. “Permanent errors” significa que ZFS no pudo reconstruir los datos desde la redundancia. Necesitas restaurar el archivo/volumen afectado desde backup o réplica.

6) El SMART del disco parece bien, pero ext4 igual remonteó ro. ¿Qué más puede ser?

SMART puede no detectar fallos transitorios o fallos a nivel de ruta. Busca reinicios SATA/NVMe, errores de controlador, cables/backplanes defectuosos, problemas de energía y (ocasionalmente) RAM defectuosa.

7) ¿Debo reiniciar inmediatamente cuando veo solo lectura?

No a ciegas. Primero recopila logs (dmesg, journalctl) y comprueba el alcance del fallo. Reiniciar puede borrar la mejor evidencia, y si el hardware está fallando puede convertir un sistema cojeante en uno muerto.

8) ¿Cómo evito que esto vuelva a suceder?

No puedes prevenir todos los fallos. Reducirás las sorpresas y el radio del desastre: monitoriza errores SMART/NVMe, vigila dmesg por reinicios, mantén espacio libre, ejecuta scrubs ZFS, prueba backups y aísla la red de corosync.

9) ¿Es ext4 o ZFS “mejor” para evitar incidentes de solo lectura?

Fallas de forma diferente. ext4 suele remountar ro al detectar errores; ZFS suele seguir hasta que no puede y luego se pone estricto (suspende I/O) y te da diagnósticos excelentes. Elige según tu madurez operativa: ZFS recompensa disciplina; ext4 es más simple pero menos auto-descriptivo.

Siguientes pasos que realmente debes tomar

Si estás en medio del incidente ahora mismo:

1. Ejecuta el guion de diagnóstico rápido: identifica el montaje, lee logs del kernel, decide “almacenamiento vs sistema de archivos vs cuórum”.
2. Si ves errores I/O: considera al hardware culpable hasta demostrar lo contrario. Recupera logs SMART/NVMe y planifica reemplazo.
3. Si es metadata ext4/XFS: programa una ventana de reparación fuera de línea. No “remount y reza”.
4. Si es /etc/pve: restaura cuórum. Arregla la red de corosync. No reemplaces discos para solucionar un problema de votos.
5. Si es ZFS: interpreta zpool status -v literalmente. Reemplaza dispositivos malos, scrub y restaura lo que tenga errores permanentes.

Luego, después de recuperar el servicio, haz el trabajo poco glamuroso: añade monitorización de errores I/O y reinicios de dispositivo, alerta por desgaste de disco/medios, aplica umbrales de espacio libre en / y /var, y trata a corosync como el plano de control que es. La producción no premia héroes. Premia sistemas que fallan de forma predecible y se recuperan rápido.