Proxmox RBD « error opening » : erreurs d’authentification et de keyring, et correctifs

Ce que signifie réellement « error opening » dans le contexte Proxmox RBD

Quand Proxmox dit « RBD: error opening », vous voyez généralement une erreur remontée depuis librbd (la librairie userspace utilisée pour accéder aux images RBD).
La librairie tente de :

1. Charger la configuration Ceph (moniteurs, réglages d’authentification, fsid, etc.).
2. S’authentifier (cephx) en utilisant une clé pour un ID client donné (client.admin, client.pve ou un utilisateur personnalisé).
3. Parler aux moniteurs (MONs), obtenir la carte du cluster et localiser les OSDs.
4. Ouvrir l’image RBD (ce qui nécessite des permissions sur le pool et l’image).

« Error opening » est fréquemment déclenché par :

• Mauvais ou absence de keyring/clé dans la configuration de stockage Proxmox.
• Inadéquation d’ID client : vous avez la bonne clé, mais pour le mauvais nom de client.
• Caps ne permettant pas l’opération (caps en lecture seule mais vous créez des images ; absence de profile rbd ; manque d’accès aux métadonnées rbd_children, etc.).
• Moniteurs inaccessibles depuis un nœud (routage, pare-feu, mon_host incorrect, confusion IPv6 vs IPv4).
• Différences de configuration Ceph entre nœuds (un nœud a un /etc/ceph/ceph.conf obsolète ou un fsid erroné).
• Permissions des fichiers keyring sur le disque : root peut le lire, mais un processus tourne sous un autre utilisateur (courant dans des outils personnalisés ; moins courant sur une installation Proxmox standard).

La manière la plus rapide d’arrêter de deviner est de reproduire l’opération d’ouverture exacte depuis le nœud défaillant en utilisant la CLI rbd avec le même ID et le même keyring.
Si rbd ls fonctionne mais que rbd info pool/image échoue, vous êtes face à un mismatch de caps. Si rien ne fonctionne, commencez par les moniteurs + keyring.

Blague n°1 : « Error opening » est ce que Ceph dit quand il est trop poli pour dire « votre keyring est pourri. »

Fiche de diagnostic rapide (vérifier 1/2/3)

C’est l’ordre qui termine les incidents le plus vite. Pas l’ordre qui procure la satisfaction émotionnelle.

1) Confirmez que vous pouvez atteindre les moniteurs et vous authentifier depuis le nœud défaillant

• Si la connectivité aux moniteurs ou l’auth cephx échoue, rien d’autre n’a d’importance. Réglez d’abord ça.
• Utilisez ceph -s et ceph auth get client.X le cas échéant.

2) Confirmez que Proxmox utilise bien le keyring que vous croyez

• Inspectez /etc/pve/storage.cfg et le chemin keyring par stockage (ou la clé intégrée).
• Validez que le fichier existe sur chaque nœud (la config Proxmox est partagée, mais les fichiers keyring sont locaux sauf si vous les gérez explicitement).

3) Validez les caps par rapport au pool et à l’opération

• Listez les caps : ceph auth get client.pve.
• Testez avec des commandes rbd qui reflètent l’action en échec : rbd ls, rbd info, rbd create, rbd snap ls.

4) Ensuite seulement : investiguez les erreurs de l’UI Proxmox, les logs qemu et les cas limites

• Consultez les logs de tâches et journalctl pour pvedaemon, pveproxy et qemu-server.
• La plupart des incidents « error opening » sont liés à l’auth/caps/config. Les cas exotiques existent, mais ce ne sont pas vos premiers suspects.

Faits et contexte intéressants (parce que le passé tourne encore en prod)

