Снимки дисков в состоянии "illegal"

1. Введение

Данная статья описывает исправление ошибок, которые можно обобщить как некорректное состояние слоёв диска и/или снимков ВМ со стороны домена хранения, либо базы данных Engine. Перед исправлением связанных с этим ошибок, настоятельно рекомендуется выполнить резервное копирование базы данных и виртуальной машины, либо диска(ов) ВМ, если невозможно сделать резервную копию ВМ.

Перед самостоятельным решением рекомендуется проконсультироваться с инженерами технической поддержки.

Резервную копию базы данных Engine можно выполнить по соответствующей инструкции в руководстве по резервному копированию и восстановлению Менеджера управления.

Резервную копию виртуальной машины рекомендуется делать на уровне операционной или файловой системы ВМ. Не рекомендуется делать резервную копию с использованием механизмов системы виртуализации zVirt, особенно с использованием снимков ВМ (CyberBackup, NetBackup, Veeam, Bacula), так как это может усложнить дальнейшую работу по исправлению.

Перед проведение работ по исправлению ошибок, необходимо предоставить инженерам технической поддержки всю собранную информацию из пункта Сбор данных.

Для самостоятельного исправления ошибок необходимо понимание слоёв дисков. Вкратце: каждый диск представляет из себя группу слоёв диска. Когда вы создаёте новый диск, у него будет 1 слой, при каждом создании нового моментального снимка, у диска появляется новый слой, а при удалении снимка, слой соответственно удаляется. Каждый слой диска закреплён за снимком, в котором он был создан. Когда ВМ только создаётся, у неё есть 1 снимок — Active VM, это активный снимок, на котором сейчас работает ВМ. Более подробное описание вы можете найти в техническом справочнике.

2. Сбор данных

Основные источники данных для решения данной проблемы: база данных engine и дамп домена хранения, а также состояние LVM, если диск хранится в блочном хранилище iSCSI / FibreChannel.

В базе данных engine для работы будут нужны 2 таблицы: images и snapshots. Для подключения к базе данных, последовательно выполните команды в консоли Менеджера Управления:

su - postgres
psql engine

Для сбора информации о сниках ВМ, выполните следующий запрос:

SELECT snapshot_id, snapshot_type, status, description FROM snapshots WHERE vm_id='$VM_ID';

$VM_ID необходимо заменить на ID виртуальной машины, с которой испытываются проблемы. ID виртуальной можно найти в WEB-интерфейсе zVirt, для этого перейдите на вкладку Ресурсы Виртуальные машины Проблемная ВМ. На вкладке Общее будет ID ВМ.

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

SELECT snapshot_id, snapshot_type, status, description FROM snapshots WHERE vm_id='10248397-4367-436f-88eb-63b4c44a57fa';
             snapshot_id              | snapshot_type | status |   description
--------------------------------------+---------------+--------+-----------------
 7d429c79-93ba-4761-a1a0-ebb4e45a3436 | REGULAR       | OK     | First snapshot
 102a5552-fb49-463b-abff-124b8fbc248c | ACTIVE        | OK     | Active VM
 3368bbf7-3117-428b-94c8-1629b1598b8d | REGULAR       | OK     | Second snapshot

В данном выводе видно, что у ВМ присутствуют 2 снимка и активный слой, все снимки в состоянии OK, что говорит о том, что ошибок нет.

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

SELECT image_guid, parentid, imagestatus, vm_snapshot_id, volume_type, volume_format, active FROM images WHERE image_group_id='$DISK_ID';

$DISK_ID необходимо заменить на ID диска ВМ. ID диска можно найти в WEB-интерфейсе zVirt, для этого перейдите на вкладку Хранилище Диски и найдите диски проблемной ВМ. В столбце Код будет ID диска.

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

SELECT image_guid, parentid, imagestatus, vm_snapshot_id, volume_type, volume_format, active FROM images WHERE image_group_id='5adc6602-75b0-4719-857d-10f655e50bd0';
              image_guid              |               parentid               | imagestatus |            vm_snapshot_id            | volume_type | volume_format | active
--------------------------------------+--------------------------------------+-------------+--------------------------------------+-------------+---------------+--------
 597f40a1-5c39-483b-8ddb-9ff8bfcda313 | ab13dd45-12ad-4665-bee0-0ff87ced4225 |           1 | 102a5552-fb49-463b-abff-124b8fbc248c |           2 |             4 | t
 b049079e-88ec-4fa1-9337-cece7200a761 | 00000000-0000-0000-0000-000000000000 |           1 | 7d429c79-93ba-4761-a1a0-ebb4e45a3436 |           2 |             4 | f
 ab13dd45-12ad-4665-bee0-0ff87ced4225 | b049079e-88ec-4fa1-9337-cece7200a761 |           1 | 3368bbf7-3117-428b-94c8-1629b1598b8d |           2 |             4 | f
