Problema

En entornos con Proxmox VE (PVE) conectado a un clúster Ceph externo, es frecuente que operaciones que requieren acceso a RBD –por ejemplo, eliminar o migrar máquinas virtuales– fallen con mensajes como rbd: listing images failed: (2) No such file or directory o Permission denied. El origen suele ser que el cliente rbd no encuentra un keyring válido para autenticarse contra Ceph. Cuando la búsqueda automática de keyring cambia o los archivos esperados desaparecen, PVE deja de poder ejecutar comandos rbd, lo que se traduce en errores en la interfaz web y en scripts de automatización.

El síntoma típico es:

auth: unable to find a keyring on /etc/ceph/ceph.client.admin.keyring,...
monclient: handle_auth_bad_method server allowed_methods [2] but i only support [1]
rbd: couldn't connect to the cluster! rbd: listing images failed: (13) Permission denied

Este patrón no está limitado a una versión concreta de PVE; cualquier actualización que modifique la ruta de búsqueda de keyring o que cambie la política de cephx puede desencadenarlo.

Causa

  1. Ruta de búsqueda de keyring no coincidente
    Proxmox VE, por defecto, busca los keyrings en /etc/ceph/ siguiendo un orden estricto: ceph.client.admin.keyring, ceph.keyring, keyring, keyring.bin. Cuando el clúster está configurado como “external”, la clave que PVE necesita suele residir en el datastore de configuración distribuida (/etc/pve/priv/ceph/). Si la sincronización de pmxcfs falla o si el archivo no se replica, la ruta esperada queda vacía.

  2. Permisos del archivo
    Incluso cuando el keyring está presente, los permisos deben permitir que el proceso root (o el usuario bajo el que corre pvedaemon) lo lea. Un chmod 600 es obligatorio; cualquier otro modo puede provocar que Ceph ignore el archivo por considerarlo inseguro.

  3. Desalineación de nombres de cliente
    Ceph distingue entre client.admin, client.pve y cualquier otro cliente definido en ceph.conf. Si el keyring se nombra ceph.client.pve.keyring pero la herramienta rbd se invoca sin --id pve, Ceph intentará usar client.admin y fallará al no encontrar su keyring.

  4. Cambios en la política de autenticación
    Algunas actualizaciones de Ceph o de PVE pueden desactivar cephx automáticamente cuando no se detecta un keyring, lo que lleva a errores de “no keyring found”. En entornos donde el mon permite solo cephx (método 2), la falta de keyring bloquea la conexión.

  5. Configuración de rbd en /etc/ceph/ceph.conf
    Si el archivo de configuración apunta a un monitor o a un pool que ya no existe, rbd aborta antes de intentar leer el keyring, generando mensajes confusos que parecen relacionados con el keyring.

Solución

1. Verificar la existencia y la ubicación del keyring

Comprueba que el keyring está presente en el datastore de PVE y que se ha replicado a /etc/ceph/:

ls -l /etc/pve/priv/ceph/
ls -l /etc/ceph/

Si el archivo pve.keyring falta en /etc/ceph/, créalo mediante un enlace simbólico o una copia:

cp /etc/pve/priv/ceph/pve.keyring /etc/ceph/ceph.client.pve.keyring
chmod 600 /etc/ceph/ceph.client.pve.keyring

2. Alinear el nombre del cliente

Asegúrate de que rbd invoque el cliente correcto. Puedes exportar la variable de entorno CEPH_ARGS o usar la opción --id en cada comando:

rbd -p pve --id pve ls

Para que PVE siempre utilice client.pve, edita /etc/ceph/ceph.conf y añade bajo [client]:

client pve
keyring = /etc/ceph/ceph.client.pve.keyring

3. Corregir permisos y propiedad

chown root:root /etc/ceph/ceph.client.pve.keyring
chmod 600 /etc/ceph/ceph.client.pve.keyring

4. Forzar la sincronización de pmxcfs

Si sospechas que el datastore distribuido está desincronizado, reinicia el servicio:

systemctl restart pve-cluster
systemctl restart pvedaemon

Esto obliga a pmxcfs a volver a copiar los archivos bajo /etc/pve/priv/ceph/ a los nodos locales.

5. Validar la configuración de Ceph

Revisa que los monitores listados en ceph.conf sean accesibles y que el pool pve exista:

ceph -s
ceph osd pool ls

Si el pool no está presente, créalo o corrige el nombre en la configuración de PVE (GUI → Datacenter → Storage → Ceph).

6. Desactivar temporalmente la verificación estricta (solo para pruebas)

En entornos de laboratorio, puedes añadir auth supported = none en [global] de ceph.conf para comprobar que el resto de la cadena funciona sin autenticación. No lo uses en producción.

Cuándo aplicar esta solución

  • Síntomas: errores de rbd que mencionan “no such file or directory” o “Permission denied”, imposibilidad de borrar VMs desde la UI, logs de pvedaemon con “no keyring found”.
  • Entorno: PVE con clúster Ceph externo, uso de RBD como backend de discos.
  • Exclusiones: Si el clúster Ceph está corriendo en modo “no‑auth” o si la máquina virtual usa otro tipo de almacenamiento (LVM, ZFS) que no depende de Ceph, la solución no aplica.

Código

# Paso 1: copiar keyring desde el datastore distribuido
cp /etc/pve/priv/ceph/pve.keyring /etc/ceph/ceph.client.pve.keyring

# Paso 2: asegurar permisos correctos
chmod 600 /etc/ceph/ceph.client.pve.keyring
chown root:root /etc/ceph/ceph.client.pve.keyring

# Paso 3: actualizar ceph.conf para usar el cliente pve
cat <<EOF >> /etc/ceph/ceph.conf

[client.pve]
keyring = /etc/ceph/ceph.client.pve.keyring
EOF

# Paso 4: reiniciar servicios de PVE
systemctl restart pve-cluster
systemctl restart pvedaemon

# Paso 5: validar conexión rbd
rbd -p pve --id pve ls

Verificación

  1. Ejecuta rbd -p pve --id pve ls. La salida debe listar los discos RBD sin errores.
  2. Desde la UI de Proxmox, intenta eliminar una VM. El proceso debería completarse sin mensajes de error.
  3. Revisa los logs de pvedaemon (journalctl -u pvedaemon -f) mientras realizas la operación; no deben aparecer líneas con “no keyring found”.
  4. Confirma que el archivo de keyring está presente en todos los nodos del clúster (ssh nodeX "ls -l /etc/ceph/ceph.client.pve.keyring").

Notas adicionales

  • En clústers con alta disponibilidad, cualquier nodo que pierda la sincronización de pmxcfs volverá a fallar hasta que se complete la replicación. Monitorea pve-cluster con systemctl status pve-cluster para detectar desincronizaciones tempranas.
  • Si utilizas versiones de Ceph que soportan cephx v2, verifica que el monitor acepte el método que tu cliente está usando (auth supported = cephx). Un desajuste entre versiones puede producir el mensaje “handle_auth_bad_method”.
  • Evita copiar manualmente el keyring a rutas no estándar; mantener la convención de nombres (ceph.client.<id>.keyring) reduce la fricción con herramientas como rbd, rados y ceph CLI.
  • Cuando realices actualizaciones de PVE, revisa el changelog de pve-manager para cambios en la lógica de búsqueda de keyring; algunas versiones introducen la variable CEPH_CONF_DIR que altera el orden de búsqueda. Ajusta tu configuración en consecuencia.