Proxmox RBD «error opening»: помилки з автентифікацією/ключами та їх виправлення

January 31, 2026 • February 3, 2026 • Читання: 7 хв • Views: 9

Було корисно?

«error opening» — це еквівалент контрольної лампочки в приладовій панелі у світі Ceph. Він майже нічого не каже, з’являється в найневдаліший момент
і може бути викликаний однією відсутньою буквою в шляху до keyring, яку ви торкалися шість місяців тому.

У Proxmox це зазвичай проявляється, коли ви намагаєтеся створити/прикріпити диск, запустити VM або мігрувати між вузлами зі сховищем на RBD. Один вузол працює.
Інший викидає «error opening». Ваш кластер Ceph виглядає як «HEALTH_OK». Всі роздратовані. Повернемо це до буденного стану.

Що насправді означає «error opening» у термінах Proxmox RBD

Коли Proxmox повідомляє «RBD: error opening», найчастіше ви бачите помилку, що піднялася з librbd (клієнтська бібліотека для доступу до образів RBD).
Бібліотека намагається:

Завантажити конфігурацію Ceph (монітори, налаштування автентифікації, fsid тощо).
Аутентифікуватися (cephx) за допомогою ключа для певного імені клієнта (client.admin, client.pve або кастомного користувача).
Поговорити з моніторами (MONs), отримати мапу кластера та знайти OSD.
Відкрити образ RBD (для цього потрібні права на пул і сам образ).

«Error opening» зазвичай виникає через:

Неправильний або відсутній keyring/ключ у конфігурації сховища Proxmox.
Несумісність імені клієнта: ключ правильний, але для іншого імені клієнта.
Caps не дозволяють операцію (тільки читання, а ви створюєте образ; відсутній profile rbd; немає доступу до метаданих rbd_children тощо).
Монітори недоступні з одного вузла (маршрутизація, фаєрвол, неправильний mon_host, плутанина IPv6/IPv4).
Різниця в конфігурації Ceph між вузлами (на одному вузлі застарілий /etc/ceph/ceph.conf або неправильний fsid).
Права доступу до файлу keyring на диску: root може читати, але процес запущений від іншого користувача (поширено у кастомних інструментах; рідше в стандартному Proxmox).

Найшвидший спосіб припинити здогадки — відтворити ті самі операції відкриття з проблемного вузла за допомогою CLI rbd з тією ж ідентичністю та keyring.
Якщо rbd ls працює, але rbd info pool/image падає — ви дивитесь на несумісність caps. Якщо нічого не працює — починайте з моніторів і keyring.

Жарт №1: «Error opening» — це те, що Ceph каже, коли йому занадто чемно сказати «ваш keyring — відстій».

Швидкий план діагностики (перевірки 1/2/3)

Це порядок дій, який найшвидше завершує інциденти. Не той, що надає емоційне задоволення.

1) Підтвердьте, що з проблемного вузла можна дістатися до моніторів і аутентифікуватися

Якщо з’єднання з моніторами або cephx автентифікація не працює, нічого іншого не має значення. Виправляйте це спочатку.
Використайте ceph -s та ceph auth get client.X, де це доречно.

2) Підтвердьте, що Proxmox використовує той keyring, який ви думаєте

Перевірте /etc/pve/storage.cfg та шлях до keyring для кожного сховища (або вбудований ключ).
Переконайтеся, що файл існує на кожному вузлі (конфіг Proxmox розподілений, але keyring-файли локальні, якщо ви їх не синхронізували).

3) Перевірте caps щодо пулу та операції

Перелічіть caps: ceph auth get client.pve.
Тестуйте командами rbd, що імітують невдалу дію: rbd ls, rbd info, rbd create, rbd snap ls.

4) Лише потім: гнатися за помилками в UI Proxmox, логами qemu та крайніми випадками

Перегляньте логи завдань і journalctl для pvedaemon, pveproxy та qemu-server.
Більшість інцидентів «error opening» — це автентифікація/caps/конфіг. Екзотика існує, але вона не перша підозра.

