Proxmox RBD «error opening»: errores de autenticación/keyring y soluciones

Qué significa realmente “error opening” en términos de Proxmox RBD

Cuando Proxmox muestra “RBD: error opening”, normalmente estás viendo un fallo que proviene de librbd (la biblioteca en espacio de usuario usada para acceder a imágenes RBD).
La librería intenta:

1. Cargar la configuración de Ceph (monitores, ajustes de auth, fsid, etc.).
2. Autenticarse (cephx) usando una clave para un ID de cliente (client.admin, client.pve, o un usuario personalizado).
3. Hablar con los monitores (MONs), obtener el mapa del cluster y localizar los OSDs.
4. Abrir la imagen RBD (lo que requiere permisos sobre el pool y la imagen).

“Error opening” se lanza comúnmente por:

• Keyring/clave incorrecta o faltante en la configuración de almacenamiento de Proxmox.
• Desajuste del ID de cliente: tienes la clave correcta, pero para un nombre de cliente diferente.
• Los caps no permiten la operación (caps de solo lectura pero estás creando imágenes; falta profile rbd; falta acceso a metadatos rbd_children, etc.).
• Monitores inaccesibles desde un nodo (ruteo, firewall, mon_host equivocado, confusión IPv6 vs IPv4).
• Diferencias en la configuración de Ceph entre nodos (un nodo tiene un /etc/ceph/ceph.conf obsoleto o fsid equivocado).
• Permisos del archivo keyring en disco: root puede leerlo, pero un proceso corre como otro usuario (común en herramientas personalizadas; menos común en Proxmox estándar).

La forma más rápida de dejar de adivinar es reproducir la operación de apertura exacta desde el nodo que falla usando la CLI rbd con el mismo ID y keyring.
Si rbd ls funciona pero rbd info pool/image falla, estás frente a un desajuste de caps. Si nada funciona, empieza por monitores + keyring.

Broma #1: “Error opening” es lo que Ceph dice cuando es demasiado educado para decir “tu keyring es basura.”

Guía rápida de diagnóstico (comprueba 1/2/3)

Este es el orden que termina incidentes más rápido. No el orden que resulta emocionalmente satisfactorio.

1) Confirma que puedes alcanzar los monitores y autenticarte desde el nodo que falla

• Si la conectividad al monitor o la autenticación cephx falla, nada más importa. Arregla eso primero.
• Usa ceph -s y ceph auth get client.X donde corresponda.

2) Confirma que Proxmox está usando el keyring que crees que usa

• Inspecciona /etc/pve/storage.cfg y la ruta keyring por almacenamiento (o la clave embebida).
• Valida que el archivo exista en cada nodo (la configuración de Proxmox es compartida, pero los archivos keyring son locales a menos que los gestiones).

3) Valida los caps contra el pool y la operación

• Lista los caps: ceph auth get client.pve.
• Prueba con comandos rbd que reflejen la acción con fallo: rbd ls, rbd info, rbd create, rbd snap ls.

4) Solo entonces: sigue los errores de la UI de Proxmox, logs de qemu y casos extremos

• Mira los logs de tareas y journalctl para pvedaemon, pveproxy y qemu-server.
• La mayoría de incidentes “error opening” son auth/caps/config. Los exóticos existen, pero no son tu primera hipótesis.

Datos interesantes y contexto (porque el pasado sigue en producción)

• El auth “cephx” de Ceph fue diseñado para evitar secretos compartidos por todo el cluster. Puedes acotar claves a pools y operaciones, por eso los caps importan tanto.
• La audiencia original de RBD fue plataformas cloud. El modelo “imagen + snapshot + clone” es muy orientado a VM, por eso Proxmox y OpenStack lo adoptaron temprano.
• Proxmox guarda la configuración del cluster en un sistema de archivos distribuido. /etc/pve se comparte entre nodos, pero archivos locales como /etc/ceph/ceph.client.pve.keyring no se replican mágicamente.
• Históricamente, muchas implementaciones usaron client.admin en todas partes. “Funciona” hasta que se convierte en una pesadilla de auditoría y amplificador de incidentes.
• La sintaxis de caps evolucionó con el tiempo. Entradas antiguas en blogs muestran patrones obsoletos; Ceph moderno prefiere profile rbd más el acotamiento explícito de pools.
• Los monitores de Ceph son una puerta de consistencia. Puedes tener OSDs saludables y aun así fallar aperturas RBD básicas si el quórum de MON o la accesibilidad están rotos desde un nodo.
• Abrir un RBD puede requerir operaciones de metadatos. Incluso las lecturas pueden requerir acceso a metadatos del pool (y, según características, a claves omap). “Le di solo lectura” puede resultar accidentalmente demasiado restrictivo.
• La detección de configuración de Ceph tiene múltiples rutas. Variables de entorno, rutas por defecto y flags explícitos pueden llevar a “funciona en mi shell” pero falla en tareas de Proxmox.

