В обычной ситуации народ подключает дополнительное блочное устройство в веб-интерфейсе Horizon и внутри виртуальной машины появляется новый HDD. Но бывают ситуации, когда в ВМ загрузили образ ВМ, который оказался битым или с него просто необходимо перенести информацию в другую виртуальную машину. Например, когда надо склеить виртуальную машину состоящую из нескольких файлов в одну. После поисков в этой ситуации находится ссылка на запись (в свою очередь ссылающуюся на stackexchange) в блоге компании Mirantis, где описывается один из способов подключения. Но минус данного подхода в том, что он безмерно коряв и требует лишних движений, связанных с прописыванием образа в Glance (что бывает не всегда возможно да и не нужно). Ещё один недостаток описанного по ссылке метода в том, что если нужно подключить данный образ на длительное время, шедулер может такой файл зачистить, так как он может не использоваться какой-то конкретной ВМ. Либо приходится зачем-то держать запущенными инстансы, которые отнимают далеко не бесконечные ресурсы.
Я предпочитаю для решения данной проблемы использовать другой способ.
Для начала, нам необходим ID инстанса и хост, где он выполняется. Для этого по ssh заходим на управляющую ноду и выполянем:
export OS_TENANT_NAME=TENANT_NAME
nova list (если вдруг забыли, как ВМ называется и узнать его ID)
nova show имя_вм
В получившемся выхлопе ищем строку OS-EXT-SRV-ATTR:host где и должно быть указано имя хоста, где запущен гипервизор с нужной нам ВМ. Далее на всё той же ноде выполняем nova rescue VM_ID. В веб-интерфейсе нужная нам ВМ перейдёт в режим rescue. В этом состоянии блокируется запись в libvirt.xml и OpenStack генерит свой, который можно безбоязненно править как нам заблагорассудится.
Далее логинимся по ssh на хост с гипервизором и выполняем virsh edit Instance_ID (instance-00000X). Сразу можно обратить внимание, что в конфигурационном файле прописано два диска: /dev/vda и /dev/vdb. Где vda — копия системы в rescue-режиме, а vdb — исходный образ виртуальной машины куда нам и надо писать необходимые данные.
Далее нам необходимо скопировать на гипервизор файл с образом в поддерживаемом в вашей версии OpenStack формате и написать следующее:
Где source file= путь к образу. После сохранения файла необходимо выполнить virsh destroy instance_id и затем выполнить virsh start instance_id. После данных манипуляций в системе должен появиться третий диск, который мы подключили дополнительно.
Далее уже можно проделывать с ВМ необходимые манипуляции. Следует обратить внимание, что диск vda — это система запущенная в rescue-режиме, то писать ничего на него не надо, иначе потеряете изменения.
После окончания работ необходимо выполнить nova unrescue ВМ_ID и потушить систему. После уже можно стартануть как обычно, через веб-интерфейс.
Я предпочитаю для решения данной проблемы использовать другой способ.
Для начала, нам необходим ID инстанса и хост, где он выполняется. Для этого по ssh заходим на управляющую ноду и выполянем:
export OS_TENANT_NAME=TENANT_NAME
nova list (если вдруг забыли, как ВМ называется и узнать его ID)
nova show имя_вм
В получившемся выхлопе ищем строку OS-EXT-SRV-ATTR:host где и должно быть указано имя хоста, где запущен гипервизор с нужной нам ВМ. Далее на всё той же ноде выполняем nova rescue VM_ID. В веб-интерфейсе нужная нам ВМ перейдёт в режим rescue. В этом состоянии блокируется запись в libvirt.xml и OpenStack генерит свой, который можно безбоязненно править как нам заблагорассудится.
Далее логинимся по ssh на хост с гипервизором и выполняем virsh edit Instance_ID (instance-00000X). Сразу можно обратить внимание, что в конфигурационном файле прописано два диска: /dev/vda и /dev/vdb. Где vda — копия системы в rescue-режиме, а vdb — исходный образ виртуальной машины куда нам и надо писать необходимые данные.
Далее нам необходимо скопировать на гипервизор файл с образом в поддерживаемом в вашей версии OpenStack формате и написать следующее:
Где source file= путь к образу. После сохранения файла необходимо выполнить virsh destroy instance_id и затем выполнить virsh start instance_id. После данных манипуляций в системе должен появиться третий диск, который мы подключили дополнительно.
Далее уже можно проделывать с ВМ необходимые манипуляции. Следует обратить внимание, что диск vda — это система запущенная в rescue-режиме, то писать ничего на него не надо, иначе потеряете изменения.
После окончания работ необходимо выполнить nova unrescue ВМ_ID и потушить систему. После уже можно стартануть как обычно, через веб-интерфейс.
Комментариев нет:
Отправить комментарий