Цікаві факти та контекст (бо минуле досі працює в проді)

Ceph cephx автентифікація створена, щоб уникати спільних глобальних секретів. Ключі можна обмежувати до пулів та операцій, тому caps мають велике значення.
Початкова аудиторія RBD — хмарні платформи. Модель «образ + снапшот + клон» дуже орієнтована на ВМ, тому Proxmox і OpenStack швидко її підхопили.
Proxmox зберігає конфіг кластера в розподіленій файловій системі. /etc/pve спільний між вузлами, але локальні файли як /etc/ceph/ceph.client.pve.keyring не реплікуються автомагічно.
Історично багато розгортань використовували client.admin всюди. Це «працює», поки не стане головним болем для аудиту та збільшувачем серйозності інцидентів.
Синтаксис caps еволюціонував. Старі дописи в блогах показують застарілі підходи; сучасний Ceph віддає перевагу profile rbd плюс явне обмеження пулом.
Монітори Ceph — це шлюз консистентності. Можна мати здорові OSD і все одно провалити відкриття RBD, якщо квора моніторів або досяжність з одного вузла зламана.
Відкриття RBD може вимагати метаданних операцій. Навіть читання може вимагати доступу до метаданих пулу (та залежно від функцій — до omap-ключів). «Я дав тільки читання» може виявитися надто суворим.
Відкриття конфігурації Ceph має кілька шляхів. Змінні середовища, шляхи за замовчуванням і явні прапори можуть призвести до ситуації «в моєму шеллі працює», але в задачах Proxmox — ні.

Поширені симптоми: що ви побачите і де

Proxmox може показувати той самий корінний збій через кілька шарів. Вивчіть патерни:

Лог завдання Proxmox: «rbd: error opening» під час створення диска, прикріплення, снапшоту, міграції або запуску ВМ.
Не вдається стартувати QEMU: VM не стартує; логи qemu згадують неможливість відкрити образ RBD.
Помилки CLI при мапінгу: rbd map повертає «permission denied» або «error connecting to the cluster».
Підказки зі сторони Ceph: логи MON показують помилки автентифікації; логи OSD — відхилені операції; але часто Ceph мовчить, якщо не підняти рівні дебагу.
Поводження залежно від вузла: Один вузол Proxmox має доступ до RBD; інший — ні. Це кричить «локальний keyring/конфіг різниться».

Практичні завдання: команди, виводи та рішення (12+)

Мета цих завдань — перетворити розпливчасті помилки UI на чіткі рішення. Виконуйте їх спочатку з проблемного вузла, потім з відомо робочого для порівняння.

Task 1: Підтвердьте, що Ceph кластер досяжний і ви не женетеся за привидами

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

Що це означає: Це підтверджує, що CLI може говорити з моніторами і автентифікуватися, використовуючи ту конфігурацію/ключ, яку бере ваш шелл.

Рішення: Якщо це падає на проблемному вузлі, але працює в інших — виправте доступ до моніторів і локальну конфігурацію Ceph перед тим, як лізти в Proxmox.

Task 2: З’ясуйте, що Proxmox вважає вашим 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

Що це означає: Proxmox намагатиметься підключитися до цих IP моніторів, аутентифікуватися як client.pve, використовуючи той keyring-файл.

Рішення: Якщо keyring відсутній або вказує на файл, якого немає на деяких вузлах — ви знайшли корінь проблеми.

Task 3: Перевірте, що файл keyring існує на цьому вузлі і доступний для читання

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

Що це означає: Файл існує і тільки root може його читати, що нормально для Proxmox.

Рішення: Якщо він відсутній на одному вузлі — скопіюйте його безпечно або відтворіть. Якщо права надто відкриті — виправте; неохайні секрети стають інцидентами.

Task 4: Підтвердьте, що keyring містить очікуване ім’я клієнта

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"

Що це означає: Заголовок секції має збігатися з ім’ям користувача, яке використовує Proxmox (без префіксу client. в storage.cfg).

