1
2
3
4
5
6
7
8
9

# HEALTH_WARN: N daemons have recently crashed
ceph crash ls-new
ceph crash info <id>          # qué daemon, cuándo y el backtrace
ceph crash archive-all        # el aviso desaparece; el crash sigue en `ceph crash ls`

# Discos de VM que ya no existe
rbd ls -l cephpool
pvesm free cephpool:vm-124-disk-1     # por la capa de storage de Proxmox
rbd rm cephpool/vm-124-disk-1         # o directo en Ceph

HEALTH_WARN: daemons have recently crashed

1
2
3

HEALTH_WARN 1 daemons have recently crashed
[WRN] RECENT_CRASH: 1 daemons have recently crashed
    osd.5 crashed on host pve-node2 at 2026-09-20T03:14:07.123456Z

Es el chequeo RECENT_CRASH del módulo crash del manager: un daemon se cayó, dejó un reporte, y el aviso se queda hasta que un administrador lo archive, o hasta que pasen dos semanas (mgr/crash/warn_recent_interval). El daemon casi siempre ya volvió solo; el aviso no dice que siga caído.

Antes de archivar, mira qué fue:

1
2

ceph crash ls-new
ceph crash info 2026-09-20T03:14:07.123456Z_9f1c...

Del info importan entity_name (qué daemon), utc_timestamp, assert_msg o backtrace, y ceph_version. Después:

1
2
3
4
5

ceph osd stat                          # ¿siguen todos up/in?
systemctl status ceph-osd@5            # en el nodo del OSD
journalctl -u ceph-osd@5 --since '-1h'
dmesg -T | grep -iE 'sd[a-z]|nvme|i/o error'
smartctl -a /dev/sdX                   # si el crash coincide con errores de disco

Con eso decidido, archiva:

1
2
3

ceph crash archive <id>
ceph crash archive-all
ceph -s                                # HEALTH_OK si no hay nada más

Archivar no arregla nada; solo reconoce que lo viste. Si el mismo OSD reaparece en ls-new cada pocos días, es un disco o una controladora, no un aviso molesto: sácalo del clúster y reemplázalo.

Para limpiar el histórico: ceph crash rm <id> o ceph crash prune <días>. El aviso se puede apagar del todo con ceph config set mgr mgr/crash/warn_recent_interval 0, que es exactamente lo que no quieres en producción.

Discos de VM huérfanos en RBD

Aparecen cuando una VM se borra con el storage inaccesible, un clon o una migración fallan a medias, alguien borra el .conf a mano o queda una restauración incompleta. Ocupan espacio y no salen en la GUI porque ningún .conf los menciona.

Encontrarlos

Compara las imágenes del pool con los .conf de todos los nodos (en /etc/pve/nodes/ está la copia de cada uno):

1
2
3
4
5

for img in $(rbd ls cephpool); do
  grep -rqs "cephpool:$img" /etc/pve/nodes/*/qemu-server /etc/pve/nodes/*/lxc \
    || echo "sin dueño: $img"
done
rbd ls -l cephpool          # tamaños

pvesm list cephpool da la misma lista con el VMID que Proxmox deduce del nombre; útil para cruzar con qm list y pct list en cada nodo.

Si la VM sigue existiendo

Que Proxmox lo vuelva a ver y bórralo desde ahí:

1

qm rescan --vmid 124        # aparece como unused0 en el .conf

Luego GUI → Hardware → disco Unused → Remove, que sí borra la imagen, o pvesm free cephpool:vm-124-disk-1. Ojo: qm set 124 --delete unused0 solo lo quita del .conf, no borra datos.

Si la VM ya no existe

1
2
3

pvesm free cephpool:vm-124-disk-1
# equivalente directo en Ceph:
rbd rm cephpool/vm-124-disk-1

Cuando rbd rm se niega:

Trampas

• Cruza con todos los nodos, no con qm list del nodo donde estás; el disco de una VM que vive en otro nodo no es un huérfano.
• base-* no es basura: son las plantillas. Bórralas solo con qm destroy de la plantilla.
• El espacio vuelve despacio: ceph df tarda un rato en reflejar el borrado mientras los OSD eliminan objetos.
• Pool entero de sobra: pveceph pool destroy <pool> --force --remove_storages; se lleva todo lo que haya dentro.

Ver también

• Ceph: device classes y CRUSH rules
• VM is locked (snapshot-delete) — los snapshots RBD huérfanos aparecen ahí
• Documentación de Ceph: Health checks — RECENT_CRASH