(3 rows)

В данном выводе есть 3 слоя диска: 2 относятся к снапшотам, а третий относится к активному слою. imagestatus=1 означает, что диск в порядке, а active=t что этот слой является активным. parentid указывает на слой, который является родительским для данного слоя. Первый и основной слой ВМ всегда имеет в качестве родительского слой с ID 00000000-0000-0000-0000-000000000000, исключения — тонкие клоны шаблонов. В данном случае можно выстроить цепочку слоёв:

00000000-0000-0000-0000-000000000000
b049079e-88ec-4fa1-9337-cece7200a761
ab13dd45-12ad-4665-bee0-0ff87ced4225
597f40a1-5c39-483b-8ddb-9ff8bfcda313

Далее нужно сделать дамп домена хранения. Это можно сделать с любого хоста, который входит в тот же Центр Данных, в котором работает (работала) проблемная ВМ. Для этого в консоли хоста выполните команду:

vdsm-tool -vvv dump-volume-chains $STORAGE_DOMAIN_ID

$STORAGE_DOMAIN_ID необходимо заменить на ID домена хранения, в котором находятся диски ВМ. ID домена хранения можно найти в WEB-интерфейсе zVirt на вкладке Хранилище Домены хранения Домен с диском. В поле ID и будет ID домена хранения.

Вывод дампа можно перенаправить файл для удобства отправки инженерам технической поддержки:

vdsm-tool -vvv dump-volume-chains 1499f56c-0a0f-43df-a3e9-9e8e613e559b > /root/storage_domain_dump.log

В дампе домена необходимо найти группу слоёв диска по его ID. Пример дампа по нужному диску:

image:    5adc6602-75b0-4719-857d-10f655e50bd0

         - b049079e-88ec-4fa1-9337-cece7200a761
            status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

         - ab13dd45-12ad-4665-bee0-0ff87ced4225
            status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

        - 597f40a1-5c39-483b-8ddb-9ff8bfcda313
            status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

Вывод состоит из указателя диска image: id и списка слоёв диска с пустой строкой в качестве разделителя. У каждого слоя указаны:

статус, где Status: OK означает нормальное состояние
тип тома, может быть LEAF, INTERNAL или SHARED. Тип слоя SHARED относится к шаблонам, нас в данном случае интересуют LEAF и INTERNAL. Различие заключается в том, что из слоя LEAF можно сделать дочерний слой (то есть исходный слой будет parent для нового слоя), а INTERNAL является защищённым от записи слоем и от него невозможно дальнейшее ветвление
формат диска cow или raw
состояние может быть корректным LEGAL и некорректным ILLEGAL
тип слоя SPARSE (тонкий диск) или PREALLOCATED(предразмеченный)
а также реальный размер и объём слоя

Вывод LVM нужен только в случае с блочным доменом хранения.

Информацию о состоянии LVM можно собрать также на любом хосте, входящем в тот же центр данных, что и проблемная ВМ. В консоли хоста выполните команду:

lvs --config 'devices {filter=["a/.*/"]}' -o +lv_tags | grep $DISK_ID

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

[root@srv1 ~]$ lvs --config 'devices {filter=["a/.*/"]}' -o +lv_tags | grep 5adc6602-75b0-4719-857d-10f655e50bd0
  597f40a1-5c39-483b-8ddb-9ff8bfcda313 1499f56c-0a0f-43df-a3e9-9e8e613e559b -wi-------    1.00g IU_5adc6602-75b0-4719-857d-10f655e50bd0,MD_302,PU_ab13dd45-12ad-4665-bee0-0ff87ced4225
  ab13dd45-12ad-4665-bee0-0ff87ced4225 1499f56c-0a0f-43df-a3e9-9e8e613e559b -wi-------    1.00g IU_5adc6602-75b0-4719-857d-10f655e50bd0,MD_301,PU_b049079e-88ec-4fa1-9337-cece7200a761
  b049079e-88ec-4fa1-9337-cece7200a761 1499f56c-0a0f-43df-a3e9-9e8e613e559b -wi-------    1.00g IU_5adc6602-75b0-4719-857d-10f655e50bd0,MD_300,PU_00000000-0000-0000-0000-000000000000

