none
Hyper-V Cluster 2008R2 + SCVMM2012R2, конфигурация VM не доступна после осуществления Live Migration RRS feed

  • Вопрос

  • Добрый день!

    Конфигурация, кластер Hyper-V под управлением Windows Server 2008R2 (четыре ноды), порядка 20 VM, на одной из VM развернут SCVMM 2012R2 (установлены все Rollup), после развертывания SCVMM настроен RunAs Account, добавлены узлы кластера, VM видны в оснастке VMM, SC BPA критичных проблем не выявил.

    При выполнении технических работ, а именно обновление узлов кластера, VM были перемещены посредством Live Migration с помощью консоли SCVMM, последовательно с одного узла на другой. Узлы кластера перезагружались после установки обновлений.

    В результате этих операций имеем следующую ситуацию, часть VM не запускаются на некоторых узлах кластера, генерируются ошибки.

    Error 21.09.2015 16:19:52 FailoverClustering 1069 Resource Control Manager
    Cluster resource 'VM_NAME Configuration' in clustered service or application 'SCVMM MSK-HQ-WDS01 Resources' failed.

    Error 21.09.2015 16:20:52 Hyper-V-High-Availability 21502 None
    'VM_NAME Configuration' failed to unregister the virtual machine with the virtual machine management service.

    Error 22.09.2015 14:15:45 Hyper-V-VMMS 16310 None
    Cannot load a virtual machine configuration because it is corrupt. (Virtual machine ID XXXXXXXX-66BC-41E2-8996-0B850C7146DA) Delete the virtual machine configuration file (.XML file) amd recreate the virtual machine.

    В оснастке управления кластером ресурс VM Configuration для данной VM в состоянии Failed, причем сама VM в оснастке Hyper-V не видна. Но если переместить VM на другой узел кластера то VM Configuration переходит в состояние Online.

    Такая ситуация присуща нескольким VM, но не всем, причем узлы кластера на которых VM сбоят вариативны, одни VM не стартуют на одном узле (узлах), другие на других.

    Я пробовал решить эту задачу разными способами, пока не один их них не привел к тому что бы сбояная VM перемещалась по всем узлам кластера. Ниже привожу ссылки.

    https://social.technet.microsoft.com/forums/windowsserver/en-US/23e51f3b-c13a-4e1d-8ad7-23911abb38a1/virtual-server-in-hyperv-windows-2008r2-stopped-responding

    http://blog.tyang.org/2011/01/19/hyper-v-virtual-machine-missing-status/

    https://social.technet.microsoft.com/forums/windowsserver/en-US/c840c570-1c4b-46ad-8df2-1a09ee0d8b88/failed-vm-configuration-file

    Создание вручную simlink-а и назначение прав ни к чему не привело, при попытке запустить сбойную конфигурацию Online simlink на этой ноде пропадает, если переместить VM на другую ноду simlink появляется без проблем.

    Поставил эксперимент на одной не критичной VM, создал новую VM с идентичной конфигурацией (конфигурацию сразу сохранил на CSV), скопировал VHD сбойной машины (так же на CSV), объявил машину кластерной. Новая VM без проблем перемещается между всеми узлами кластера. В принципе это решение, но при создании новой машины создается новый сетевой адаптер, при этом в гостевой системе приходится править реестр удаляя старый интерфейс, после чего можно назначить IP адрес новому интерфейсу. 

    Прошу помощи, возможно есть способ привести в порядок сбойные машины, без пересоздания конфигурации?

    22 сентября 2015 г. 13:51

Ответы

  • Добрый день!

    Удалось решить вышеописанную проблему, надеюсь решение будет полезно сообществу.

    Выделив техническое окно (ночное время, выходной день), произвел обновление гостевых систем VM, обновил Integration Services и последовательно выключил все VM. Так же обновил хосты виртуализации и выключил их. На всякий случай предварительно сделал скриншоты конфигураций виртуальных машин, а именно количество vCPU, объем оперативной памяти, местоположение VHD файла, количество, название и MAC адреса виртуальных сетевых адаптеров.

    После включение всех узлов кластера, убедился, что кластерная служба "поднялась" без ошибок и в целом кластер чувствует себя хорошо, во всяком случае критических ошибок в логах обнаружено не было. Попробовал перемещать сбойные VM с узла на узел (в выключенном состоянии), получил ту же ошибку что и до перезагрузки, на определенных узлах кластера конфигурация VM переходила в состояние Failed.

    Начал реанимировать VM. Последовательность действий следующая.

    1. Переместил VM на узел кластера, где конфигурация доступна.

    2. Отключил все VHD от VM (в принципе это делать не обязательно, т.к. при удалении машины из кластера, а затем из Hyper-V менеджера VHD файлы сохраняются по пути их местоположения, но я решил перестраховаться).

    3. Удалил VM из кластера.

    4. Скопировал XML файл конфигурации сбойной машины в отдельное местоположение (например в папку на рабочем столе).

    5. Удалил VM из Hyper-V менеджера.

    6. Создал новую VM, указав местоположение новой конфигурации на CSV в папке старой VM. Сетевые адаптеры не подключал, диски не монтировал.

    7. Изменил конфигурацию новой VM, указал кол-во памяти, кол-во vCPU, смонтировал диски, подключил сетевой адаптер к нужному vSwitch.

    8. Добавил машину в кластер (VM запускать не нужно).

    9. Скопировал XML файл конфигурации новой VM в отдельное местоположение (например в папку на рабочем столе).

    10. Открыл XML файл конфигурации старой (сбойной) VM в текстовом редакторе нашел блок, отвечающий за сетевые интерфейсы, скопировал GUID сетевого интерфейса. Таким же образом нашел GUID интерфейса в XML новой конфигурации и подменил его старым. Сохранил конфигурацию.

    11. Скопировал XML файл конфигурации в местоположение VM с заменой исходного файла.

    12. Запустил VM, после загрузки проверил состояние интерфейса, IP не должен измениться, т.к. для гостевой системы GUID интерфейса остался прежним. Проверил доступность ресурсов (ipconfig, ping, tracert и т.д.)

    Повторил вышеописанные действия для всех сбойных VM.

    В гостевых системах 2008R2 диски не являющиеся системными разделами (например диски под базы данных Exchange) после старта новой машины находятся в состоянии offline, не нужно пугаться что при первом запуске почтовик не смонтирует базы. Переводим диски в состояние online, перезапускаем VM (или соответсвующие службы) и наблюдаем корректную работу сервисов.

    Если в сбойной VM использовалось несколько сетевых интерфейсов необходимо искать GUID в файле конфигурации ориентируясь на MAC адрес интерфейса, даже если он динамический, он отображается в свойствах VM.

    Вроде все, всем удачи в работе.

    • Помечено в качестве ответа elmuerto 28 сентября 2015 г. 7:55
    28 сентября 2015 г. 7:55

