Невозможно запустить пул libvirt. Ошибка Duplicate hash table key

Проблема

После сбоя в хранилище Ceph невозможно выполнять операции с виртуальными машинами (ВМ): создание, удаление, переустановка ОС на ВМ. При этом на одном или нескольких узлах кластера наблюдаются следующие проблемы:

• пул libvirt находится в состоянии inactive:
  Пример статуса пулов

  #virsh pool-list --all
   Name State Autostart
  -----------------------------------
   cloud_hdd inactive yes
  

• пул libvirt не запускается командой virsh pool-start. При попытке запуска возникает ошибка:
  
  Пример ошибки при попытке запуска пула

  # virsh pool-start cloud_hdd
  error: Failed to start pool cloud_hdd
  error: internal error: Duplicate hash table key 'cloud_hdd/15139_vm733939'

• в логах libvirtd наблюдаются ошибки получения метаданных от пула RBD и получения данных образа:
  

  Feb 06 12:56:25 node20853.dev.example.com libvirtd[3250509]: 2026-02-06T12:56:25.279+0300 7f8dd2ffd700 -1 librbd::image::RefreshRequest: failed to retrieve pool metadata: (110) Connection timed out
  Feb 06 12:56:25 node20853.dev.example.com libvirtd[3250509]: 2026-02-06T12:56:25.279+0300 7f8dd2ffd700 -1 librbd::ImageState: 0x7f8da00a70a0 failed to open image: (110) Connection timed out

• не запускаются ВМ, которые используют образы из проблемного пула. На запущенных ВМ с проблемным образом внутри гостевой ОС возникает ошибка No bootable device.

Причина

Ошибка Duplicate hash table key возникает на стороне libvirt. 

При запуске пула libvirt обращается к кластеру Ceph через библиотеку librados, получает список RBD-образов и строит внутреннюю таблицу данных, где каждому имени образа соответствует уникальная запись (ключ). Нормальное поведение — когда каждое имя встречается один раз. В указанном случае в Ceph физически присутствуют два RBD-образа с одинаковым именем. Когда libvirt получает такой список, он пытается добавить в свою таблицу два идентичных ключа. Это нарушает логику работы.

Диагностика

Чтобы подтвердить причину проблемы:

1. Подключитесь к узлу кластера по SSH. Подробнее о подключении по SSH см. в статье Настройка рабочего места.
2. Получите названия всех пулов libvirt на узле кластера:

   virsh pool-list --all

   Пример вывода

   [root@node20857 ~]# virsh pool-list --all
    Name State Autostart
   -----------------------------------
    cloud_hdd inactive yes
    cloud_ssd active yes

3. Выполните попытку запуска неактивного пула:
   

   virsh pool-start <название_пула>

   Признак проблемы: вывод содержит следующую ошибку:

   error: Failed to start pool cloud_hdd
   error: internal error: Duplicate hash table key 'cloud_hdd/15139_vm733939'

4. Подключитесь к сетевому хранилищу Ceph.
   
5. Убедитесь, что образ проблемной ВМ дублируется:

   rbd ls <пул_rbd>|grep <имя_ВМ>

   Пример вывода

   [root@node20833 ~]# rbd ls cloud_hdd|grep vm733939
   15139_vm733939
   15139_vm733939

   Наличие двух одинаковых строк в выводе подтверждает причину проблемы.

Решение

Чтобы решить проблему:

1. Подключитесь к Ceph.
2. Удалите повреждённый образа дубля.
3. Запустите пул на всех узлах кластера.

Если оба образа повреждены, для восстановления данных обратитесь к вашему системному администратору.

Подготовка

Проверьте наличие диска ВМ на узле кластера:

1. Подключитесь к серверу с платформой по SSH. Подробнее о подключении по SSH см. в статье Настройка рабочего места.
2. Определите внутреннее имя и узел кластера целевой ВМ:
   

   docker exec vm_back vssh -a 'virsh list --all | grep <имя_ВМ>

   Пример вывода

   [root@VMmanager10 ~]# docker exec vm_back vssh -a 'virsh list --all | grep grayish-indicolite '
   multiple errors:
   node 6:
   Node 7:
    5    28_grayish-indicolite    running

   Пояснения:
   • 7 — ID узла кластера;
   • 28_grayish-indicolite — внутреннее имя ВМ.
3. Подключитесь к узлу кластера с целевой ВМ по SSH. Подробнее о подключении по SSH см. в статье Настройка рабочего места.
4. Выполните команду: 
   

   virsh domblklist <внутреннее_имя_ВМ>

   Пример вывода, когда диск присутствует

   virsh domblklist 28_grayish-indicolite
    Target     Source
   ---------------------------------------------------------------
    vda        cloud_hdd/13516_vm715346

   Если диск присутствует, высокая вероятность, что один из образов доступен.