В данном выводе мы видим ID слоёв диска, домена хранения и самого диска, а также размер слоёв диска.

Всю перечисленную выше информацию необходимо предоставить инженерам технической поддержки для дальнейшего анализа и предложения пути решения проблемы. Для самостоятельно решения вы можете ознакомиться со сценариями проблем и их решением далее.

3. Примеры ошибок и их решение

3.1. Некорректное удаление записей из базы данных

3.1.1. Обнаружение

Данный сценарий является самым распространённым, суть ошибки заключается в том, что слой диска фактически (в домене хранения) удаляется, но остаётся записи в базе данных. Ошибка может сопровождаться сообщением:

Невозможно выполнить ВМ. ВМ выполняет операцию над моментальным снимком. Подождите, пока операция завершится, и повторите попытку.

А в WEB-интерфейсе zVirt в снимках ВМ будет такое состояние:

В базе данных при этом может наблюдаться следующий вывод:

снимки

SELECT snapshot_id, snapshot_type, status, description FROM snapshots WHERE vm_id='10248397-4367-436f-88eb-63b4c44a57fa';
	        snapshot_id              | snapshot_type | status |   description
--------------------------------------+---------------+--------+-----------------
 7d429c79-93ba-4761-a1a0-ebb4e45a3436 | REGULAR       | OK     | First snapshot
 102a5552-fb49-463b-abff-124b8fbc248c | ACTIVE        | OK     | Active VM
 3368bbf7-3117-428b-94c8-1629b1598b8d | REGULAR       | LOCKED | Second snapshot
(3 rows)

слои диска

SELECT image_guid, parentid, imagestatus, vm_snapshot_id, volume_type, volume_format, active FROM images WHERE image_group_id='5adc6602-75b0-4719-857d-10f655e50bd0';
              image_guid              |               parentid               | imagestatus |            vm_snapshot_id            | volume_type | volume_format | active
--------------------------------------+--------------------------------------+-------------+--------------------------------------+-------------+---------------+--------
 b049079e-88ec-4fa1-9337-cece7200a761 | 00000000-0000-0000-0000-000000000000 |           1 | 7d429c79-93ba-4761-a1a0-ebb4e45a3436 |           2 |             4 | f
 ab13dd45-12ad-4665-bee0-0ff87ced4225 | b049079e-88ec-4fa1-9337-cece7200a761 |           4 | 3368bbf7-3117-428b-94c8-1629b1598b8d |           2 |             4 | f
 597f40a1-5c39-483b-8ddb-9ff8bfcda313 | ab13dd45-12ad-4665-bee0-0ff87ced4225 |           2 | 102a5552-fb49-463b-abff-124b8fbc248c |           2 |             4 | t
(3 rows)

В представленном выводе мы видим, что снимок Second snapshot находится в заблокированном состоянии, как и соответствующий ему слой диска 597f40a1-5c39-483b-8ddb-9ff8bfcda313, а слой ab13dd45-12ad-4665-bee0-0ff87ced4225 имеет imagestatus=4, что и означает некорректное состояние.

Если при этом в дампе домена хранения отсутствует последний слой диска (597f40a1-5c39-483b-8ddb-9ff8bfcda313), то вы столкнулись с данным сценарием

image:    5adc6602-75b0-4719-857d-10f655e50bd0

  - b049079e-88ec-4fa1-9337-cece7200a761
    status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

  - ab13dd45-12ad-4665-bee0-0ff87ced4225
    status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

При этом при наличии несколько дисков, подключенных к ВМ, проблема может проявиться как на одном диске, так и нескольких. Если проблема проявилась на нескольких дисках, то решение необходимо применить ко всем дискам.

3.1.2. Решение

Вам необходимо внести следующие исправления в базу данных:

Удалить записи о ненужно снимке и слое диска
```
DELETE FROM snapshots WHERE snapshot_id='3368bbf7-3117-428b-94c8-1629b1598b8d';
DELETE FROM images WHERE image_guid='597f40a1-5c39-483b-8ddb-9ff8bfcda313';
```
Обратите внимание, мы удаляем записи именно со снимком Second snapshot и последний слой диска (который отсутствует в дампе домена хранения).
Отредактировать запись с предыдущим слоем:
```
UPDATE images SET active='t', imagestatus=1, vm_snapshot_id='102a5552-fb49-463b-abff-124b8fbc248c' WHERE image_guid='ab13dd45-12ad-4665-bee0-0ff87ced4225';
```
Здесь мы указываем, что предыдущий слой теперь активен и исправен, а также меняем связанный снимок на Active VM

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