Рішення: Якщо в файлі вказано [client.admin], а в storage.cfg — username pve, Proxmox не зможе автентифікуватися.

Task 5: Тестуйте доступ до RBD явно, використовуючи ту ж ідентичність, що й 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

Що це означає: Аутентифікація працює і користувач може перерахувати образи в пулі.

Рішення: Якщо перелік працює, але Proxmox все ще падає при відкритті — проблема, ймовірно, в правах на рівні образу/функцій або ви використовуєте інший пул/ім’я образу, ніж думаєте.

Task 6: Відтворіть відкриття конкретного образу (найкорисніше для «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

Що це означає: Якщо це вдається, «open» працює на рівні RBD. Proxmox має в змозі запустити VM, якщо не використовуються інші облікові дані/конфіг.

Рішення: Якщо це падає з «permission denied», ваші caps недостатні для метаоперацій або ви націлені на інший пул.

Task 7: Підтвердьте caps для користувача клієнта (не здогадуйтеся)

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

Що це означає: Це авторитетна інформація всередині Ceph (не те, що може лежати в keyring-файлі на вузлі).

Рішення: Якщо caps не включають цільовий пул — виправте caps. Якщо ключ відрізняється від того, що в keyring-файлі — оновіть файл всюди.

Task 8: Перевірте конфіг Ceph, який Proxmox буде неявно використовувати

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

Що це означає: Неправильний fsid або відсутній/неправильний mon_host можуть змусити вузол говорити з неправильним або жодним кластером.

Рішення: Якщо це різниться між вузлами — уніфікуйте. Розділення конфігурації — типова причина «вчора працювало» без реальних змін.

Task 9: Підтвердьте досяжність моніторів з проблемного вузла (маршрутизація/фаєрвол)

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!

Що це означає: Ceph MON використовує 3300 (msgr2) і іноді 6789 (легасі). Ви маєте мати зв’язок хоча б з тим, що використовує ваш кластер.

Рішення: Якщо це падає тільки на одному вузлі — виправте фаєрвол/маршрутизацію/VLAN/MTU. Не «виправляйте» автентифікацію, щоб компенсувати мережеві проблеми.

Task 10: Дістаньте лог задачі Proxmox, де міститься помилка

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

Що це означає: Це підтверджує точні аргументи, які QEMU використав, включно з id=pve та шляхом до keyring. Це — золото.

Рішення: Виконайте еквівалентну команду RBD вручну з тими ж параметрами. Якщо вона падає — це не «проблема Proxmox».

Task 11: Переконайтеся, що Proxmox вказує QEMU правильний 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

Що це означає: Proxmox може генерувати/використовувати /etc/pve/ceph.conf. Він може відрізнятися від /etc/ceph/ceph.conf.

Рішення: Якщо ваші CLI тести використовують /etc/ceph/ceph.conf, а QEMU — /etc/pve/ceph.conf, уніфікуйте їх або тестуйте з тим же --conf.

Task 12: Повторіть тест з тим же конфігом, який використовував QEMU

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

Що це означає: Це звужує коло підозр. Ранній успіх міг бути через інший конфіг (інший кластер, інші монітори, інші налаштування автентифікації).

Рішення: Перегляньте /etc/pve/ceph.conf і виправте його або перестаньте його використовувати. Послідовність краща за витонченість.

Task 13: Підтвердьте, з яким кластером ви спілкуєтесь (саніті-чек fsid)

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

Що це означає: Якщо fsid відрізняється від очікуваного — ви автентифікуєтесь проти іншого Ceph-кластера (або старого лабораторного залишку).

Рішення: Виправте конфіг і перезапустіть потрібні сервіси; не «додавайте ще монів» в обидва кластери й не надійтеся.

Task 14: Виправте caps для клієнта Proxmox RBD (типова безпечна схема)

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

Що це означає: Ви даєте моніторам відповідні права для RBD і даєте доступ до пулу на OSD. Це здравий замисел для VM-дисків в одному пулі.

Рішення: Якщо у вас кілька пулів, які використовує Proxmox, додайте кожен пул явно. Уникайте широкого allow *, якщо не любите пояснювати це потім.

Task 15: Оновіть (або створіть) keyring-файл послідовно на всіх вузлах

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

Що це означає: Ви пишете авторитетний ключ/права на файлову систему вузла. Повторіть на кожному вузлі або розподіліть безпечно.

Рішення: Якщо лише один вузол мав застарілий keyring — це усуне вузлові «error opening».

Task 16: Перевірте, чи здорова дефініція сховища Proxmox

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

Що це означає: Для RBD ємність може показуватися як 0 залежно від налаштувань, але сховище має бути active.

Рішення: Якщо воно неактивне або показує помилки — ще раз перевірте mon_host, username і шлях до keyring у storage.cfg.

Модель автентифікації Ceph у Proxmox: клієнти, keyring, caps та де Proxmox ховає налаштування

Імена клієнтів: найпоширеніша «підніжка» — однословна невідповідність

Користувачі Ceph називаються як client.pve, client.admin, client.proxmox. У Proxmox у storage.cfg ви часто вказуєте
username pve, що Proxmox трактує як client.pve.

Шаблони невідповідностей:

Невідповідність заголовка keyring: файл містить [client.proxmox], а Proxmox використовує pve. Автентифікація провалюється.
Невідповідність ключа: заголовок правильний, але ключ від старої ротації. Автентифікація провалюється.
Невідповідність caps: автентифікація вдається, але операції провалюються під час open/create/snapshot.

Розташування keyring: спільний конфіг, локальні секрети

Розподілена ФС Proxmox спокушає думати, що все у конфігурації реплікується. Ні.
/etc/pve/storage.cfg реплікується. Ваш keyring у /etc/ceph — звичайний файл.

Ось чому «працює на node1, падає на node3» відбувається так часто:

Ви додали сховище через UI один раз — це оновило /etc/pve/storage.cfg по кластеру.
Ви скопіювали keyring тільки на один вузол (або скопіювали іншу версію).
Proxmox з радістю розміщує VM на вузлі, який не може автентифікуватися, і ви отримуєте «error opening».

Caps: «profile rbd» — базова норма, обмеження пулом — запобіжна рейка

Для використання RBD у Proxmox оптимальна схема така:

mon = "profile rbd", щоб клієнт міг запитувати потрібні мапи й метадані, пов’язані з RBD.
osd = "profile rbd pool=<poolname>", щоб клієнт мав доступ до образів у конкретному пулі.

Якщо ви використовуєте кілька пулів (наприклад, vmdata, fast-ssd, templates), ви або:

Надаєте кілька рядків для пулів (окремі клієнти — чистіше), або
Приймаєте ширші caps і миритеся з компромісами безпеки.

Proxmox і `/etc/pve/ceph.conf`: тонкий розрив конфігів

Proxmox може підтримувати Ceph-конфіг під /etc/pve/ceph.conf, і процеси QEMU, запущені Proxmox, можуть посилатися саме на нього.
Тим часом ваші shell-команди можуть брати /etc/ceph/ceph.conf за замовчуванням. Якщо вони різняться — ви витратите години на доведення протилежного.

Визначте одне джерело правди і робіть його послідовним. Якщо Proxmox використовує /etc/pve/ceph.conf, тримайте його в порядку і синхронізованим з реальним кластером.

Цитата про надійність, якій варто довіряти

Парафраз думки Джона Оллспо (операції/надійність): «Інциденти виникають через звичайну роботу й побутові рішення, а не лише через рідкісну некомпетентність.»

Типові помилки: симптом → корінь проблеми → виправлення

1) Симптом: Працює на одному вузлі, падає на іншому з «error opening»