Все ответы

  • Попробуйте удалить ВМ как кластерный ресурс (Remove из оснастки Failover Cluster) и добавить их снова. Правда, в Windows Server 2008 R2 это придётся делать с остановкой гостевой операционной системы.

    Кроме того, попробуйте использовать в консоли PowerShell для SCVMM командлет

    Refresh-VM VM_NAME -force

    и командлет кластера

    Update-ClusterVirtualMachineConfiguration "Virtual Machine Configuration VM_NAME" 


    22 сентября 2015 г. 18:56
    Модератор
  • Денис, добрый день!

    Спасибо, за советы, но к сожалению ни один из них не помог решить проблему. После выведения машины из кластера и добавления обратно ситуация не изменилась. Возможно ошибка пропадет, если полностью перезагрузить кластер.

    24 сентября 2015 г. 5:27
  • Добрый день!

    Удалось решить вышеописанную проблему, надеюсь решение будет полезно сообществу.

    Выделив техническое окно (ночное время, выходной день), произвел обновление гостевых систем VM, обновил Integration Services и последовательно выключил все VM. Так же обновил хосты виртуализации и выключил их. На всякий случай предварительно сделал скриншоты конфигураций виртуальных машин, а именно количество vCPU, объем оперативной памяти, местоположение VHD файла, количество, название и MAC адреса виртуальных сетевых адаптеров.

    После включение всех узлов кластера, убедился, что кластерная служба "поднялась" без ошибок и в целом кластер чувствует себя хорошо, во всяком случае критических ошибок в логах обнаружено не было. Попробовал перемещать сбойные VM с узла на узел (в выключенном состоянии), получил ту же ошибку что и до перезагрузки, на определенных узлах кластера конфигурация VM переходила в состояние Failed.

    Начал реанимировать VM. Последовательность действий следующая.

    1. Переместил VM на узел кластера, где конфигурация доступна.

    2. Отключил все VHD от VM (в принципе это делать не обязательно, т.к. при удалении машины из кластера, а затем из Hyper-V менеджера VHD файлы сохраняются по пути их местоположения, но я решил перестраховаться).

    3. Удалил VM из кластера.

    4. Скопировал XML файл конфигурации сбойной машины в отдельное местоположение (например в папку на рабочем столе).

    5. Удалил VM из Hyper-V менеджера.

    6. Создал новую VM, указав местоположение новой конфигурации на CSV в папке старой VM. Сетевые адаптеры не подключал, диски не монтировал.

    7. Изменил конфигурацию новой VM, указал кол-во памяти, кол-во vCPU, смонтировал диски, подключил сетевой адаптер к нужному vSwitch.

    8. Добавил машину в кластер (VM запускать не нужно).

    9. Скопировал XML файл конфигурации новой VM в отдельное местоположение (например в папку на рабочем столе).

    10. Открыл XML файл конфигурации старой (сбойной) VM в текстовом редакторе нашел блок, отвечающий за сетевые интерфейсы, скопировал GUID сетевого интерфейса. Таким же образом нашел GUID интерфейса в XML новой конфигурации и подменил его старым. Сохранил конфигурацию.

    11. Скопировал XML файл конфигурации в местоположение VM с заменой исходного файла.

    12. Запустил VM, после загрузки проверил состояние интерфейса, IP не должен измениться, т.к. для гостевой системы GUID интерфейса остался прежним. Проверил доступность ресурсов (ipconfig, ping, tracert и т.д.)

    Повторил вышеописанные действия для всех сбойных VM.

    В гостевых системах 2008R2 диски не являющиеся системными разделами (например диски под базы данных Exchange) после старта новой машины находятся в состоянии offline, не нужно пугаться что при первом запуске почтовик не смонтирует базы. Переводим диски в состояние online, перезапускаем VM (или соответсвующие службы) и наблюдаем корректную работу сервисов.

    Если в сбойной VM использовалось несколько сетевых интерфейсов необходимо искать GUID в файле конфигурации ориентируясь на MAC адрес интерфейса, даже если он динамический, он отображается в свойствах VM.

    Вроде все, всем удачи в работе.

    • Помечено в качестве ответа elmuerto 28 сентября 2015 г. 7:55
    28 сентября 2015 г. 7:55