1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 1. Clase del OSD. Si ya tiene una (hdd/ssd/nvme automática), quítala primero: Ceph no la pisa
ceph osd crush rm-device-class osd.5
ceph osd crush set-device-class sas osd.5

# 2. Regla que solo coloca datos en esa clase (root "default", dominio de fallo "host")
ceph osd crush rule create-replicated replicated_sas default host sas

# 3. Pool nuevo sobre la regla, dado de alta como storage en Proxmox
pveceph pool create vm-sas --crush_rule replicated_sas --add_storages 1

# ...o mover un pool que ya existe (reequilibra todos sus datos)
pveceph pool set vm-fast --crush_rule replicated_sas

Por qué

La regla por defecto de Ceph (replicated_rule) reparte objetos entre todos los OSD sin mirar qué disco hay debajo. En un clúster mixto eso significa que el pool “rápido” también cae en los discos lentos y rinde como el peor de ellos.

Desde Luminous cada OSD lleva una device class. Ceph la detecta sola al arrancar (hdd, ssd o nvme) y una CRUSH rule puede limitarse a una clase: internamente crea una jerarquía sombra (default~sas) con solo esos OSD y coloca ahí todo el pool. La clase es una etiqueta libre: además de las automáticas puedes usar sas, sata, archive o lo que te sirva para separar.

Ver el estado

1
2
3
4
5
6
7

ceph osd tree                        # columna CLASS por OSD
ceph osd crush class ls              # clases que existen
ceph osd crush class ls-osd sas      # OSD de una clase
ceph osd crush tree --show-shadow    # las jerarquías sombra default~<clase>
ceph osd crush rule ls
ceph osd crush rule dump replicated_sas
ceph osd pool ls detail              # crush_rule <id> de cada pool

Cambiar la clase de un OSD

Si el OSD ya tiene clase, set-device-class no la sobrescribe:

1
2

Error EBUSY: osd.5 has already bound to class 'hdd', can not reset class to 'sas';
use 'ceph osd crush rm-device-class <id>' to remove old class first

De ahí el rm-device-class previo. Varios OSD de una vez:

1
2

ceph osd crush rm-device-class osd.5 osd.6 osd.7
ceph osd crush set-device-class sas osd.5 osd.6 osd.7

No existe un paso de “crear la clase”: el ceph osd crush class create de las primeras versiones de Luminous se eliminó, y la clase aparece con el primer OSD que la recibe. Para renombrarla en todo el clúster, ceph osd crush class rename sas sas-10k.

Una clase asignada a mano sobrevive a los reinicios del OSD: al arrancar, el OSD intenta poner su clase automática y recibe el mismo EBUSY. Si prefieres que los OSD nuevos nazcan sin clase para asignarla tú, ceph config set osd osd_class_update_on_start false; a cambio, ningún OSD nuevo tendrá clase automática.

La regla

1
2
3

ceph osd crush rule create-replicated <nombre> <root> <dominio-de-fallo> <clase>
ceph osd crush rule create-replicated replicated_sas default host sas
ceph osd crush rule create-replicated replicated_nvme default host nvme

• root es default salvo que hayas montado tu propio árbol CRUSH.
• host como dominio de fallo pone cada réplica en un nodo distinto. Con size 3 necesitas al menos tres nodos con OSD de esa clase, o los PG se quedan undersized.
• Para pools erasure-coded la clase va en el perfil: pveceph pool create ec-sas --erasure-coding k=4,m=2,device-class=sas.

El pool

Nuevo, con storage de Proxmox incluido:

1

pveceph pool create vm-sas --crush_rule replicated_sas --size 3 --min_size 2 --add_storages 1

Existente: pveceph pool set vm-fast --crush_rule replicated_sas, o en la GUI Ceph → Pools → Edit → Crush Rule. Es lo mismo que ceph osd pool set vm-fast crush_rule replicated_sas. El cambio dispara un backfill de todo el pool hacia los OSD de la clase; hazlo en ventana de mantenimiento y síguelo con ceph -s.

Trampas

• Cuenta los OSD antes de la regla. Tres nodos, size 3, y solo dos con discos sas: el pool nunca llega a active+clean.
• Las clases automáticas se equivocan con controladoras RAID/HBA que presentan SSD como rotacionales. Revisa ceph osd tree después de añadir discos y corrige con rm-device-class + set-device-class.
• Mover un pool grande de regla es mover todos sus datos. Sube osd_max_backfills solo si sabes lo que haces; por defecto va lento a propósito.
• Borrar un pool que se resiste: pveceph pool destroy <pool> --force --remove_storages (los datos se van con él).