• L’auth Ceph « cephx » a été conçue pour éviter les secrets partagés à l’échelle du cluster. Vous pouvez limiter les clés aux pools et aux opérations, d’où l’importance des caps.
• Le public initial de RBD était les plateformes cloud. Le modèle « image + snapshot + clone » est très centré VM, d’où l’adoption précoce par Proxmox et OpenStack.
• Proxmox stocke la config du cluster dans un système de fichiers distribué. /etc/pve est partagé entre nœuds, mais les fichiers locaux comme /etc/ceph/ceph.client.pve.keyring ne sont pas répliqués automatiquement.
• Historiquement, beaucoup de déploiements utilisaient client.admin partout. Ça « marche » jusqu’à ce que ça devienne un cauchemar d’audit et un amplificateur d’incidents.
• La syntaxe des caps a évolué dans le temps. Les anciens articles montrent des modèles obsolètes ; Ceph moderne préfère profile rbd plus le scope explicite du pool.
• Les moniteurs Ceph sont une porte de cohérence. Vous pouvez avoir des OSDs sains et quand même échouer à des ouvertures RBD si le quorum MON ou l’accessibilité sont rompus depuis un nœud.
• Ouvrir un RBD peut nécessiter des opérations sur les métadonnées. Même les lectures peuvent exiger l’accès aux métadonnées du pool (et selon les fonctionnalités, aux clés omap). « Je lui ai donné lecture seule » peut être accidentellement trop strict.
• La découverte de configuration Ceph a plusieurs chemins. Variables d’environnement, chemins par défaut et flags explicites peuvent conduire à un « ça marche dans mon shell » mais échoue dans les tâches Proxmox.

Symptômes courants : ce que vous verrez et où

Proxmox peut exposer la même défaillance sous plusieurs couches. Apprenez les schémas :

• Journal de tâches Proxmox : « rbd: error opening » lors de la création de disque, de l’attachement, d’un snapshot, d’une migration ou du démarrage d’une VM.
• Échecs de démarrage QEMU : la VM ne démarre pas ; les logs qemu mentionnent l’incapacité à ouvrir l’image RBD.
• Erreurs CLI de mapping : rbd map retourne « permission denied » ou « error connecting to the cluster ».
• Indices côté Ceph : les logs MON montrent des échecs d’auth ; les logs OSD montrent des opérations refusées ; mais souvent Ceph reste silencieux sauf si les niveaux de debug sont augmentés.
• Comportement spécifique au nœud : un nœud Proxmox peut accéder au RBD ; un autre ne le peut pas. Ça crie « mismatch de keyring/config locale ».

Tâches pratiques : commandes, sorties et décisions (12+)

Le but de ces tâches est de transformer des erreurs UI vagues en décisions nettes. Exécutez-les depuis le nœud Proxmox défaillant d’abord, puis depuis un nœud connu bon pour comparer.

Task 1: Confirm Ceph cluster is reachable and you’re not chasing ghosts

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

Ce que cela signifie : Cela confirme que la CLI peut parler aux moniteurs et s’authentifier en utilisant la config/clé par défaut que votre shell utilise.

Décision : Si cela échoue sur le nœud en panne mais fonctionne ailleurs, corrigez d’abord l’accessibilité des moniteurs et la config Ceph locale avant de toucher Proxmox.

Task 2: Identify what Proxmox thinks your RBD storage is

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

Ce que cela signifie : Proxmox tentera de se connecter à ces IPs de moniteurs, s’authentifier en tant que client.pve, en utilisant ce fichier keyring.

Décision : Si le keyring est absent ou pointe vers un fichier qui n’existe pas sur certains nœuds, vous avez trouvé la cause racine.

Task 3: Verify the keyring file exists on this node and is readable

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

Ce que cela signifie : Il existe et seul root peut le lire, ce qui est normal sur Proxmox.

Décision : S’il manque sur un nœud, copiez-le de manière sécurisée ou recréez-le. Si les permissions sont trop permissives, corrigez-les ; les secrets négligés deviennent des incidents.

Task 4: Confirm the keyring actually contains the expected client name

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"

Ce que cela signifie : L’en-tête de section doit correspondre au nom d’utilisateur que Proxmox utilise (sans le préfixe client. dans storage.cfg).

Décision : Si le fichier indique [client.admin] mais que storage.cfg dit username pve, Proxmox échouera à s’authentifier.

Task 5: Test RBD access explicitly using the same identity as 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

Ce que cela signifie : L’authentification fonctionne et l’utilisateur peut lister les images dans le pool.