Síntomas comunes: qué verás y dónde

Proxmox puede mostrar el mismo fallo subyacente a través de varias capas. Aprende los patrones:

• Log de tareas de Proxmox: “rbd: error opening” durante creación/adjunto de disco, snapshot, migración o arranque de VM.
• Fallas de arranque de QEMU: La VM no arranca; los logs de qemu mencionan incapacidad para abrir la imagen RBD.
• Errores en CLI al mapear: rbd map devuelve “permission denied” o “error connecting to the cluster”.
• Pistas desde Ceph: Logs de MON muestran fallos de auth; logs de OSD muestran operaciones denegadas; pero en muchos casos Ceph permanece silencioso a menos que se suba el nivel de debug.
• Comportamiento específico por nodo: Un nodo Proxmox puede acceder a RBD; otro no. Eso indica “desajuste local de keyring/config”.

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

El objetivo de estas tareas es convertir errores vagos de la UI en decisiones claras. Ejecuta desde el nodo Proxmox que falla primero, luego desde un nodo conocido como bueno para comparar.

Task 1: Confirma que el cluster Ceph es accesible y no persigues ilusiones

cr0x@server:~$ ceph -s
  cluster:
    id:     2c3d1d5e-9a2e-4e2b-8a59-4f1c7c0c1c2f
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
    mgr: mgr1(active, since 2h)
    osd: 12 osds: 12 up (since 3h), 12 in (since 3h)

  data:
    pools:   4 pools, 256 pgs
    objects: 3.2M objects, 12 TiB
    usage:   36 TiB used, 72 TiB / 108 TiB avail
    pgs:     256 active+clean

Qué significa: Esto confirma que la CLI puede hablar con los monitores y autenticarse usando la configuración/clave por defecto que tu shell está usando.

Decisión: Si esto falla en el nodo roto pero funciona en otros, arregla la accesibilidad a monitores y la configuración local de Ceph antes de tocar Proxmox.

Task 2: Identifica qué piensa Proxmox que es tu almacenamiento RBD

cr0x@server:~$ grep -nE '^(rbd:|[[:space:]]*(pool|monhost|username|keyring|content))' /etc/pve/storage.cfg
12:rbd: ceph-rbd
13:        monhost 10.10.0.11 10.10.0.12 10.10.0.13
14:        pool vmdata
15:        username pve
16:        keyring /etc/ceph/ceph.client.pve.keyring
17:        content images,rootdir

Qué significa: Proxmox intentará conectar a esas IPs de monitores, autenticarse como client.pve, usando ese archivo keyring.

Decisión: Si falta keyring o apunta a un archivo que no existe en algunos nodos, encontraste la causa raíz.

Task 3: Verifica que el archivo keyring exista en este nodo y sea legible

cr0x@server:~$ ls -l /etc/ceph/ceph.client.pve.keyring
-rw------- 1 root root 151 Dec 26 10:41 /etc/ceph/ceph.client.pve.keyring

Qué significa: Existe y solo root puede leerlo, lo cual es normal en Proxmox.

Decisión: Si falta en un nodo, cópialo de forma segura o recréalo. Si los permisos están demasiado abiertos, corrígelos; secretos descuidados se convierten en incidentes.

Task 4: Confirma que el keyring contiene el nombre de cliente esperado

cr0x@server:~$ sed -n '1,120p' /etc/ceph/ceph.client.pve.keyring
[client.pve]
	key = AQB7qMdnJg0aJRAA7i9fJvQW9x0o0Jr8mGmNqA==
	caps mon = "profile rbd"
	caps osd = "profile rbd pool=vmdata"