Корінь: Файл keyring відсутній або відрізняється на проблемному вузлі (або різний ceph.conf).

Виправлення: Переконайтеся, що keyring і конфіг існують і співпадають на кожному вузлі.

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

Рішення: Хеші не співпадають між вузлами? Стоп. Уніфікуйте. Не продовжуйте дебагувати вищі рівні.

2) Симптом: «(13) Permission denied» при старті ВМ або створенні диска

Корінь: Caps занадто вузькі для того, що робить Proxmox (створення, снапшот, клон), або неправильне обмеження пулом.

Виправлення: Оновіть caps, щоб включити потрібний пул і profile rbd. Перевірте за допомогою 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

Рішення: Це підтверджує, що справа в caps, а не в крихкій конфігурації ВМ. Виправте caps, потім перевірте створення й видаліть тестовий образ.

3) Симптом: «no keyring found» або «failed to load keyring» у логах

Корінь: Неправильний шлях у storage.cfg, або файл існує, але неправильні права/контекст SELinux/AppArmor (рідко в дефолтному Proxmox).

Виправлення: Виправте шлях; використовуйте абсолютний шлях; встановіть 0600 root:root.

4) Симптом: «error connecting to the cluster» або таймаути підключення до MON

Корінь: Неправильні IP моніторів у storage.cfg/ceph.conf, фаєрвол блокує 3300/6789, або DNS/IPv6 несумісність.