Décision : Si la liste fonctionne mais que Proxmox échoue toujours à l’ouverture, le problème est probablement lié aux permissions spécifiques à l’image/fonctionnalités ou à un nom de pool/image différent de ce que vous pensez.

Task 6: Reproduce the open on a specific image (most useful for “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

Ce que cela signifie : Si cela réussit, l’« open » fonctionne au niveau RBD. Proxmox devrait pouvoir démarrer la VM à moins qu’il n’utilise d’autres identifiants/config.

Décision : Si cela échoue avec « permission denied », vos caps sont insuffisantes pour des opérations sur les métadonnées ou vous ciblez le mauvais pool.

Task 7: Confirm caps for the client user (don’t guess)

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

Ce que cela signifie : Ceci est la vérité autoritaire à l’intérieur de Ceph (pas ce qui est copié dans un fichier keyring).

Décision : Si les caps n’incluent pas le pool cible, corrigez-les. Si la clé diffère du fichier keyring, mettez-le à jour partout.

Task 8: Check the Ceph config that Proxmox will implicitly use

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

Ce que cela signifie : Un fsid erroné ou un mon_host manquant/incorrect peut pousser un nœud à parler au mauvais cluster ou à aucun cluster.

Décision : Si cela diffère entre nœuds, standardisez-le. Une divergence de configuration est la cause typique d’un « ça marchait hier » sans changement réel.

Task 9: Confirm monitor reachability from the failing node (routing/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!

Ce que cela signifie : Ceph MON utilise 3300 (msgr2) et parfois 6789 (legacy). Vous voulez la connectivité au moins vers ce que votre cluster utilise.

Décision : Si ceci échoue sur un seul nœud, corrigez le pare-feu/routage/VLAN/MTU. Ne « corrigez » pas l’auth pour compenser un réseau défaillant.

Task 10: Pull the Proxmox task log that contains the failure

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

Ce que cela signifie : Cela confirme les arguments exacts que QEMU a utilisés, incluant id=pve et le chemin du keyring. C’est de l’or.

Décision : Refaire la commande RBD équivalente manuellement avec ces paramètres. Si cela échoue, ce n’est pas « un problème Proxmox ».

Task 11: Verify Proxmox is pointing QEMU at the right ceph.conf

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

Ce que cela signifie : Proxmox peut générer/utiliser /etc/pve/ceph.conf. Cela peut différer de /etc/ceph/ceph.conf.

Décision : Si vos tests CLI utilisent /etc/ceph/ceph.conf mais QEMU utilise /etc/pve/ceph.conf, alignez-les ou testez avec le même --conf.

Task 12: Re-test with the same config file that QEMU used

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

Ce que cela signifie : Cela précise la portée du problème. Votre succès précédent pouvait provenir d’une autre config (cluster différent, mon_host différent, réglages d’auth différents).

Décision : Inspectez /etc/pve/ceph.conf et corrigez-le ou cessez de l’utiliser. La cohérence bat l’ingéniosité.

Task 13: Confirm which Ceph cluster you’re talking to (fsid sanity check)

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

Ce que cela signifie : Si le fsid diffère du cluster attendu, vous vous authentifiez contre le mauvais cluster Ceph (ou un ancien lab oublié).

Décision : Corrigez le fichier de config et redémarrez les services affectés ; n’ajoutez pas « juste plus de mons » à deux clusters en espérant le meilleur.

Task 14: Fix caps for a Proxmox RBD client (typical safe pattern)

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

Ce que cela signifie : Vous accordez les permissions monitor appropriées et des permissions OSD scoppées sur le pool. C’est le comportement par défaut sensé pour des disques VM dans un pool.

Décision : Si vous avez plusieurs pools utilisés par Proxmox, ajoutez chaque pool explicitement. Évitez allow * sauf si vous aimez devoir l’expliquer plus tard.

Task 15: Update (or create) the keyring file consistently across nodes

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

Ce que cela signifie : Vous écrivez la clé/caps autoritaire sur le système de fichiers du nœud. Répétez sur chaque nœud ou distribuez de manière sécurisée.

Décision : Si un seul nœud avait un keyring obsolète, ceci élimine les échecs « error opening » spécifiques à un nœud.

Task 16: Validate Proxmox storage definition is healthy

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

Ce que cela signifie : Pour RBD, la capacité peut afficher 0 selon le réglage, mais le stockage doit être active.

Décision : S’il est inactive ou signale des erreurs, revérifiez les mon_host, username et chemin keyring dans storage.cfg.

Modèle d’authentification Ceph dans Proxmox : clients, keyrings, caps et où Proxmox cache les choses

Client names: the most common foot-gun is a one-word mismatch

Les utilisateurs Ceph s’appellent client.pve, client.admin, client.proxmox. Dans Proxmox storage.cfg, vous spécifiez souvent
username pve, que Proxmox interprète comme client.pve.

Les schémas de mismatch :

• Mismatch d’en-tête de keyring : le fichier contient [client.proxmox] mais Proxmox utilise pve. L’auth échoue.
• Clé obsolète : l’en-tête du fichier est correcte mais la clé provient d’une rotation antérieure. L’auth échoue.
• Caps inadéquates : l’auth réussit mais les opérations échouent au moment d’ouvrir/créer/snapshot.

Keyring location: shared config, local secrets

Le système de fichiers cluster de Proxmox donne envie de penser que tout dans votre configuration est répliqué. Ce n’est pas le cas.
/etc/pve/storage.cfg est répliqué. Votre fichier keyring sous /etc/ceph est juste un fichier local.

C’est pourquoi « fonctionne sur le nœud1, échoue sur le nœud3 » arrive si souvent :

• Vous avez ajouté le stockage via l’UI une fois, cela a mis à jour /etc/pve/storage.cfg sur tout le cluster.
• Vous avez copié le keyring sur un seul nœud (ou une version différente).
• Proxmox programme volontiers un démarrage de VM sur un nœud qui ne peut pas s’authentifier, et vous obtenez « error opening ».

Caps: “profile rbd” is the baseline, pool scoping is the safety rail

Pour l’utilisation RBD de Proxmox, le compromis opérationnel est :

• mon = "profile rbd" pour que le client puisse interroger les maps nécessaires et les métadonnées liées à RBD.
• osd = "profile rbd pool=<poolname>" pour que le client puisse accéder aux images d’un pool spécifique.

Si vous utilisez plusieurs pools (par ex. vmdata, fast-ssd, templates), vous pouvez soit :

• Accorder plusieurs clauses de pool (des clients séparés sont plus propres), ou
• Accepter des caps plus larges et assumer le compromis de sécurité.

Proxmox and /etc/pve/ceph.conf: the subtle config split

Proxmox peut maintenir une configuration Ceph sous /etc/pve/ceph.conf, et les processus QEMU lancés par Proxmox peuvent la référencer directement.
Pendant ce temps, vos commandes shell peuvent par défaut utiliser /etc/ceph/ceph.conf. Si ces fichiers diffèrent, vous perdrez des heures à « prouver » des faits contradictoires.

Choisissez une source de vérité et rendez-la cohérente. Si Proxmox utilise /etc/pve/ceph.conf, gardez-la correcte et synchronisée avec le cluster.

One reliability quote you should actually take seriously

Paraphrase d’une idée de John Allspaw (opérations/fiabilité) : « Les incidents viennent du travail normal et des décisions ordinaires, pas seulement d’incompétences rares. »

Erreurs fréquentes : symptôme → cause racine → correction

1) Symptom: Works on one node, fails on another with “error opening”

Cause racine : Fichier keyring absent ou différent sur le nœud en échec (ou ceph.conf différent).

Correction : Assurez-vous que le keyring et la configuration existent et correspondent sur chaque nœud.

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

Décision : Hashs différents entre nœuds ? Stop. Standardisez. Ne continuez pas à déboguer les couches supérieures.

2) Symptom: “(13) Permission denied” when starting VM or creating disk

