We rise up for the things we believe in over and over again
Пришла пора обновлять гипервизоры. Стандартная процедура при этом - выгнать с них все виртуалки, сидящие в кластере, погасить все, сидящие вне кластера. Делаем привычное Move - Live Migrate - Best Possible Node... И получаем облом вот такого вида:
Virtual machine migration operation for 'xxx' failed at migration source 'NODExxx'. (Virtual machine ID %VM-GUID%)
'xxx' failed to delete configuration: The request is not supported. (0x80070032). (Virtual machine ID %VM-GUID%)
Блуждания в инете говорят, что проблема в одном из двух:
1. Всякий антивирусный софт. В моем случае маловероятно, потому что с этой ноды уже несколько машин спокойно уехало. Для очистки совести заглянул в параметры антивирусного ПО - все, что относится к Hyper-V и кластеру - добавлено в исключения. Стало быть, не то.
2. Изменение настроек кластерной ВМ через оснастку Hyper-V. Рассуждения таковы: оснастка Hyper-V может банально не знать о кластерных настройках и при записи новых значений в файл просто вытрет их оттуда. Отсюда и кривая работа ВМ в кластере. Лечить - удалением пораженной машины из кластера и добавление оной в кластер заново.
В рабочем чате собирается BrainStorm. Поступает предложение выполнить валидацию всего кластера, исключив проверку стораджей. Запускаем. Проверка показывает ересь в плане сетевых настроек, но они на ВМ так влиять не должны. Смотрю на раздел VM Configuration, вместо привычного Success стоит Warning. А расскажи-ка мне поподробнее, что там предупреждение выкинуло? Каково же было мое удивление, когда я прочитал следующее:
Virtual Machine: xxx
Configuration Data Root: C:\ProgramData\Microsoft\Windows\Hyper-V
Вот в чем дело. Гипервизор считает, что файл описания ВМ хранится не на кластерном диске, а на локальном, куда хода остальным нодам кластера нет. Что ж, надо это исправить. Выключаем пораженную машину, в оснастке Failover Cluster Manager жмем на ней правой кнопкой мыши, выбираем Move, Virtual Machne Storage. В появившемся окне назначаем нужным разделам нужные каталоги на кластерном диске, и жмем ОК. А по нажатию кнопки ОК гипервизор нам заявляет, что переместить файл описания виртуальной машины не может, так как там этот файл уже есть. Хм... То есть у нас есть две копии одного файла, и рабочая из них та, что лежит в неположенном месте. Ладно, уберем их с кластерного диска, благо, имя конфликтующего файла оснастка кластера показывает. После этого дадим оснастке команду обновиться, чтобы она "забыла" о том, что на кластерном диске что-то было, и повторно попробуем переместить файлы конфигурации и обновить каталоги. В этот раз все прошло на ура.
Rinse and repeat 5 more times, потому что валидация кластера показала 6 таких пораженных виртуальных машин.
Самый главный вопрос - почему файлы конфигурации этих ВМ переползли на локальные диски, пока без ответа. Но хотя бы можно продолжить процесс обновления гипервизоров.