Выполните точную диагностику состояния образов:

virsh shutdown <vm_name>

virsh destroy <vm_name>

1. Подключитесь к сетевому хранилищу Ceph.
2. Переименуйте один из образов:

   rbd rename <пул_rbd>/<название_образа> <пул_rbd>/<название_образа>_rename
   

   Пояснения:

   • <пул_rbd>, <название_образа> — указаны в п.5 раздела «Диагностика».
   Пример вывода

   rbd rename cloud_hdd/13516_vm715346 cloud_hdd/13516_vm715346_rename

3. Проверьте образы целевой ВМ:

   rbd ls <пул_rbd>|grep <имя_ВМ>

   Пример вывода

   [root@node20833 ~]# rbd ls cloud_hdd | grep vm715346
   13516_vm715346_rename
   13516_vm715346

   Ожидаемый результат: вывод содержит два разных имени.

4. Проверьте состояние каждого образа:

   rbd info <пул_rbd>/<название_образа>

   Если команда возвращает метаданные (размер, формат и т. д.), образ доступен. Если в выводе ошибка error opening image: (2) No such file or directory, образ повреждён.

   Пример вывода, когда образ доступен

   [root@node20833 ~]# rbd info cloud_hdd/13516_vm715346_rename
   rbd image '13516_vm715346_rename':
    size 80 GiB in 20480 objects
    order 22 (4 MiB objects)
    snapshot_count: 0
    id: 9bc1a0963ddfac
    block_name_prefix: rbd_data.9bc1a0963ddfac
    format: 2
    features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
    op_features:
    flags:
    create_timestamp: Sat Feb 7 12:36:46 2026
    access_timestamp: Sat Feb 7 19:35:07 2026
    modify_timestamp: Sat Feb 7 19:34:55 2026

   Пример вывода, когда образ повреждён

   [root@node20833 ~]# rbd info cloud_hdd/13516_vm715346
   rbd: error opening image 13516_vm715346: (2) No such file or directory

Выберите сценарий решения:

• переходите к разделу Один из образов доступен, если:
  • диск присутствует в выводе virsh domblklist;
  • один из образов в выводе rbd info возвращает метаданные, а второй — ошибку;
• переходите к разделу Оба образа повреждены, если:
  • диск отсутствует в выводе virsh domblklist;
  • оба образа возвращают ошибку error opening image: (2) No such file or directory в выводе rbd info;
• обратитесь к вашему системному администратору, если столкнулись с нетипичными сценариями:
  • диск присутствует, но оба образа повреждены (диск в конфигурации ВМ ссылается на несуществующий образ);
  • диск отсутствует, но один из образов доступен (образ в хранилище есть, но ВМ на него не ссылается).

Один из образов доступен

После выполнения шагов из раздела Подготовка вы подтвердили, что один из образов доступен.

Чтобы решить проблему:

1. Удалите повреждённый образ:

   rbd rm <пул_rbd>/<название_образа>

   Пример вывода

   [root@node20833 ~]# rbd rm cloud_hdd/13516_vm715346
   Removing image: 100% complete...done.

2. Переименуйте доступный образ обратно в исходное имя:

   rbd rename <пул_rbd>/<название_образа>_rename <пул_rbd>/<название_образа>

   Пример команды

   rbd rename cloud_hdd/13516_vm715346_rename cloud_hdd/13516_vm715346

3. Убедитесь, что отсутствуют дубли, и что название диска в конфигурации ВМ совпадает с названием образа в хранилище Ceph. Название диска получено в выводе команды virsh domblklist, п.4 раздела «Подготовка».
   Внимание!

   Если при переименовании допущена ошибка и итоговое имя образа в Ceph не соответствует имени диска в конфигурации ВМ, то при запуске ВМ не сможет подключить диск из Ceph. Внутри гостевой ОС это проявится как отсутствие загрузочного устройства: ошибка No bootable device.

   Выполните команду:

   rbd ls <пул_rbd> | grep <имя_ВМ>

   Ожидаемый результат: вывод содержит одну строку.

   Пример вывода

   [root@node20833 ~]# rbd ls cloud_hdd|grep vm733939
   15139_vm733939

4. Подключитесь к узлу кластера по SSH. Подробнее о подключении по SSH см. в статье Настройка рабочего места.
5. Запустите пул libvirt:

   virsh pool-start <название_пула>

   Пример вывода

   [root@node20853 ~]# virsh pool-start cloud_hdd
   Pool cloud_hdd started

6. Убедитесь, что все пулы запущены:

   virsh pool-list --all

   Пример вывода

   [root@node20853 ~]# virsh pool-list --all
    Name State Autostart
   ---------------------------------
    cloud_hdd active yes
    cloud_ssd active yes

   Если пул не запустился или ошибка указывает на другой проблемный образ, это означает, что в пуле есть ещё один дублирующийся образ. В этом случае повторите процедуру с п. 1 для нового образа, указанного в ошибке.