3.2. Снимок удалён из БД, но присутствует в домене хранения

3.2.1. Обнаружение

Данный сценарий является обратным для первого, так как в этом сценарии диск фактически в домене присутствует, однако записи из базы данных о нём удалены, а у активного слоя некорректное состояние (illegal).

в данном сценарии решение существенно отличается в зависимости от типа хранилища: файловое (NFS) или блочное (iSCSI/FC), учтите это при самостоятельном решении проблемы.

В случае возникновения данной ошибки, в WEB-интерфейсе zVirt у слоя диска снимка Active VM некорректное состояние, а при попытке запуска может возникать ошибка, указывающая на некорректное состояние.

А в БД будет следующий вывод:

снимки

SELECT snapshot_id, snapshot_type, status, description FROM snapshots WHERE vm_id='10248397-4367-436f-88eb-63b4c44a57fa';
             snapshot_id              | snapshot_type | status |  description
--------------------------------------+---------------+--------+----------------
 7d429c79-93ba-4761-a1a0-ebb4e45a3436 | REGULAR       | OK     | First snapshot
 f05794b9-ecba-48a6-b847-4b95d902a860 | ACTIVE        | OK     | Active VM
(2 rows)

слои диска

SELECT image_guid, parentid, imagestatus, vm_snapshot_id, volume_type, volume_format, active FROM images WHERE image_group_id='5adc6602-75b0-4719-857d-10f655e50bd0';
              image_guid              |               parentid               | imagestatus |            vm_snapshot_id            | volume_type | volume_format | active
--------------------------------------+--------------------------------------+-------------+--------------------------------------+-------------+---------------+--------
 b049079e-88ec-4fa1-9337-cece7200a761 | 00000000-0000-0000-0000-000000000000 |           1 | 7d429c79-93ba-4761-a1a0-ebb4e45a3436 |           2 |             4 | f
 ab13dd45-12ad-4665-bee0-0ff87ced4225 | b049079e-88ec-4fa1-9337-cece7200a761 |           4 | f05794b9-ecba-48a6-b847-4b95d902a860 |           2 |             4 | t
(2 rows)

В предоставленном выводе проблема только в некорректном состоянии активного слоя диска ab13dd45-12ad-4665-bee0-0ff87ced4225. Если при этом в дампе домена хранения будут находиться по прежнему 3 диска, то ошибка идёт именно по этому сценарию:

image:    5adc6602-75b0-4719-857d-10f655e50bd0

         - b049079e-88ec-4fa1-9337-cece7200a761
           status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

         - ab13dd45-12ad-4665-bee0-0ff87ced4225
           status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

         - 597f40a1-5c39-483b-8ddb-9ff8bfcda313
           status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

3.2.2. Решение для блочного хранилища

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

Рекомендуется выполнять шаги ниже на хосте SPM.

Далее в решении активным слоем является слой с ID ab13dd45-12ad-4665-bee0-0ff87ced4225, а удаляемым 597f40a1-5c39-483b-8ddb-9ff8bfcda313.

внесите изменения в фильтр LVM в конфигурационный файл по пути /etc/lvm/lvm.conf, вам необходимо найти параметр filter =, пример ниже:
```
filter = ["a|^/dev/disk/by-id/lvm-pv-uuid-yvdeUF-DddZ-cNFj-TYel-JYcm-AZSG-RzbWtA$|", "r|.*|"]
```
Данный параметр необходимо закомментировать и добавить ниже новый:
```
filter = ["a|.*|"]
```
Для zVirt 4.X отключите использование system.devices:

lvs --config 'devices {use_devicesfile=0'}
активировать 2 тома: активный и удалённый из БД:
```
lvchange -ay /dev/1499f56c-0a0f-43df-a3e9-9e8e613e559b/ab13dd45-12ad-4665-bee0-0ff87ced4225
lvchange -ay /dev/1499f56c-0a0f-43df-a3e9-9e8e613e559b/597f40a1-5c39-483b-8ddb-9ff8bfcda313
```
обратите внимание, что после /dev/ указывается ID домена хранения, а затем ID слоя диска.
выполнить слияние слоёв диска:
```
qemu-img commit /dev/1499f56c-0a0f-43df-a3e9-9e8e613e559b/597f40a1-5c39-483b-8ddb-9ff8bfcda313
```
обратите внимание, что в команде мы указываем ID удаляемого диска.