Cause racine : Caps trop restrictives pour ce que Proxmox tente de faire (create, snapshot, clone), ou mauvaise portée pool.

Correction : Mettez à jour les caps pour inclure le pool correct et profile rbd. Vérifiez avec un test 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

Décision : Cela confirme que c’est les caps, pas une configuration VM instable. Corrigez les caps, retestez la création et supprimez l’image de test.

3) Symptom: “no keyring found” or “failed to load keyring” in logs

Cause racine : Mauvais chemin keyring dans storage.cfg, ou le fichier existe mais a des permissions/contexts SELinux/AppArmor incorrects (rare sur Proxmox par défaut).

Correction : Corrigez le chemin ; utilisez un chemin absolu ; mettez 0600 root:root.

4) Symptom: “error connecting to the cluster” or MON connection timeouts

Cause racine : IPs de moniteurs erronées dans storage.cfg/ceph.conf, pare-feu bloquant 3300/6789, ou mismatch DNS/IPv6.

Correction : Utilisez des adresses de moniteurs stables ; validez la connectivité ; évitez les noms d’hôte sauf si le DNS est réellement fiable.

5) Symptom: RBD list works, but open fails for some images

Cause racine : L’image est dans un autre pool, ou les fonctionnalités de l’image exigent des opérations que vos caps bloquent, ou le nom d’image est erroné (typo, référence obsolète après renommage).