Виправлення: Використовуйте стабільні адреси моніторів; валідуйте досяжність; уникайте імен хостів, якщо DNS ненадійний.

5) Симптом: RBD list працює, але open падає для деяких образів

Корінь: Образ у іншому пулі, або функції образу вимагають операцій, які блокує ваші caps, або ім’я образу помилкове (описка, застаріла посилання після перейменування).

Виправлення: Перевірте точний пул/образ; запустіть rbd info і rbd snap ls з тією ж ідентичністю, що й Proxmox.

6) Симптом: Після ротації ключів старі ВМ не стартують

Корінь: Один вузол досі має старий keyring; Proxmox запланував запуски там; ви отримуєте «error opening».

Виправлення: Катайте оновлення ключів атомарно по вузлах, потім перевірте на невеликій кількості стартів/міграцій.

Жарт №2: Ротація ключів схожа на користування зубною ниткою — всі погоджуються, що це корисно, і майже ніхто не робить це у запланований час.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія мала кластер Proxmox з Ceph RBD для дисків VM. Вони додали новий вузол, приєднали його до кластера Proxmox і вважали справу зробленою.
Наступного ранку планове обслуговування спричинило декілька міграцій ВМ на новий вузол.

Половина мігрованих ВМ не повернулась. Proxmox показував ту саму тупу помилку: «error opening».
Ceph був здоровий. Сховище було визначене в /etc/pve/storage.cfg, тож команда припустила: «конфіг сховища реплікувався, отже доступ реплікувався».

Це припущення стало причиною інциденту. Новий вузол не мав /etc/ceph/ceph.client.pve.keyring. Інші вузли мали.
Proxmox UI зробив ситуацію гіршою, бо був послідовним: однакова назва сховища, той самий пул, ті самі монітори, однакова помилка.

Виправлення було неефектним: роздати keyring на всі вузли, перевірити хеші, потім перезапустити старти.
Дія після розбору була навіть більш прозаїчною: чекліст при приєднанні вузла з пунктом «ключі Ceph присутні і перевірені».

Міні-історія 2: Оптимізація, що пішла не так

Інша організація хотіла зменшити площу ураження, тому створила окремі Ceph-користувачі для різних Proxmox-кластерів і агресивно мінімізувала caps.
Гарна ідея. Але вони зайшли занадто далеко: дали лише права читання користувачу, якого Proxmox також використовував для операцій зі снапшотами і клонуванням.

Все було нормально тижнями, бо повсякденні читання/записи VM зазвичай працювали — доки pipeline шаблонів не запустився на повну.
Раптом задачі провалювались з «error opening» і «permission denied», і команда ганялася за мережею, бо збої були періодичні.

Реальна причина була в тому, що деякі операції вимагали записів метаданих (створення снапшоту, клонування, flatten), які блокували їхні caps.
Збої були періодичними, бо ці операції запускались періодично.