деактивировать оба тома:

lvchange -an /dev/1499f56c-0a0f-43df-a3e9-9e8e613e559b/ab13dd45-12ad-4665-bee0-0ff87ced4225
lvchange -an /dev/1499f56c-0a0f-43df-a3e9-9e8e613e559b/597f40a1-5c39-483b-8ddb-9ff8bfcda313

удалить ненужный том:

lvremove /dev/1499f56c-0a0f-43df-a3e9-9e8e613e559b/597f40a1-5c39-483b-8ddb-9ff8bfcda313

После этого проверьте вывод дампа домена хранения, лишний слой должен удалиться:

image:    5adc6602-75b0-4719-857d-10f655e50bd0

  - b049079e-88ec-4fa1-9337-cece7200a761
    status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

  - ab13dd45-12ad-4665-bee0-0ff87ced4225
    status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

Обратите внимание, что у активного слоя диска остался тип тома INTERNAL. Это не помешает запуску ВМ, но не позволит создать новый слой этого диска, что блокирует создание моментальных снимков для ВМ.

После ручного слияния слоёв диска, необходимо установить статус слоя диска ВМ на корректный с помощью запроса в БД:

UPDATE images SET imagestatus=1 WHERE image_guid='ab13dd45-12ad-4665-bee0-0ff87ced4225';

Убедитесь, что ВМ можно запустить. Если ВМ удалось запустить, необходимо сделать резервную копию в ВМ, после чего удалить её, создать новую и восстановить систему из резервной копии. Если это невозможно, обратитесь к инженерам технической поддержки для предоставления альтернативных путей исправления состояния ВМ.

3.2.3. Решение для файлового хранилища

Для исправления ошибки будет необходимо вручную провести слияние слоёв диска, исправить метаданные слоя и восстановить работу ВМ. Для ручного слияния дисков обязательным требованием является выключение виртуальной машины, выберите время для простоя на время работы, после чего приступайте к решению.

Рекомедуется выполнять шаги ниже на хосте SPM.

Далее в решении будут применяться следующие переменные:

ID домена хранения в данном примере — fd9dbf27-6de2-4d07-99a5-bbec00f58d6b
ID диска в — 8d5a9a01-8a09-4f29-bc2b-3c32b09b768c
активным слоем является слой с ID 87971591-fd33-4200-a54b-b666cdfa29b9
удаляемым слоем является слой с ID 93c90f4b-303e-4c42-b778-9844cc3ba148

определите ID центра данных с помощью запроса в API:
curl -k https://$ENGINE_FQDN/ovirt-engine/api/datacenters -u admin@internal
$ENGINE_FQDN необходимо заменить на FQDN Менеджера Управления; admin@internal при необходимости заменить на имя пользователя; при выполнении будет запрошен пароль от указанного парользователя; Пример ID нужного центра данных будет в выводе:
<data_center href="/ovirt-engine/api/datacenters/d900057a-5c5a-11ee-bde3-00163e10167d" id="d900057a-5c5a-11ee-bde3-00163e10167d">

перейдите в директорию /rhev/data-center/$DATACENTER_ID/$STORAGE_DOMAIN_ID/images/$DISK_ID

cd /rhev/data-center/d900057a-5c5a-11ee-bde3-00163e10167d/fd9dbf27-6de2-4d07-99a5-bbec00f58d6b/images/8d5a9a01-8a09-4f29-bc2b-3c32b09b768c

выведите список содержимого в директории:

ls -l

примерный вывод:

total 3480
-rw-rw----. 1 vdsm kvm     196688 Mar  2 01:14 87971591-fd33-4200-a54b-b666cdfa29b9
-rw-rw----. 1 vdsm kvm    1048576 Mar  2 01:14 87971591-fd33-4200-a54b-b666cdfa29b9.lease
-rw-r--r--. 1 vdsm kvm        254 Mar  2 01:15 87971591-fd33-4200-a54b-b666cdfa29b9.meta
-rw-rw----. 1 vdsm kvm 5368709120 Mar  2 01:12 8decbe7a-a9e2-464c-ad92-683929d06148
-rw-rw----. 1 vdsm kvm    1048576 Mar  2 01:12 8decbe7a-a9e2-464c-ad92-683929d06148.lease
-rw-r--r--. 1 vdsm kvm        306 Mar  2 01:14 8decbe7a-a9e2-464c-ad92-683929d06148.meta
-rw-rw----. 1 vdsm kvm     196688 Mar  2 01:15 93c90f4b-303e-4c42-b778-9844cc3ba148
-rw-rw----. 1 vdsm kvm    1048576 Mar  2 01:15 93c90f4b-303e-4c42-b778-9844cc3ba148.lease
-rw-r--r--. 1 vdsm kvm        250 Mar  2 01:15 93c90f4b-303e-4c42-b778-9844cc3ba148.meta