Correction : Vérifiez pool/image exacts ; exécutez rbd info et rbd snap ls en utilisant la même identité que Proxmox.

6) Symptom: After rotating keys, old VMs won’t start

Cause racine : Un nœud a encore l’ancien keyring ; Proxmox y planifie des starts ; vous obtenez « error opening ».

Correction : Déployez les mises à jour de keyring de façon atomique sur tous les nœuds, puis validez avec un petit jeu de tests start/migrate.

Blague n°2 : La rotation de clés, c’est comme utiliser du fil dentaire — tout le monde admet que c’est bien, et presque personne ne le fait selon le calendrier annoncé.

Trois mini-histoires d’entreprise issues du terrain

Mini-story 1: The incident caused by a wrong assumption

Une entreprise de taille moyenne exploitait un cluster Proxmox avec Ceph RBD pour les disques VM. Ils ont ajouté un nouveau nœud, l’ont joint au cluster Proxmox et l’ont considéré comme terminé.
Le lendemain matin, une maintenance de routine a déclenché une série de migrations de VM vers le nouveau nœud.

La moitié des VMs migrées ne revenaient pas. Proxmox affichait le même message laconique : « error opening ».
La santé Ceph était bonne. Le stockage était défini dans /etc/pve/storage.cfg, donc l’équipe a supposé « la config de stockage s’est répliquée ; donc l’accès au stockage aussi ».

Cette hypothèse était la cause entière de l’incident. Le nouveau nœud n’avait pas /etc/ceph/ceph.client.pve.keyring. Les nœuds existants l’avaient.
L’UI Proxmox a empiré la situation en étant cohérente : même nom de stockage, même pool, mêmes moniteurs, même message d’échec.

La correction fut peu glamour : distribuer le keyring à chaque nœud, vérifier que les hashes correspondent, puis relancer les starts.
L’action de postmortem fut encore plus ennuyeuse : une checklist d’ajout de nœud avec une étape « keyrings Ceph présents et vérifiés ».

Mini-story 2: The optimization that backfired

Une autre organisation voulait réduire le rayon d’impact et a créé des utilisateurs Ceph séparés pour différents clusters Proxmox en minimisant agressivement les caps.
Bonne intention. Puis ils ont été trop loin : caps en lecture seule pour un utilisateur que Proxmox utilisait aussi pour des opérations de snapshot et de templating par clone.

Tout semblait bien pendant des semaines parce que les I/O runtime de VM fonctionnaient la plupart du temps — jusqu’à ce que la pipeline de templates tourne à grande échelle.
Soudain, les tâches de provisioning ont commencé à échouer avec « error opening » et « permission denied », et l’équipe a cherché du réseau car les échecs étaient intermittents et corrélés dans le temps.

La vraie cause était que certaines opérations nécessitaient des écritures métadonnées (création de snapshot, clone, flatten) que leurs caps bloquaient.
Les échecs étaient périodiques car ces opérations l’étaient.

