Как обращаться (с LVM или DM (устройство)), когда привод ушел и вернулся в качестве нового блочного устройства

(Этот правильный ответ относится к тому, который имеет мало поверхностного сходства с этим. Задавая вопрос и сам ответ на него со ссылкой на этот вопрос.)

Рассмотрим виртуальную среду хоста, в которой виртуальной машине было назначено 3 отдельных virtio диска, которые отображаются как 3 отдельных блочных устройства и назначены 3 отдельным VG (группам томов).

  • os – /dev/vda vda – vgroot
  • db – /dev/vdb – vgdata
  • var – /dev/vdc – vgvar

Пока виртуальная машина находится в сети, /dev/vdb уходит. Это может быть связано с перемещением виртуальной машины на новый гипервизор, но этот конкретный том застрял, или, возможно, безумный системный администратор удалил том и временно разместил его на другом хосте. В моем случае мне повезло.

Когда объем возвращается, ядро ​​Linux (не все, на самом деле, но по крайней мере с RHEL6) присваивает его не своей оригинальной букве диска, потому что этот диск технически рассматривается как «открытый», а для нового блочного устройства: /dev/vdd .

Впоследствии все команды LVM, такие как vgs , сообщают:

 /dev/data/db: read failed after 0 of 4096 at 10733158400: Input/output error /dev/data/db: read failed after 0 of 4096 at 10733215744: Input/output error /dev/data/db: read failed after 0 of 4096 at 0: Input/output error /dev/data/db: read failed after 0 of 4096 at 4096: Input/output error 

Однако pvscan и vgscan обнаруживают исходные тома, но они все еще пытаются прочитать старое блок-устройство. Повторная установка не работает. И, ради аргумента, перезагрузка недопустима. Что делать?

На этот вопрос был дан ответ в связи с обсуждением здесь дисков iscsi . Поскольку я вообще не работаю с scsi, но, скорее, virtio , поиски Google не помогли найти мой ответ. Если вы столкнетесь с этим ответом, обязательно подтвердите ответ Гизеппе. Короче говоря, это:

 vgscan ; vgchange <vgname> --refresh