выполните слияние слоя диска:
```
qemu-img commit ./93c90f4b-303e-4c42-b778-9844cc3ba148
```
обратите внимание, что в команде мы указываем ID удаляемого диска.
удалите ненужный слой вместе с файлом-лизинга и метаданными:
```
rm -f ./93c90f4b-303e-4c42-b778-9844cc3ba148*
```
исправьте метаданные активного слоя, для этого откройте файл .meta активного слоя с помощью любого редактора и исправьте VOLTYPE=INTERNAL на VOLTYPE=LEAF
убедитесь, что в дампе домена хранения применились изменения, в данном примере корректным вывод является удаление лишнего слоя и указание VOLTYPE=LEAF для активного
```
image:    8d5a9a01-8a09-4f29-bc2b-3c32b09b768c

  - 8decbe7a-a9e2-464c-ad92-683929d06148
    status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 4096

  - 87971591-fd33-4200-a54b-b666cdfa29b9
    status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 200704
```
В приведённом выводе был удалён лишний 3-ий слой, а активный слой с ID 87971591-fd33-4200-a54b-b666cdfa29b9 имеет корректный тип тома.

внесите исправление в базу данных

UPDATE images SET imagestatus=1 WHERE image_guid='87971591-fd33-4200-a54b-b666cdfa29b9';

После выполнения указанных выше шагов, попробуйте запустить виртуальную машину и создать новый снимок. Если ВМ запускается, а создание нового снимка проходит без ошибок, то работа виртуальной машины восстановлена.

3.3. Слой диска в состоянии удалён (removed)

3.3.1. Обнаружение

Данный сценарий представляет собой оставшийся в базе данных и метаданных домена слой диска, который фактически уже слит с родительским и удалён.

В данном сценарии решение отличается в зависимости от типа хранилища: файловое (NFS) или блочное (iSCSI/FC), учтите это при самостоятельном решении проблемы.

В случае возникновения данной ошибки, в WEB-интерфейсе zVirt у слоя диска удаляемого снимка будет некорректное состояние, а при попытке запуска может возникать ошибка, указывающая на это. На вкладке со снимками ожидается такое состояние:

Диск снимка Second snapshot в некорректном состоянии, при этом ни активный диск, ни сами снимки не заблокированы.

В базе данных может наблюдаться следующий вывод:

снимки:

SELECT snapshot_id, snapshot_type, status, description FROM snapshots WHERE vm_id='10248397-4367-436f-88eb-63b4c44a57fa';
             snapshot_id              | snapshot_type | status |   description
--------------------------------------+---------------+--------+-----------------
 7d429c79-93ba-4761-a1a0-ebb4e45a3436 | REGULAR       | OK     | First snapshot
 e5abed70-dcde-426a-8f9d-81d96ce03b3e | ACTIVE        | OK     | Active VM
 f05794b9-ecba-48a6-b847-4b95d902a860 | REGULAR       | OK     | Second Snapshot
(3 rows)

слои диска

SELECT image_guid, parentid, imagestatus, vm_snapshot_id, volume_type, volume_format, active FROM images WHERE image_group_id='5adc6602-75b0-4719-857d-10f655e50bd0';
              image_guid              |               parentid               | imagestatus |            vm_snapshot_id            | volume_type | volume_format | active
--------------------------------------+--------------------------------------+-------------+--------------------------------------+-------------+---------------+--------
 b049079e-88ec-4fa1-9337-cece7200a761 | 00000000-0000-0000-0000-000000000000 |           1 | 7d429c79-93ba-4761-a1a0-ebb4e45a3436 |           2 |             4 | f
 ab13dd45-12ad-4665-bee0-0ff87ced4225 | b049079e-88ec-4fa1-9337-cece7200a761 |           4 | f05794b9-ecba-48a6-b847-4b95d902a860 |           2 |             4 | f
 26fd9755-d7e5-4e3f-aca1-721413ed87e2 | ab13dd45-12ad-4665-bee0-0ff87ced4225 |           1 | e5abed70-dcde-426a-8f9d-81d96ce03b3e |           2 |             4 | t
