Как удалить "неудаляемый" диск в openstack
Бывают такие ситуации, когда диск openstack невозможно удалить штатными средствами.
Например, некоторые действия с диском не отображены в базе данных MySQL в результате каких-то сбоев.
Рассмотрим все на конкретном примере. Проблемный диск: volume_id=522b22a3-155b-4dd8-8b5a-c158e1410145
Запишем идентификатор диска в переменную VOLID.
VOLID='522b22a3-155b-4dd8-8b5a-c158e1410145'
Attachments
Проверить и удалить "мертвые" attachments
select * from volume_attachment where volume_id=$VOLID;
delete from volume_attachment where volume_id=$VOLID;
Snapshots
Проверить и удалить снэпшоты
select * from snapshots where volume_id=$VOLID;
delete from snapshots where volume_id=$VOLID;
Transfers
Проверить, нет ли незавершенной миграции диска
select * from transfers where volume_id=$VOLID;
delete from transfers where volume_id=$VOLID;
Удаление
Удалить наконец-то проблемный диск:
openstack volume delete --force $VOLID
Если будет сообщение такого типа:
Invalid volume: Volume must not be migrating, attached, belong to a consistency group or have snapshots. (HTTP 400) (Request-ID: req-3fc7dc02-ee95-444c-b4a0-f68e5c67aa8d)
В таблицах backups, cgsnapshots, consistencygroups, driver_initiator_data encryption, image_volume_cache_entries, iscsi_targets, snapshot_metadata, в нашем случае нет записей. Поэтому это не может повлияить на возможность удаления диска.
Проверяем все параметры нашего диска
cinder show $VOLID
+--------------------------------+----------------------------------------------+
| Property | Value |
+--------------------------------+----------------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2018-05-29T12:44:23.000000 |
| description | |
| encrypted | False |
| id | 522b22a3-155b-4dd8-8b5a-c158e1410145 |
| metadata | {'readonly': 'False', 'attached_mode': 'rw'} |
| migration_status | None |
| multiattach | False |
| name | test |
| os-vol-host-attr:host | dc-stor-01@object#object |
| os-vol-mig-status-attr:migstat | None |
| os-vol-mig-status-attr:name_id | None |
| os-vol-tenant-attr:tenant_id | e3cc5d1e0569481e91e936546a2dbe1c |
| replication_status | disabled |
| size | 100 |
| snapshot_id | None |
| source_volid | None |
| status | available |
| updated_at | 2019-01-31T07:55:18.000000 |
| user_id | 12ac19dd84804572a97c0bb6221371eb |
| volume_type | object |
+--------------------------------+----------------------------------------------+
Metadata
В данном случае диск все равно не хотел удаляться, т.к. у него в метаданных осталась запись ('attached_mode': 'rw').
Это можно посмотреть в таблице volume_admin_metadata
mysql> select * from volume_admin_metadata where volume_id=$VOLID;
+---------------------+------------+---------------------+---------+-----+--------------------------------------+---------------+-------+
| created_at | updated_at | deleted_at | deleted | id | volume_id | key | value |
+---------------------+------------+---------------------+---------+-----+--------------------------------------+---------------+-------+
| 2018-05-29 12:45:16 | NULL | NULL | 0 | 937 | 522b22a3-155b-4dd8-8b5a-c158e1410145 | readonly | False |
| 2018-05-29 12:45:17 | NULL | 2018-05-29 13:21:12 | 1 | 940 | 522b22a3-155b-4dd8-8b5a-c158e1410145 | attached_mode | rw |
| 2018-05-29 13:29:30 | NULL | NULL | 0 | 949 | 522b22a3-155b-4dd8-8b5a-c158e1410145 | attached_mode | rw |
+---------------------+------------+---------------------+---------+-----+--------------------------------------+---------------+-------+
3 rows in set (0.01 sec)
Удаляем ненужные записи по ключу: value='rw'
delete from volume_admin_metadata where volume_id=$VOLID and value='rw';
Status
В моем конкретном случае и это не помогло. Причина была в том, что диск находился в статусе "attached".
mysql> select id,attach_status from volumes where id=$VOLID;
+--------------------------------------+---------------+
| id | attach_status |
+--------------------------------------+---------------+
| 522b22a3-155b-4dd8-8b5a-c158e1410145 | attached |
+--------------------------------------+---------------+
1 row in set (0.00 sec)
mysql> select distinct attach_status from volumes;
+---------------+
| attach_status |
+---------------+
| detached |
| attached |
| none |
+---------------+
3 rows in set (0.00 sec)
Сбрасываем статус подключения в none
update volumes set attach_status='none' where id=$VOLID;
Наконец-то получилось удалить наш злополучный диск командой:
openstack volume delete --force 522b22a3-155b-4dd8-8b5a-c158e1410145
dog vdi list volume-522b22a3-155b-4dd8-8b5a-c158e1410145
Name Id Size Used Shared Creation time VDI id Copies Tag
Крайний вариант
Что делать, если ничего не помогло?
На крайний вариант, если все вышеприведенные приемы на помогли, удаляем вручную запись о диске с таблице volumes и во всех связанных таблицах, в которых есть $VOLID.
После этого вручную удаляем диск в хранилище:
dog vdi delete volume-$VOLID
aizaro@mail.ru 31.01.2019