Ver también

• Ceph en Proxmox: crashes y discos huérfanos
• Repositorios sin suscripción — incluye el repo de Ceph
• Documentación de Ceph: CRUSH Maps — Device classes

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

PVE 9 (Debian 13 trixie, formato deb822):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

cat > /etc/apt/sources.list.d/proxmox.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

# Apagar enterprise (sin suscripción devuelve 401 en cada apt update)
grep -q '^Enabled:' /etc/apt/sources.list.d/pve-enterprise.sources \
  || echo 'Enabled: false' >> /etc/apt/sources.list.d/pve-enterprise.sources

apt update && apt full-upgrade

PVE 8 (Debian 12 bookworm, formato de una línea):

1
2
3
4
5

echo 'deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription' \
  > /etc/apt/sources.list.d/pve-no-subscription.list
sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list

apt update && apt full-upgrade

Si el host tiene Ceph, el repo enterprise de Ceph también hay que apagarlo y cambiarlo por su no-subscription (abajo).

Qué hace cada repositorio

Proxmox lo dice claro: pve-no-subscription es para pruebas y uso no productivo; en producción quieren que pagues la suscripción y uses enterprise. Para un lab o un homelab es el repo normal.

El 401 de enterprise no rompe nada por sí mismo, pero cada apt update termina con error y el resto de repos queda a medio refrescar. Apagarlo es el arreglo; no hace falta borrarlo.

PVE 9: archivos .sources (deb822)

Desde PVE 9 el instalador ya escribe /etc/apt/sources.list.d/pve-enterprise.sources en formato deb822. Un .sources es un bloque de claves:

1
2
3
4
5
6
7

# /etc/apt/sources.list.d/pve-enterprise.sources
Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
Enabled: false

Enabled: false lo deja escrito pero inactivo. El de no-subscription es el bloque del En corto; el de test es igual con Components: pve-test.

Si arrastras archivos .list de una actualización desde PVE 8, apt 3 los convierte solo:

1

apt modernize-sources

Reescribe cada .list como .sources y deja el original como .list.bak.

PVE 8: archivos .list

1
2
3
4
5

# /etc/apt/sources.list.d/pve-enterprise.list
# deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

# /etc/apt/sources.list.d/pve-no-subscription.list
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Comentar la línea enterprise con # equivale al Enabled: false de deb822.

Ceph

El instalador también deja el repo enterprise de Ceph. Mismo tratamiento; el nombre del repo lleva la versión de Ceph que corre el clúster (ceph -v):

PVE 9:

1
2
3
4
5
6

# /etc/apt/sources.list.d/ceph.sources
Types: deb
URIs: http://download.proxmox.com/debian/ceph-tentacle
Suites: trixie
Components: no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Cambia ceph-tentacle por ceph-squid si sigues en Squid. Si el archivo original tenía Components: enterprise, reemplázalo entero por este.

PVE 8:

1
2
3

# /etc/apt/sources.list.d/ceph.list
# deb https://enterprise.proxmox.com/debian/ceph-squid bookworm enterprise
deb http://download.proxmox.com/debian/ceph-squid bookworm no-subscription

En bookworm existen ceph-quincy, ceph-reef y ceph-squid; usa el que corresponda a tu clúster, no el más nuevo.

Proxmox Backup Server

Idéntico patrón con pbs en la URI y pbs-no-subscription como componente:

1
2
3
4
5
6

# /etc/apt/sources.list.d/proxmox.sources (PBS 4, trixie)
Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Y Enabled: false en pbs-enterprise.sources.

Trampas

• No mezcles suites. bookworm en PVE 8, trixie en PVE 9. Una línea con la suite equivocada rompe el siguiente full-upgrade.
• El keyring ya está. /usr/share/keyrings/proxmox-archive-keyring.gpg viene con cualquier instalación desde ISO. Solo hace falta descargarlo cuando instalas Proxmox encima de un Debian limpio (lo explica la guía oficial de esa vía).
• Signed-By es obligatorio en deb822; sin esa línea apt ignora el repo con un aviso.
• Si apt falla con pve-apt-hook: not found, no es un problema de repos: ese es otro post.
• El aviso de “no valid subscription” de la GUI es independiente de los repos y no se arregla aquí; una suscripción Community lo quita y de paso te da el repo enterprise.

Referencia: Package Repositories en la wiki de Proxmox.