Вони виправили це, розділивши обов’язки: один Ceph-клієнт для «runtime I/O VM» з чітко обмеженим доступом до пулу,
інший — для «керування образами» під автоматизацією, з додатковими правами і більш суворим контролем операцій.
Least privilege вижив. Просто його потрібно було підлаштувати під реальні робочі процеси, а не під побажання.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Команда фінансових послуг мала звичку, яка виглядала майже комічно: на кожному вузлі був невеликий локальний скрипт, що щодня перевіряв доступ клієнта Ceph.
Він запускав ceph -s, rbd ls і rbd info проти відомого образу, використовуючи точні креденшали, які використовував Proxmox.
Результати логувалися локально і також піднімався простий метрик «ok/fail».

В один день адміністратор Ceph провів ротацію ключів у вікні змін. Зміна була коректною, caps були в порядку, кластер Ceph лишився здоровим.
Але один вузол Proxmox пропустив оновлення ключа через тимчасовий збій менеджменту конфігурації.

Їхня щоденна перевірка виявила це за кілька годин — до того, як планове обслуговування перемістило навантаження на зламаний вузол.
Замість простою — у них був тикет: «Node pve7 fails RBD open using client.pve.» Ремедіація — синхронізація keyring і повторна перевірка.

Нічого героїчного не сталося. Ніхто не отримав виклик. Ось як виглядає «reliability engineering» у хороший день: менше історій, щоб їх розповідати.

Чеклісти / покроковий план

Чекліст A: Коли VM не стартує з «error opening»

З проблемного вузла візьміть точну помилку та параметри з логів (journalctl -u pvedaemon).
Витягніть id=, keyring=, пул, ім’я образу та шлях conf=.
Запустіть rbd --conf ... info pool/image --id ... --keyring ....
Якщо автентифікація падає: перевірте існування keyring, його коректність та заголовок імені клієнта.
Якщо «permission denied»: перевірте caps та обмеження пулом; виправте caps; повторіть тест.
Якщо з’єднання з моніторами падає: перевірте порти 3300/6789; підтвердьте mon_host та маршрутизацію/MTU.
Після виправлення повторіть старт VM і перевірте читання/запис.

Чекліст B: Додавання нового вузла Proxmox до Ceph-backed кластера

Встановіть пакети Ceph client відповідно до вашої версії Proxmox.
Скопіюйте /etc/ceph/ceph.conf (або переконайтеся, що /etc/pve/ceph.conf правильний і використовується послідовно).
Скопіюйте потрібні keyring-файли: зазвичай /etc/ceph/ceph.client.pve.keyring.
Перевірте права файлів: 0600 root:root для keyring.
Запустіть: ceph -s і rbd -p <pool> ls --id pve --keyring ....
Тільки після цього дозволяйте міграції/HA на цей вузол.

Чекліст C: Безпечніша ротація ключів для Proxmox RBD клієнтів

Створіть або оновіть Ceph auth запис (ceph auth get-or-create / ceph auth caps), зберігши обмеження пулом.
Експортуйте оновлений keyring-файл.
Розподіліть keyring на всі вузли Proxmox (атомарно, якщо можливо).
Перевірте, що хеші співпадають між вузлами.
Запустіть RBD open тести з кожного вузла, використовуючи той же --conf, що і QEMU.
Проведіть канарі: запустіть по одній VM на вузол, виконайте міграцію, створіть снапшот якщо це використовується.
Тільки після цього вважайте ротацію завершеною.

Команди, що допомагають автоматизувати перевірку чеклістів

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

Рішення: Якщо це працює на кожному вузлі — ви виключили більшість причин «error opening», пов’язаних з автентифікацією/ключами.

Питання та відповіді (FAQ)

1) Чому Proxmox показує «error opening», а не справжню помилку Ceph?

Бо помилка пробивається через шари QEMU/librbd і підсумовується. Детальна причина часто є у рядках journalctl, де видно
«permission denied», «no such file» або помилки з’єднання. Завжди дивіться логи того вузла, що не вдався.

2) Я можу виконати `ceph -s` успішно — чому Proxmox падає?