Ils ont corrigé cela en séparant les responsabilités : un utilisateur Ceph pour « I/O runtime VM » avec accès pool strictement scoppé,
un autre pour les tâches de gestion d’images pilotées par l’automatisation, avec permissions supplémentaires et contrôles opérationnels plus stricts.
Le principe du moindre privilège a survécu. Il fallait juste l’aligner sur les workflows réels, pas sur des souhaits.

Mini-story 3: The boring but correct practice that saved the day

Une équipe de services financiers avait une habitude presque comique : chaque nœud avait un petit script local validant quotidiennement l’accès client Ceph.
Il exécutait ceph -s, rbd ls et rbd info contre une image connue, en utilisant les mêmes identifiants que Proxmox.
Il consignait les résultats localement et exposait aussi une métrique simple « ok/fail ».

Un après-midi, un admin Ceph a tourné les clés pendant une fenêtre de changement. Le changement était correct, les caps étaient bons et le cluster Ceph est resté sain.
Mais un nœud Proxmox a raté la mise à jour du keyring à cause d’une défaillance temporaire de gestion de configuration.

Leur validation quotidienne l’a détecté en quelques heures — avant qu’une migration de maintenance n’amène des charges sur le nœud défaillant.
Au lieu d’une panne, ils ont eu un ticket : « Node pve7 fails RBD open using client.pve. » La remédiation fut une synchronisation du keyring et un retest.

Rien d’héroïque. Personne n’a été réveillé. C’est à ça que ressemble l’ingénierie de fiabilité les jours calmes : moins d’histoires à raconter.

Listes de contrôle / plan pas à pas

Checklist A: When a VM fails to start with “error opening”

1. Dépêchez-vous depuis le nœud en échec, récupérez l’erreur exacte et les paramètres dans les logs (journalctl -u pvedaemon).
2. Extrayez id=, keyring=, pool, nom d’image et le chemin conf=.
3. Exécutez rbd --conf ... info pool/image --id ... --keyring ....
4. Si l’auth échoue : vérifiez l’existence du keyring, son exactitude et l’en-tête du nom client.
5. Si « permission denied » : inspectez les caps et le scoping du pool ; corrigez les caps ; retestez.
6. Si la connectivité aux moniteurs échoue : validez les ports 3300/6789 ; vérifiez mon_host et le routage/MTU.
7. Une fois corrigé, relancez le démarrage de la VM et vérifiez la lecture/écriture.

Checklist B: Adding a new Proxmox node to a Ceph-backed cluster

1. Installez les paquets clients Ceph requis pour votre version de Proxmox.
2. Copiez /etc/ceph/ceph.conf (ou assurez-vous que /etc/pve/ceph.conf est correct et utilisé de manière cohérente).
3. Copiez les keyrings requis : typiquement /etc/ceph/ceph.client.pve.keyring.
4. Vérifiez les permissions des fichiers : 0600 root:root pour les keyrings.
5. Exécutez : ceph -s et rbd -p <pool> ls --id pve --keyring ....
6. Ce n’est qu’après cela que vous autorisez les migrations/HA sur ce nœud.

Checklist C: Safe-ish key rotation for Proxmox RBD clients

1. Créez ou mettez à jour l’entrée d’auth Ceph (ceph auth get-or-create / ceph auth caps), en gardant le scoping pool correct.
2. Exportez le fichier keyring mis à jour.
3. Distribuez le keyring à tous les nœuds Proxmox (atomiquement si possible).
4. Vérifiez que les hashes correspondent entre nœuds.
5. Exécutez des tests d’ouverture RBD depuis chaque nœud en utilisant le même --conf que QEMU.
6. Faites un canari : démarrez une VM par nœud, faites une migration, créez un snapshot si vous en utilisez.
7. Ce n’est qu’après cela que vous pouvez considérer la rotation comme « terminée ».

Commands that help automate the checklist validation

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

Décision : Si cela fonctionne sur chaque nœud, vous avez éliminé la plupart des causes d’auth/keyring de « error opening ».

FAQ

1) Why does Proxmox show “error opening” instead of the real Ceph error?

Parce que l’erreur remonte à travers QEMU/librbd et est résumée. La raison détaillée se trouve souvent dans des lignes de journalctl montrant
« permission denied », « no such file » ou des erreurs de connexion. Récupérez toujours les logs du nœud qui a échoué.