Qué significa: El encabezado de sección debe coincidir con el nombre de usuario que Proxmox usa (sin el prefijo client. en storage.cfg).

Decisión: Si el archivo dice [client.admin] pero storage.cfg indica username pve, Proxmox fallará al autenticarse.

Task 5: Prueba acceso RBD explícitamente usando la misma identidad que Proxmox

cr0x@server:~$ rbd -p vmdata ls --id pve --keyring /etc/ceph/ceph.client.pve.keyring
vm-101-disk-0
vm-102-disk-0
base-9000-disk-0

Qué significa: La autenticación funciona y el usuario puede listar imágenes en el pool.

Decisión: Si el listado funciona pero Proxmox sigue dando error al abrir, el problema probablemente sea permisos específicos de la imagen/características de la imagen o un nombre de pool/imagen distinto al esperado.

Task 6: Reproduce la apertura en una imagen específica (más útil para “error opening”)

cr0x@server:~$ rbd info vmdata/vm-101-disk-0 --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd image 'vm-101-disk-0':
	size 100 GiB in 25600 objects
	order 22 (4 MiB objects)
	snapshot_count: 2
	id: 1a2b3c4d5e6f
	block_name_prefix: rbd_data.1a2b3c4d5e6f
	format: 2
	features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
	op_features:
	flags:
	create_timestamp: Tue Dec 24 09:12:33 2025
	access_timestamp: Tue Dec 24 09:12:33 2025
	modify_timestamp: Thu Dec 26 10:01:07 2025

Qué significa: Si esto tiene éxito, la apertura funciona a nivel RBD. Proxmox debería poder arrancar la VM salvo que esté usando credenciales/configuración distintas.

Decisión: Si falla con “permission denied”, tus caps son insuficientes para operaciones de metadatos o estás apuntando al pool equivocado.

Task 7: Confirma los caps del usuario cliente (no adivines)

cr0x@server:~$ ceph auth get client.pve
[client.pve]
	key = AQB7qMdnJg0aJRAA7i9fJvQW9x0o0Jr8mGmNqA==
	caps mon = "profile rbd"
	caps osd = "profile rbd pool=vmdata"

Qué significa: Esto es la verdad autoritativa dentro de Ceph (no lo que esté copiado en un archivo keyring).

Decisión: Si los caps no incluyen el pool objetivo, corrígelos. Si la clave difiere del keyring en disco, actualiza el archivo en todos los nodos.

Task 8: Revisa la configuración de Ceph que Proxmox usará implícitamente

cr0x@server:~$ cat /etc/ceph/ceph.conf
[global]
fsid = 2c3d1d5e-9a2e-4e2b-8a59-4f1c7c0c1c2f
mon_host = 10.10.0.11 10.10.0.12 10.10.0.13
auth_client_required = cephx
auth_cluster_required = cephx
auth_service_required = cephx

Qué significa: Un fsid equivocado o un mon_host faltante/incorrecto puede hacer que un nodo hable con el cluster equivocado o con ninguno.

Decisión: Si esto difiere entre nodos, estandarízalo. Una división de configuración es cómo obtienes “funcionó ayer” sin un cambio real.

Task 9: Confirma la accesibilidad a monitores desde el nodo que falla (ruteo/firewall)

