Диагностика сбоев динамической миграции (часть 3)

• Диагностика сбоев динамической миграции (часть 2)

Введение

Как я объяснял в этой серии статей, существует ряд различных условий, которые могут привести к сбою динамической миграции Hyper-V.

В этой статье я хочу вернуться к ранее обсуждаемому сообщению об ошибке, потому что есть другая причина ошибки.

Не удалось установить соединение с хостом

Особое сообщение об ошибке, к которому я хочу вернуться, — это сообщение «Не удалось установить соединение с хостом». Точное сообщение об ошибке:

Фактическое сообщение об ошибке вы можете увидеть на рисунке A.

Рисунок A. Это одно из наиболее распространенных сообщений об ошибках динамической миграции Hyper-V.

Как я объяснил в предыдущей статье, это конкретное сообщение об ошибке часто является результатом проблемы с безопасностью. Как правило, CredSSP используется для проверки подлинности, а операция динамической миграции инициирована на сервере, отличном от того, на котором в настоящее время размещена виртуальная машина. Как объяснялось ранее, лучший способ решить эту конкретную проблему — включить проверку подлинности Kerberos и настроить ограниченное делегирование.

Однако оказывается, что эта конкретная ошибка может возникнуть, даже если Kerberos включен и правильно настроен. Проблема может возникнуть в результате входа в неправильный домен. Позволь мне объяснить.

На прошлой неделе я потратил много времени на работу над книгой по Hyper-V, которую пишу. Поскольку я не хочу вносить изменения в конфигурацию производственных систем, я настроил домен управления с именем MGMT.com. Домен MGMT.com существует на уровне хост-сервера. Его задача состоит в том, чтобы сгруппировать все узлы Hyper-V в общий домен для упрощения управления.

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

Теперь здесь все становится интереснее. На всех компьютерах на MGMT.com включена динамическая миграция, а ограниченное делегирование правильно настроено для всех моих серверов Hyper-V. Динамические миграции в этой среде работают именно так, как должны.

Однажды на прошлой неделе я немного не выспался и совершил ошибку по невнимательности. Я вошел на один из компьютеров в своем домене MGMT.com, но случайно ввел labAdministrator в качестве имени пользователя. Мой вход в систему прошел успешно, несмотря на то, что я использовал учетную запись пользователя из неправильного домена, поскольку все мои домены настроены на прием одной и той же комбинации имени пользователя и пароля.

Как вы, наверное, уже поняли, я вошел в диспетчер Hyper-V и попытался выполнить живую миграцию, но живая миграция не удалась, сославшись на показанную выше ошибку.

Причина возникновения этой ошибки заключалась в том, что ограниченное делегирование Kerberos настроено на уровне Active Directory. Поскольку я случайно вошел в недопустимый домен, я фактически не прошел аутентификацию в Active Directory, из-за чего Kerberos не работал должным образом.

Виртуальную машину нельзя переместить на конечный компьютер

Еще одно очень распространенное сообщение об ошибке: «Виртуальная машина не может быть перемещена на конечный компьютер». Аппаратное обеспечение целевого компьютера несовместимо с аппаратными требованиями этой виртуальной машины. Вы можете увидеть фактическое сообщение об ошибке, показанное на рисунке B.

Рисунок B: Процесс динамической миграции может завершиться ошибкой из-за различий в оборудовании хост-сервера.

Как вы, наверное, уже догадались, эта ошибка возникает из-за того, что физическое оборудование целевого хост-сервера слишком отличается от физического оборудования, на котором в данный момент работает виртуальная машина. В частности, ЦП сервера слишком отличается.

Чтобы показать вам, что я имею в виду, давайте взглянем на системы, вызвавшие эту конкретную ошибку динамической миграции. Приведенное выше сообщение об ошибке было вызвано попыткой переместить виртуальную машину, работающую на сервере с именем Lab7.mgmt.com, на сервер с именем Lab2.mgmt.com.

Сервер Lab7 — это более старая система, и если вы посмотрите на рисунок C, то увидите, что этот сервер оснащен процессором AMD Athlon™ II X4 630, работающим на частоте 2,8 ГГц.

Рисунок C. Этот сервер оснащен процессором AMD Athlon™ II X4 630 с тактовой частотой 2,8 ГГц.

Напротив, Lab2 — гораздо более новый сервер. Если вы посмотрите на рисунок D, то увидите, что Lab2 работает на восьмиядерном процессоре AMD FX™ 8120 с тактовой частотой 3,12 ГГц.

Рисунок D: Lab2 работает на восьмиядерном процессоре AMD FX™ 8120 с тактовой частотой 3,12 ГГц.

Несмотря на то, что на обоих серверах установлены процессоры AMD, на одном сервере установлен более старый четырехъядерный процессор, а на другом — более новый восьмиядерный процессор. Эти процессоры просто слишком отличаются друг от друга, чтобы динамическая миграция могла происходить обычным образом.

Итак, как решить эту проблему? Ну, если предположить, что о новом оборудовании не может быть и речи, решение состоит в том, чтобы использовать функцию совместимости процессоров Hyper-V. Основная идея заключается в том, что вы можете отключить возможность виртуальной машины использовать расширенные функции ЦП. Ограничивая виртуальную машину использованием только стандартных функций, становится возможной динамическая миграция виртуальной машины.

Прежде чем вы попробуете эту технику, есть несколько вещей, которые вам нужно знать. Во-первых, использование режима совместимости ЦП снижает производительность виртуальной машины. Во-вторых, вам придется на мгновение выключить виртуальную машину, чтобы включить (или позже отключить) режим совместимости ЦП.

С учетом сказанного выключите виртуальную машину. Затем щелкните правой кнопкой мыши виртуальную машину в диспетчере Hyper-V и выберите команду «Настройки» в контекстном меню. Когда появится экран настроек виртуальной машины, разверните контейнер «Процессор» и выберите контейнер «Совместимость». Теперь установите флажок «Мигрировать на физический компьютер с другой версией процессора», как показано на рисунке E, и нажмите «ОК».

Рисунок E. Установите флажок «Мигрировать на физический компьютер с другой версией процессора».

Как только виртуальная машина загрузится, вы сможете выполнить ее динамическую миграцию. Однако настоятельно рекомендуется отключить режим совместимости процессоров после завершения динамической миграции. Конечно, для этого вам потребуется снова выключить виртуальную машину, поэтому вы не сможете немедленно отключить режим совместимости.

Вывод

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

• Диагностика сбоев динамической миграции (часть 2)