2) I can run ceph -s successfully, so why does Proxmox fail?

Votre shell peut utiliser un fichier de config différent (/etc/ceph/ceph.conf) et une clé différente (client.admin via le keyring par défaut).
Proxmox pourrait utiliser /etc/pve/ceph.conf et client.pve. Testez en utilisant le même --conf, --id et --keyring que ceux indiqués dans les logs Proxmox.

3) Can I just use client.admin to make it go away?

Vous pouvez, et ça « marche », mais c’est une mauvaise habitude. Cela augmente le rayon d’impact et complique les audits. Utilisez un client dédié avec des caps scoppées au pool.
Réservez client.admin aux tâches administratives, pas aux I/O de VM de routine.

4) What are the minimum caps for Proxmox RBD usage?

Typiquement : mon "profile rbd" et osd "profile rbd pool=<pool>". Si vous utilisez des workflows additionnels (snapshots, clones, flatten),
vous voudrez généralement conserver profile rbd, mais assurez-vous que votre cluster et vos clients supportent les opérations nécessaires. Validez en testant l’opération avec la même identité.

5) Why does it fail only during migration or snapshot?

Parce que les migrations et les snapshots sollicitent des appels API différents. Lister des images n’est pas la même chose qu’ouvrir une image avec certaines fonctionnalités, créer des snapshots ou cloner.
Si cela échoue pour ces opérations, suspectez d’abord un mismatch de caps.

6) Where does Proxmox store Ceph secrets?

Proxmox stocke la définition du stockage dans /etc/pve/storage.cfg. La clé elle-même est typiquement dans un fichier keyring sous /etc/ceph référencé par chemin.
Certaines configurations intègrent les secrets différemment, mais le modèle « fichier keyring local au nœud » est courant et explique précisément pourquoi des mismatches nœud-à-nœud surviennent.

7) How do I tell if it’s a monitor connectivity problem versus auth?

Si vous voyez des timeouts et « error connecting to the cluster », validez d’abord la reachabilité réseau vers les ports MON (3300/6789) et confirmez mon_host.
Si vous voyez rapidement « permission denied », les moniteurs sont joignables et l’auth/caps est le coupable probable.

8) Do I need to restart Proxmox services after fixing keyrings or caps?

Souvent non ; les nouvelles tâches prennent en compte le fichier keyring mis à jour. Mais si vous avez changé quel fichier de config est utilisé ou mis à jour des définitions de stockage,
redémarrer pvedaemon et retenter la tâche peut supprimer un état obsolète. Restez ciblé ; ne redémarrez pas des nœuds pour faire de la thérapie.

9) What’s the fastest safe test to validate a fix?

Exécutez rbd info pool/image en utilisant le même --conf, --id et --keyring que QEMU utilise, depuis le nœud qui a échoué.
Ensuite démarrez une VM qui utilise cette image. Si vous dépendez de snapshots/clones, testez-en un aussi.

10) Could this be a Ceph bug or data corruption?

Cela peut arriver, mais si le cluster est sain et que l’erreur est « permission denied » ou « keyring not found », ce n’est pas de la corruption.
Commencez par l’auth/config ; 95% des incidents « error opening » sont des coupures auto-infligées.

Conclusion : prochaines étapes à faire aujourd’hui

Si vous voulez que « error opening » cesse d’être un personnage récurrent dans vos rotations d’astreinte, faites trois choses :

1. Standardisez quel fichier de config QEMU utilise (/etc/pve/ceph.conf vs /etc/ceph/ceph.conf) et harmonisez-les sur tous les nœuds.
2. Utilisez un client Ceph dédié (par ex. client.pve) avec des caps profile rbd scoppées par pool. Arrêtez d’utiliser client.admin pour les I/O VM de routine.
3. Faites des keyrings un artefact de déploiement de première classe : distribuez-les sur chaque nœud, vérifiez les hashes et validez l’accès avec un test automatisé rbd info.

La bonne nouvelle : une fois que vous traitez les keyrings et les caps comme de la configuration de production (et non comme du savoir tribal), Ceph devient prévisiblement ennuyeux. C’est l’objectif.