cr0x@server:~$ for m in 10.10.0.11 10.10.0.12 10.10.0.13; do echo "== $m =="; nc -vz -w2 $m 3300; nc -vz -w2 $m 6789; done
== 10.10.0.11 ==
Connection to 10.10.0.11 3300 port [tcp/*] succeeded!
Connection to 10.10.0.11 6789 port [tcp/*] succeeded!
== 10.10.0.12 ==
Connection to 10.10.0.12 3300 port [tcp/*] succeeded!
Connection to 10.10.0.12 6789 port [tcp/*] succeeded!
== 10.10.0.13 ==
Connection to 10.10.0.13 3300 port [tcp/*] succeeded!
Connection to 10.10.0.13 6789 port [tcp/*] succeeded!

Qué significa: Ceph MON usa 3300 (msgr2) y a veces 6789 (legacy). Quieres conectividad al menos a lo que use tu cluster.

Decisión: Si esto falla solo en un nodo, arregla firewall/ruteo/VLAN/MTU. No “arregles” la auth para compensar una red rota.

Task 10: Saca el log de tarea de Proxmox que contiene el fallo

cr0x@server:~$ journalctl -u pvedaemon -S -2h | tail -n 40
Dec 26 10:50:14 pve3 pvedaemon[2211]:  starting task UPID:pve3:00008A1B:0002A1C4:676D7F46:qmstart:101:root@pam:
Dec 26 10:50:15 pve3 pvedaemon[1032]: command '/usr/bin/kvm -id 101 -name vm101 ... -drive file=rbd:vmdata/vm-101-disk-0:conf=/etc/pve/ceph.conf:id=pve:keyring=/etc/ceph/ceph.client.pve.keyring,if=none ...' failed: exit code 1
Dec 26 10:50:15 pve3 pvedaemon[1032]: TASK ERROR: start failed: error opening 'rbd:vmdata/vm-101-disk-0': (13) Permission denied

Qué significa: Esto confirma los argumentos exactos que QEMU usó, incluyendo id=pve y la ruta del keyring. Eso es oro.

Decisión: Vuelve a ejecutar el comando RBD equivalente manualmente con esos parámetros. Si falla, no es “un problema de Proxmox”.

Task 11: Verifica que Proxmox esté apuntando QEMU al ceph.conf correcto

cr0x@server:~$ ls -l /etc/pve/ceph.conf
-rw-r----- 1 root www-data 232 Dec 26 10:40 /etc/pve/ceph.conf

Qué significa: Proxmox puede generar/usar /etc/pve/ceph.conf. Esto puede diferir de /etc/ceph/ceph.conf.

Decisión: Si tus pruebas en CLI usan /etc/ceph/ceph.conf pero QEMU usa /etc/pve/ceph.conf, alínea ambos o prueba con el mismo --conf.

Task 12: Reprueba con el mismo archivo de configuración que QEMU usó

cr0x@server:~$ rbd --conf /etc/pve/ceph.conf -p vmdata ls --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd: listing images failed: (13) Permission denied

Qué significa: Esto lo acota. Tu éxito anterior pudo haber venido de una configuración distinta (cluster distinto, distinto mon_host, distintos ajustes de auth).

Decisión: Inspecciona /etc/pve/ceph.conf y arréglalo o deja de usarlo. La consistencia vence a la astucia.

Task 13: Confirma con qué cluster Ceph estás hablando (comprobación de fsid)

cr0x@server:~$ ceph --conf /etc/pve/ceph.conf fsid
2c3d1d5e-9a2e-4e2b-8a59-4f1c7c0c1c2f

Qué significa: Si el fsid difiere del cluster esperado, te estás autenticando contra el cluster equivocado (o un remanente de laboratorio).

Decisión: Arregla el archivo de configuración y reinicia los servicios afectados; no “añadas más mons” a ambos clusters y esperes que funcione.

Task 14: Corrige los caps para un cliente Proxmox RBD (patrón seguro típico)

cr0x@server:~$ ceph auth caps client.pve mon "profile rbd" osd "profile rbd pool=vmdata"
updated caps for client.pve

Qué significa: Estás otorgando permisos de monitor apropiados para RBD y permisos OSD acotados al pool. Es la configuración sensata por defecto para discos VM en un pool.

Decisión: Si tienes múltiples pools usados por Proxmox, añade cada pool explícitamente. Evita allow * a menos que te guste explicarlo luego.

Task 15: Actualiza (o crea) el archivo keyring de forma consistente en todos los nodos

cr0x@server:~$ ceph auth get client.pve -o /etc/ceph/ceph.client.pve.keyring
exported keyring for client.pve

Qué significa: Estás escribiendo la clave/caps autorizados en el sistema de archivos del nodo. Repite en cada nodo o distribuye de forma segura.

Decisión: Si solo un nodo tenía un keyring obsoleto, esto elimina fallas node-specific “error opening”.

Task 16: Valida que la definición de almacenamiento de Proxmox esté sana

cr0x@server:~$ pvesm status
Name       Type     Status           Total       Used        Available        %
ceph-rbd   rbd      active            0           0           0               0.00
local      dir      active        1966080    1126400          839680         57.29

Qué significa: Para RBD, la capacidad puede mostrarse como 0 según la configuración, pero el almacenamiento debe aparecer active.

Decisión: Si está inactivo o da errores, revisa mon_host, username y la ruta keyring en storage.cfg.

Modelo de autenticación Ceph en Proxmox: clientes, keyrings, caps y dónde Proxmox lo oculta

Nombres de cliente: el error más habitual es una coincidencia de una sola palabra

Los usuarios de Ceph se llaman como client.pve, client.admin, client.proxmox. En Proxmox storage.cfg, a menudo especificas
username pve, que Proxmox interpreta como client.pve.

Los patrones de desajuste:

• Desajuste en encabezado del keyring: el archivo contiene [client.proxmox] pero Proxmox usa pve. La autenticación falla.
• Clave obsoleta: el encabezado del archivo es correcto pero la clave viene de una rotación anterior. La autenticación falla.
• Desajuste de caps: la autenticación tiene éxito pero las operaciones fallan al abrir/crear/snapshot.

Ubicación del keyring: configuración compartida, secretos locales

El sistema de archivos de cluster de Proxmox invita a pensar que todo en tu configuración se replica. No es así.
/etc/pve/storage.cfg se replica. Tu archivo keyring bajo /etc/ceph es solo un archivo local.

Por eso ocurre tan a menudo “funciona en nodo1, falla en nodo3”:

• Agregaste el almacenamiento en la UI una vez; actualizó /etc/pve/storage.cfg en todo el cluster.
• Copiaste el keyring solo en un nodo (o copiaste una versión distinta).
• Proxmox programa con gusto un arranque en un nodo que no puede autenticarse, y obtienes “error opening”.

Caps: “profile rbd” es la base, acotar por pool es la baranda de seguridad

Para uso de RBD en Proxmox, el punto operativo adecuado es:

• mon = "profile rbd" para que el cliente pueda consultar mapas y metadatos relacionados con RBD.
• osd = "profile rbd pool=<poolname>" para que el cliente pueda acceder a imágenes en un pool específico.

Si usas múltiples pools (p. ej., vmdata, fast-ssd, templates), o bien:

• Otorgas cláusulas múltiples por pool (clientes separados es más limpio), o
• Aceptas caps más amplios y convives con el intercambio de seguridad.

Proxmox y /etc/pve/ceph.conf: la división sutil de configuración

Proxmox puede mantener una configuración de Ceph en /etc/pve/ceph.conf, y los procesos QEMU invocados por tareas de Proxmox pueden referenciarla directamente.
Mientras tanto, tus comandos de shell pueden usar por defecto /etc/ceph/ceph.conf. Si difieren, perderás horas “probando” hechos contradictorios.

Decide una fuente de verdad y mantenla consistente. Si Proxmox usa /etc/pve/ceph.conf, mantenla correcta y sincronizada con el cluster real.

Una cita de confiabilidad que deberías tomarte en serio

Idea parafraseada de John Allspaw (operaciones/confiabilidad): “Los incidentes vienen del trabajo normal y de decisiones ordinarias, no solo de incompetencia rara.”

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

1) Síntoma: Funciona en un nodo, falla en otro con “error opening”

Causa raíz: Archivo keyring faltante o diferente en el nodo que falla (o ceph.conf distinto).

Solución: Asegura que el keyring y la configuración existan y coincidan en cada nodo.

cr0x@server:~$ sha256sum /etc/ceph/ceph.client.pve.keyring /etc/ceph/ceph.conf /etc/pve/ceph.conf
e1d0c0d2f0b8d66c3f2f5b7a20b3fcb0a1f6e42a2bfafbfcd1c4e2a8fcbcc3af  /etc/ceph/ceph.client.pve.keyring
9b1f0c3c4f74d5d5c22d5e4e2d0a2a77bff2f5bd3d92a0e7db6c2f4f122c8f10  /etc/ceph/ceph.conf
9b1f0c3c4f74d5d5c22d5e4e2d0a2a77bff2f5bd3d92a0e7db6c2f4f122c8f10  /etc/pve/ceph.conf

Decisión: ¿Hash mismatched entre nodos? Alto. Estandariza. No sigas depurando en capas superiores.

2) Síntoma: “(13) Permission denied” al arrancar VM o crear disco

Causa raíz: Caps demasiado restrictivos para lo que Proxmox hace (create, snapshot, clone), o acotamiento de pool equivocado.

Solución: Actualiza caps para incluir el pool correcto y profile rbd. Verifica con la prueba rbd create.

cr0x@server:~$ rbd create vmdata/caps-test --size 64M --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd: create error: (13) Permission denied

Decisión: Esto confirma que son los caps, no una configuración de VM inestable. Arregla los caps, luego vuelve a probar crear y borra la imagen de prueba.

3) Síntoma: “no keyring found” o “failed to load keyring” en logs

Causa raíz: Ruta de keyring incorrecta en storage.cfg, o archivo existe pero permisos/SELinux/AppArmor (raro en Proxmox por defecto).

Solución: Corrige la ruta; usa ruta absoluta; establece 0600 root:root.

4) Síntoma: “error connecting to the cluster” o timeouts a MON

Causa raíz: IPs de monitores equivocadas en storage.cfg/ceph.conf, firewall bloqueando 3300/6789, o mismatch DNS/IPv6.

Solución: Usa direcciones de monitores estables; valida la conectividad; evita hostnames a menos que DNS sea realmente fiable.

5) Síntoma: el listado RBD funciona, pero la apertura falla para algunas imágenes

Causa raíz: La imagen está en otro pool, o las características de la imagen requieren operaciones que tus caps bloquean, o el nombre de la imagen es incorrecto (typo, referencia obsoleta tras renombrar).

Solución: Verifica pool/imagen exacta; ejecuta rbd info y rbd snap ls usando la misma identidad que Proxmox usa.

6) Síntoma: Tras rotar claves, VMs antiguas no arrancan

Causa raíz: Un nodo aún tiene el keyring viejo; Proxmox programa inicios allí; obtienes “error opening”.

Solución: Despliega actualizaciones de keyring de forma atómica en los nodos, luego valida con un pequeño conjunto de pruebas de arranque/migración.

Broma #2: Rotar claves es como usar hilo dental—todos acuerdan que es bueno, y casi nadie lo hace en el calendario que dicen.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana ejecutaba un cluster Proxmox con Ceph RBD para discos de VM. Añadieron un nodo nuevo, lo unieron al cluster Proxmox y lo dieron por hecho.
A la mañana siguiente, una tarea de mantenimiento rutinaria desencadenó varias migraciones de VM hacia el nodo nuevo.

La mitad de las VMs migradas no volvieron. Proxmox mostró el mismo mensaje contundente: “error opening”.
Ceph estaba sano. El almacenamiento estaba definido en /etc/pve/storage.cfg, así que el equipo asumió “la configuración de almacenamiento se replicó; por tanto el acceso se replicó”.

Esa suposición fue el incidente completo. El nodo nuevo no tenía /etc/ceph/ceph.client.pve.keyring. Los nodos existentes sí.
La UI de Proxmox lo empeoró por ser consistente: mismo nombre de almacenamiento, mismo pool, mismos monitores, mismo mensaje de fallo.

La solución fue poco glamorosa: distribuir el keyring a cada nodo, verificar hashes coincidentes, y luego reintentar los arranques.
La acción postmortem fue aún más aburrida: una checklist de incorporación de nodo con una puerta “Keyrings de Ceph presentes y verificados”.

Microhistoria 2: La optimización que salió mal

Otra organización quiso reducir el área de impacto, así que crearon usuarios Ceph separados para distintos clusters Proxmox y minimizaron agresivamente los caps.
Buena intuición. Luego fueron un paso demasiado lejos: caps de solo lectura para un usuario que Proxmox también usaba para operaciones de snapshot y templating basado en clones.

Todo funcionó semanas porque las lecturas/escrituras diarias de VM funcionaban en su mayoría—hasta que la canalización de templates se ejecutó a escala.
De repente, las tareas de aprovisionamiento comenzaron a fallar con “error opening” y “permission denied”, y el equipo persiguió problemas de red porque las fallas eran intermitentes y correlacionadas en el tiempo.

La causa real era que algunas operaciones necesitaban escrituras de metadatos (crear snapshot, clonar, flatten) que sus caps bloqueaban.
Las fallas fueron periódicas porque esas operaciones lo eran.

Lo solucionaron separando responsabilidades: un usuario Ceph para “I/O en tiempo de ejecución de VM” con acceso estrictamente acotado al pool,
y otro para “gestión de imágenes” usado por la automatización, con permisos adicionales y controles operativos más estrictos.
El principio de menor privilegio sobrevivió. Solo necesitó alinearse con los flujos reales de trabajo, no con deseos.

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

Un equipo de servicios financieros tenía un hábito que parecía casi cómico: cada nodo tenía un pequeño script local que validaba el acceso del cliente Ceph diariamente.
Ejecutaba ceph -s, rbd ls y rbd info contra una imagen conocida, usando las credenciales exactas que Proxmox usaba.
Registraba resultados localmente y además emitía una métrica simple “ok/fail”.

Una tarde, un administrador de Ceph rotó claves durante una ventana de cambios. El cambio fue correcto, los caps estaban bien y el cluster Ceph permaneció sano.
Pero un nodo Proxmox perdió la actualización del key debido a una falla temporal en la gestión de configuración.

Su validación diaria lo detectó en pocas horas—antes de que una migración de mantenimiento moviera cargas al nodo roto.
En vez de una caída, tuvieron un ticket: “Node pve7 falla RBD open usando client.pve.” La remediación fue sincronizar keyrings y volver a probar.

No pasó nada heroico. Nadie fue alertado. Así es la ingeniería de confiabilidad en un buen día: menos historias que contar.

Listas de verificación / plan paso a paso

Checklist A: Cuando una VM no arranca con “error opening”

1. Desde el nodo que falla, obtén el error exacto y los parámetros de los logs (journalctl -u pvedaemon).
2. Extrae id=, keyring=, pool, nombre de imagen y la ruta conf=.
3. Ejecuta rbd --conf ... info pool/image --id ... --keyring ....
4. Si falla la auth: verifica existencia del keyring, corrección y encabezado del nombre de cliente.
5. Si es permission denied: inspecciona caps y acotamiento de pool; corrige caps; vuelve a probar.
6. Si falla la conectividad a monitores: valida puertos 3300/6789; verifica mon_host y ruteo/MTU.
7. Una vez arreglado, reintenta el arranque de la VM y verifica lectura/escritura.

Checklist B: Añadir un nodo Proxmox nuevo a un cluster respaldado por Ceph

1. Instala los paquetes cliente Ceph necesarios para tu versión de Proxmox.
2. Copiar /etc/ceph/ceph.conf (o asegura que /etc/pve/ceph.conf sea correcto y se use consistentemente).
3. Copiar keyrings necesarios: típicamente /etc/ceph/ceph.client.pve.keyring.
4. Verificar permisos de archivos: 0600 root:root para keyrings.
5. Ejecutar: ceph -s y rbd -p <pool> ls --id pve --keyring ....
6. Sólo entonces permitir migraciones/HA hacia ese nodo.

Checklist C: Rotación de claves relativamente segura para clientes Proxmox RBD

1. Crear o actualizar la entrada de auth en Ceph (ceph auth get-or-create / ceph auth caps), manteniendo el acotamiento por pool correcto.
2. Exportar el keyring actualizado.
3. Distribuir el keyring a todos los nodos Proxmox (de forma atómica si es posible).
4. Verificar que los hashes coincidan entre nodos.
5. Ejecutar pruebas de apertura RBD desde cada nodo usando el mismo --conf que usa QEMU.
6. Realizar un canario pequeño: arrancar una VM por nodo, hacer una migración, crear un snapshot si los usas.
7. Solo entonces considerar la rotación “completada”.

Comandos que ayudan a automatizar la validación de la checklist

cr0x@server:~$ rbd --conf /etc/pve/ceph.conf info vmdata/vm-101-disk-0 --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd image 'vm-101-disk-0':
	size 100 GiB in 25600 objects
	order 22 (4 MiB objects)
	snapshot_count: 2
	id: 1a2b3c4d5e6f
	format: 2
	features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
	op_features:
	flags:
	create_timestamp: Tue Dec 24 09:12:33 2025
	access_timestamp: Tue Dec 24 09:12:33 2025
	modify_timestamp: Thu Dec 26 10:01:07 2025

Decisión: Si esto funciona en cada nodo, eliminaste la mayoría de causas de “error opening” relacionadas con auth/keyring.

Preguntas frecuentes (FAQ)

1) ¿Por qué Proxmox muestra “error opening” en lugar del error real de Ceph?

Porque el error atraviesa las capas QEMU/librbd y se resume. La razón detallada suele estar en líneas de journalctl que muestran
“permission denied”, “no such file” o errores de conexión. Siempre extrae logs del nodo que falló.

2) Puedo ejecutar ceph -s con éxito, ¿por qué falla Proxmox?

Tu shell puede estar usando un archivo de configuración distinto (/etc/ceph/ceph.conf) y una clave distinta (client.admin vía keyring por defecto).
Proxmox podría usar /etc/pve/ceph.conf y client.pve. Prueba usando el mismo --conf, --id y --keyring que ves en los logs de Proxmox.

3) ¿Puedo usar client.admin para que deje de dar el error?

Puedes, y “funcionará”, y es una mala práctica. Amplía el área de impacto y complica auditorías. Usa un cliente dedicado con caps acotados por pool.
Reserva client.admin para tareas administrativas, no para I/O rutinario de VM.

4) ¿Cuáles son los caps mínimos para uso RBD en Proxmox?

Típicamente: mon "profile rbd" y osd "profile rbd pool=<pool>". Si usas flujos adicionales (snapshots, clones, flatten),
normalmente aún quieres profile rbd, pero puede que necesites asegurar que el cluster y los clientes soporten las operaciones necesarias. Valida probando la operación con la misma identidad.

5) ¿Por qué falla solo durante migración o snapshot?

Porque migraciones y snapshots ejercitan llamadas de API distintas. Listar imágenes no es lo mismo que abrir una imagen con ciertas características, crear snapshots o clonar.
Si falla en esas operaciones, sospecha primero un desajuste de caps.

6) ¿Dónde almacena Proxmox los secretos de Ceph?

Proxmox guarda la definición de almacenamiento en /etc/pve/storage.cfg. La clave normalmente está en un archivo keyring bajo /etc/ceph referenciado por ruta.
Algunas configuraciones embeben secretos de forma distinta, pero el patrón “keyring local por nodo” es común y es precisamente la razón de los desajustes entre nodos.

7) ¿Cómo diferencio un problema de conectividad a monitores de uno de autenticación?

Si ves timeouts y “error connecting to the cluster”, valida la accesibilidad de red a puertos MON (3300/6789) y confirma mon_host.
Si ves “permission denied” rápido, los monitores son accesibles y la auth/caps probablemente son la causa.

8) ¿Necesito reiniciar servicios de Proxmox tras arreglar keyrings o caps?

A menudo no; las nuevas tareas recogerán el keyring actualizado. Pero si cambias qué archivo de configuración se usa o actualizaste definiciones de almacenamiento,
reiniciar pvedaemon y reintentar la tarea puede eliminar estado en caché. Mantén los reinicios dirigidos; no reinicies nodos como terapia.

9) ¿Cuál es la prueba segura y más rápida para validar una solución?

Ejecuta rbd info pool/image usando el mismo --conf, --id y --keyring que QEMU usa, desde el nodo que falló.
Luego arranca una VM que use esa imagen. Si dependes de snapshots/clones, prueba también una de esas operaciones.

10) ¿Podría ser un bug de Ceph o corrupción de datos?

Puede ser, pero si el cluster está sano y el error es “permission denied” o “keyring not found”, no es corrupción.
Empieza por auth/config; el 95% de incidentes “error opening” son cortes autoinfligidos por descuidos.

Conclusión: siguientes pasos que puedes hacer hoy

Si quieres que “error opening” deje de ser un personaje recurrente en tu vida de on-call, haz tres cosas:

1. Estandariza qué archivo de configuración usa QEMU (/etc/pve/ceph.conf vs /etc/ceph/ceph.conf) y haz que sean consistentes entre nodos.
2. Usa un cliente Ceph dedicado (por ejemplo, client.pve) con caps profile rbd acotados por pool. Deja de usar client.admin para I/O rutinario de VM.
3. Haz de los keyrings un artefacto de despliegue de primera clase: distribúyelos a cada nodo, verifica hashes y valida acceso con una prueba automatizada rbd info.

La buena noticia: una vez trates keyrings y caps como configuración de producción (no como conocimiento tribal), Ceph se vuelve predeciblemente aburrido. Ese es el objetivo.