7. Запустите ВМ через веб-интерфейс или командой:

   virsh start <внутреннее_имя_ВМ>

8. Подключитесь к серверу с платформой по SSH. Подробнее о подключении по SSH см. в статье Настройка рабочего места.
9. Запустите пул libvirt на всех узлах кластера. Для этого на сервере с платформой выполните команду:

   docker exec vm_back vssh -a 'virsh pool-start <пул_rbd>'

   Пример вывода

   [root@VMmanager10 ~]# docker exec vm_back vssh -a 'virsh pool-start cloud_hdd'
   multiple errors:
   node 6: error: Failed to start pool cloud_hdd
   error: Requested operation is not valid: storage pool 'cloud_hdd' is already active
   node 7:
   Pool cloud_hdd started

   Если на узле кластера нет такого хранилища, выполнение указанной команды завершится ошибкой:

   node <id>: error: failed to get pool '<pool_name>'
   error: Storage pool not found: no storage pool with matching name '<pool_name>'

   Это нормальное поведение и не является проблемой.

10. Убедитесь, что в выводе нет следующей ошибки:

    error: Failed to start pool cloud_hdd
    error: internal error: Duplicate hash table key 'cloud_hdd/15139_vm733939'

    Если ошибка присутствует, это означает, что в пуле остались проблемные ВМ с дублирующимися образами. Повторите процедуру для всех ВМ, указанных в выводе ошибки.
    Ожидаемый результат: 
    
    • пулы на всех узлах целевого кластера запущены без ошибки Duplicate hash table key;
    • на каждом узле кластера при запуске пула появляется сообщение:

      storage pool 'cloud_hdd' is already active

Оба образа повреждены

После выполнения шагов из раздела Подготовка вы подтвердили, что оба образа повреждены.

Если данные на диске ВМ представляют ценность, обратитесь к системному администратору для попытки восстановления повреждённых RBD-образов. Восстановление образов в Ceph — отдельная задача, которая требует специальных знаний и инструментов, и выходит за рамки текущей инструкции.

Если восстановление невозможно или не требуется, выполните следующие шаги:

1. Подключитесь к сетевому хранилищу Ceph.
2. Переименуйте оба повреждённых образа:
   

   rbd rename <pool_name>/<image_name_1> <pool_name>/<image_name_1>_bad_image
   rbd rename <pool_name>/<image_name_2> <pool_name>/<image_name_2>_bad_image_2

   Пояснения к команде:

   • _bad_image, _bad_image_2 — суфиксы нового имени повреждённых образов.
   Пример вывода

   rbd rename cloud_hdd/15139_vm733939 cloud_hdd/15139_vm733939_bad_image
   rbd rename cloud_hdd/15139_vm733939_rename cloud_hdd/15139_vm733939_bad_image_2

   Это необходимо, чтобы:
   • исключить конфликт дублирующихся имён при запуске пула;
   • предотвратить случайное подключение ВМ к одному из образов;
   • сохранить образы для возможного восстановления системным администратором.
3. Проверьте состояние каждого образа:
   

   rbd info <pool_name>/<image_name>_bad_image
   rbd info <pool_name>/<image_name>_bad_image_2

   Если оба вывода содержат error opening image: (2) No such file or directory, образы нечитаемы.

4. Удалите оба повреждённых образа:
   
   Внимание!

   Если повреждённые образы требуются вашему системному администратору для восстановления данных, удаление не выполняется. Пропустите этот шаг и перейдите к п.6. Образы на этот момент уже переименованы и не блокируют запуск пула.

   rbd rm <pool_name>/<image_name>_bad_image
   rbd rm <pool_name>/<image_name>_bad_image_2

5. Подключитесь к узлу кластера по SSH. Подробнее о подключении по SSH см. в статье Настройка рабочего места.
6. Запустите пул libvirt на узле кластера:
   

   virsh pool-start <название_пула>

7. Подключитесь к серверу с платформой по SSH. Подробнее о подключении по SSH см. в статье Настройка рабочего места.
8. Запустите пул на всех узлах кластера:
   

   docker exec vm_back vssh -a 'virsh pool-start <название_пула>'

   Если на узле кластера нет такого хранилища, выполнение указанной команды завершится ошибкой:

   node <id>: error: failed to get pool '<pool_name>'
   error: Storage pool not found: no storage pool with matching name '<pool_name>'

   Это нормальное поведение и не является проблемой.
   Ожидаемый результат: пулы на всех узлах целевого кластера запущены без ошибки Duplicate hash table key.

9. Если образы были удалены в п. 5, создайте ВМ заново через веб-интерфейс платформы. Подробнее см. в статье Создание виртуальных машин.