(3 rows)

Если при этом в дампе домена хранения вы видите 2 диска, ссылающихся на общий родительский слой, а у одного из слоёв status: REMOVED, то вы столкнулись с данным сценарием

image:    5adc6602-75b0-4719-857d-10f655e50bd0

    Error: more than one volume pointing to the same parent volume e.g: (_BLANK_UUID<-a), (a<-b), (a<-c)

  Unordered volumes and children:

    - b049079e-88ec-4fa1-9337-cece7200a761
      status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

    - b049079e-88ec-4fa1-9337-cece7200a761 <- ab13dd45-12ad-4665-bee0-0ff87ced4225
      status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

    - b049079e-88ec-4fa1-9337-cece7200a761 <- 26fd9755-d7e5-4e3f-aca1-721413ed87e2
      status: REMOVED, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

3.3.2. Решение для блочного хранилища

Для исправления ошибки будет необходимо вручную удалить лишний слой диска и внести исправления в базу данных. Рекомендуется выполнять описанные ниже действия с выключенной ВМ.

Рекомедуется выполнять шаги ниже на хосте SPM.

Далее в решении активным слоем является слой с ID ab13dd45-12ad-4665-bee0-0ff87ced4225, а удаляемым 26fd9755-d7e5-4e3f-aca1-721413ed87e2.

Внесите изменения в фильтр LVM в конфигурационный файл по пути /etc/lvm/lvm.conf, вам необходимо найти параметр filter =, пример ниже:
filter = ["a|^/dev/disk/by-id/lvm-pv-uuid-yvdeUF-DddZ-cNFj-TYel-JYcm-AZSG-RzbWtA$|", "r|.*|"]
Данный параметр необходимо закомментировать и добавить ниже новый:
filter = ["a|.*|"]

Удалите лишний том

lvremove /dev/1499f56c-0a0f-43df-a3e9-9e8e613e559b/26fd9755-d7e5-4e3f-aca1-721413ed87e2

После этого проверьте вывод дампа домена хранения, лишний слой должен удалиться:

image:    5adc6602-75b0-4719-857d-10f655e50bd0

  - b049079e-88ec-4fa1-9337-cece7200a761
    status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

  - ab13dd45-12ad-4665-bee0-0ff87ced4225
    status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 5368709120, truesize: 1073741824

Обратите внимание, чтобы у активного слоя диска остался тип тома LEAF. Если тип тома будет INTERNAL, обратитесь к технической поддержке для получения шагов по дальнейшему исправлению ВМ. Так как тип тома INTERNAL не мешает запуску виртуальной машины, вы можете запустить ВМ и сделать резервную копию на уровне ОС или файловой системы и восстановить их в новую ВМ. Предыдущую неисправную ВМ после восстановления можно удалить.

UPDATE images SET imagestatus=1 WHERE image_guid='ab13dd45-12ad-4665-bee0-0ff87ced4225';

Убедитесь, что ВМ можно запустить и новый снимок создаётся корректно. Если ВМ запускается, а создание нового снимка проходит без ошибок, то работа виртуальной машины восстановлена.

3.3.3. Решение для файлового хранилища

Рекомендуется выполнять шаги ниже на хосте SPM.

Далее в решении будут применяться следующие переменные:

ID домена хранения в данном примере — fd9dbf27-6de2-4d07-99a5-bbec00f58d6b
ID диска в — 8d5a9a01-8a09-4f29-bc2b-3c32b09b768c
активным слоем является слой с ID 87971591-fd33-4200-a54b-b666cdfa29b9

удаляемым слоем является слой с ID 93c90f4b-303e-4c42-b778-9844cc3ba148

Определите ID центра данных с помощью запроса в API:
curl -k https://$ENGINE_FQDN/ovirt-engine/api/datacenters -u admin@internal
$ENGINE_FQDN необходимо заменить на FQDN Менеджера Управления; admin@internal при необходимости заменить на имя пользователя; при выполнении будет запрошен пароль от указанного парользователя; Пример ID нужного центра данных будет в выводе:
<data_center href="/ovirt-engine/api/datacenters/d900057a-5c5a-11ee-bde3-00163e10167d" id="d900057a-5c5a-11ee-bde3-00163e10167d">

Перейдите в директорию /rhev/data-center/$DATACENTER_ID/$STORAGE_DOMAIN_ID/images/$DISK_ID