Ваш шелл може використовувати інший конфіг-файл (/etc/ceph/ceph.conf) і інший ключ (client.admin через дефолтний keyring).
Proxmox може використовувати /etc/pve/ceph.conf і client.pve. Тестуйте з тим же --conf, --id та --keyring, які ви бачите в логах Proxmox.

3) Чи можу я просто використовувати `client.admin`, щоб «залагодити» проблему?

Можете, і це «працюватиме», але це погана практика. Це розширює площу ураження і ускладнює аудит. Використовуйте виділеного клієнта з обмеженням пулом та profile rbd.
Зберігайте client.admin для адміністративних задач, а не для рутинного I/O VM.

4) Які мінімальні caps для використання Proxmox RBD?

Зазвичай: mon "profile rbd" і osd "profile rbd pool=<pool>". Якщо ви використовуєте додаткові робочі процеси (снапшоти, клонування, flatten),
зазвичай достатньо profile rbd, але потрібно переконатися, що кластер і клієнти підтримують потрібні операції. Валідовуйте операцію тестом з тією ж ідентичністю.

5) Чому це падає лише під час міграції або створення снапшоту?

Бо міграції та снапшоти використовують інші виклики API. Перелік образів — не те саме, що відкриття образу з певними функціями, створення снапшоту або клонування.
Якщо помилка виникає під час цих операцій — спочатку підозрюйте несумісність caps.

6) Де Proxmox зберігає секрети Ceph?

Proxmox зберігає опис сховища в /etc/pve/storage.cfg. Сам ключ зазвичай у keyring-файлі під /etc/ceph, на який посилаються шляхом.
Деякі налаштування можуть вбудовувати секрети інакше, але патерн «локальний ключ на вузлі» — типовий і саме через нього відбуваються вузлові невідповідності.

7) Як відрізнити проблему з моніторами від проблеми з автентифікацією?

Якщо ви бачите таймаути і «error connecting to the cluster», перевірте мережеву досяжність до портів MON (3300/6789) і підтвердіть mon_host.
Якщо ви швидко бачите «permission denied», монітори доступні і ймовірно проблема в автентифікації/caps.

8) Чи потрібно перезапускати сервіси Proxmox після виправлення keyring або caps?

Часто ні; нові задачі підхоплюють оновлений keyring. Але якщо ви змінили якийсь конфіг, що використовується QEMU або оновили дефініцію сховища,
перезапуск pvedaemon і повтор виконання задачі може позбутися застарілих станів. Дійте цілеспрямовано; не перезавантажуйте вузли «лікувально».

9) Який найшвидший безпечний тест, щоб підтвердити виправлення?

Запустіть rbd info pool/image з тим же --conf, --id та --keyring, що й QEMU, з вузла, який падав.
Потім стартуйте одну VM, що використовує цей образ. Якщо ви залежать від снапшотів/клонів — також протестуйте одну з тих операцій.

10) Чи може це бути баг Ceph або пошкодження даних?

Може, але якщо кластер здоровий і помилка — «permission denied» або «keyring not found», то це не корупція даних.
Почніть з автентифікації/конфігурації; 95% інцидентів «error opening» — це самостійні паперові порізи.

Висновок: наступні кроки, які можна зробити сьогодні

Якщо ви хочете, щоб «error opening» перестав бути постійним гостем вашого on-call життя, зробіть три речі:

Уніфікуйте, який файл конфігурації використовує QEMU (/etc/pve/ceph.conf vs /etc/ceph/ceph.conf) і зробіть їх однаковими на всіх вузлах.
Використовуйте виділеного Ceph-клієнта (наприклад, client.pve) з обмеженими правами profile rbd по пулу. Припиніть використовувати client.admin для рутинного I/O VM.
Зробіть keyring першокласним артефактом розгортання: розповсюджуйте їх на всі вузли, перевіряйте хеші і валідовуйте доступ автоматизованим тестом rbd info.

Хороша новина: коли ви почнете ставитись до keyring і caps як до продакшен-конфігурації (а не як до племінного знання), Ceph стане передбачувано нудним. Оце й є мета.