Comments 7
Очень интересно.А можно по подробнее по пункту 6. « Обратились в Orion soft за помощью, описав нашу проблему – поддержка действительно помогла и подсказала ряд действий, после которых в интерфейсе виртуализации мы увидели наши сконвертированные диски.» В чем была проблема и как ее исправлять?
Не очень понятно, что ж у заказчика за инфраструктура такая, что время простоя ВМ должно быть минимальным? они не задублированы, не кластеризованы, вообще никакого резерва и высокой доступности? Ну постояли бы без одной реплики какое-то время...
AHV — не стандартный KVM
Что в вашем понимании "стандартный KVM"? Вы там ожидали увидеть libvirt и QEMU?
По итогу: вы достали образы дисков, конвертировали (ну видимо в qcow2) и запустили новые виртуальные машины с них. Банальная и очевидная операция для любого системного инженера, но подаёте это как героический героизм.
По описанию:
1. Выключили виртуальные машины (иначе прощай консистентность данных)
2. Конвертировали диски, но они ещё лежали у Nutanix
3. Подключили диру с дисками по NFS к хосту с zVirt
4. Судя по описанию не осилили обновление пула хранилища в libvirt и позвали на помощь ребят из OrionSoft (zVirt это форк oVirt, а тот, сюрприз, использует libvirt)
5. Запусили ВМ в zVirt используя диски из шары
Самое же интересное тут это как выполняли:
Ну а в конце – перенесли диски с NFS-шары с Nutanix в новое хранилище.
Ведь надо создать локальную копию диска, переключить чтение/запись на неё, а NFS шару разобрать. Опять останавливали ВМ? Но в чём тогда выигрыш от фокуса с NFS?
Звирт, вмменеджер и спейсвм - самые толковые наши системы виртуализации. Сами мигрировали на вмменеджер, конечно, попроще все было. Но главное, что схема рабочая и кому-то точно пригодится.
Как мы спасали рядового Райана от платформы виртуализации Nutanix AHV: кейс и грабли