cd /rhev/data-center/d900057a-5c5a-11ee-bde3-00163e10167d/fd9dbf27-6de2-4d07-99a5-bbec00f58d6b/images/8d5a9a01-8a09-4f29-bc2b-3c32b09b768c

Выведите список содержимого в директории:

ls -l

примерный вывод:

total 3480
-rw-rw----. 1 vdsm kvm     196688 Mar  2 01:14 87971591-fd33-4200-a54b-b666cdfa29b9
-rw-rw----. 1 vdsm kvm    1048576 Mar  2 01:14 87971591-fd33-4200-a54b-b666cdfa29b9.lease
-rw-r--r--. 1 vdsm kvm        254 Mar  2 01:15 87971591-fd33-4200-a54b-b666cdfa29b9.meta
-rw-rw----. 1 vdsm kvm 5368709120 Mar  2 01:12 8decbe7a-a9e2-464c-ad92-683929d06148
-rw-rw----. 1 vdsm kvm    1048576 Mar  2 01:12 8decbe7a-a9e2-464c-ad92-683929d06148.lease
-rw-r--r--. 1 vdsm kvm        306 Mar  2 01:14 8decbe7a-a9e2-464c-ad92-683929d06148.meta
-rw-rw----. 1 vdsm kvm     196688 Mar  2 01:15 93c90f4b-303e-4c42-b778-9844cc3ba148
-rw-rw----. 1 vdsm kvm    1048576 Mar  2 01:15 93c90f4b-303e-4c42-b778-9844cc3ba148.lease
-rw-r--r--. 1 vdsm kvm        250 Mar  2 01:15 93c90f4b-303e-4c42-b778-9844cc3ba148.meta

Удалите лишний слой диска вместе с файлом-лизинга и метаданными:
```
rm -f ./93c90f4b-303e-4c42-b778-9844cc3ba148*
```
Если в метаданных активного слоя указан тип тома INTERNAL, исправьте его на LEAF в файле .meta

Внесите исправление в базу данных

UPDATE images SET imagestatus=1 WHERE image_guid='87971591-fd33-4200-a54b-b666cdfa29b9';

3.4. Примечания

Если случайно был удалён не тот слой диска, то для его восстановления необходимо выполнить INSERT данных обратно в таблицу images и добавить запись в image_storage_domain_map.

Пример запросов:

INSERT INTO public.images (image_guid, creation_date, size, it_guid, parentid, imagestatus, lastmodified, vm_snapshot_id, volume_type, volume_format, image_group_id, _create_date, _update_date, active, volume_classification, qcow_compat, sequence_number) VALUES ('94529545-060b-47f0-b098-929fa079a0ca', '2024-05-03 00:30:48+05', 5368709120, '00000000-0000-0000-0000-000000000000', '00000000-0000-0000-0000-000000000000', 1, '2024-05-03 00:30:48.48+05', 'f9a1dd14-5eaa-44b1-a389-237e57906b4b', 2, 4, '45c65483-23bf-4e29-80a6-eeebf56b5f2d', '2024-05-03 00:30:48.480593+05', '2024-05-03 00:30:51.654206+05', true, 0, 2, 1);
INSERT INTO public.image_storage_domain_map (image_id, storage_domain_id, quota_id, disk_profile_id) VALUES ('94529545-060b-47f0-b098-929fa079a0ca', '2f5d6f3e-5a29-4df1-a65b-5788c96834d9', 'aa021e86-a243-4ca4-8d53-a64b51e69e21', 'b3a601ae-6342-4f1b-a11b-31b27d1b5f69');

При необходимости выполнить загрузку слоя диска в zVirt для его последующего использования (В случае, когда в дампе vdsm параметр слоя, создание слоев от которого в дальнейшем может быть необходимо, voltype равен INTERNAL и т.д), необходимо сделать следующее:
Предварительно получить значения параметров:
- POOL_ID - ID центра данных, к которому подключен нужный нам домен хранения. На хосте, который входит в нужный ЦД выполняем:
  vdsm-client Host getConnectedStoragePools
- STORAGE_ID - ID домена хранения: Хранилище Домены Нажать на имя нужного домена Общее ID
- DISK_ID - ID диска: Хранилище Диски Нажать на имя нужного диска Общее ID
На SPM-хосте(не является обязательным требованием): cd /rhev/data-center/POOL_ID/STORAGE_ID/DISK_ID - переходим в директорию нужного диска
Выполняем загрузку слоя на портал по данной инструкции.
Прикрепляем полученный диск к нужной ВМ.