Проблемы с добавлением хоста Hyper-V в Virtual Machine Manager? Сделай это
Добавление узла Hyper-V в System Center Virtual Machine Manager должно быть простым делом. Однако время от времени что-то работает не так, как должно, и процесс добавления хоста завершается со сбоем. В таком случае я хотел бы найти время, чтобы рассказать вам о некоторых возможных причинах. Когда VMM не удается добавить узел Hyper-V, в окне «Задания» обычно отображается сообщение, похожее на то, что показано на изображении ниже. Как видите, в этом окне отображается сообщение об ошибке, код ошибки и краткое описание ошибки.
На первый взгляд эта конкретная проблема может показаться относительно простой. В конце концов, номер ошибки (2940) — это код ошибки передачи файлов. Кроме того, в описании ошибки конкретно указано, что передача файла не удалась и что вы должны убедиться, что служба HTTP работает и что никакие правила брандмауэра не блокируют HTTP-трафик.
Ошибки могут ввести в заблуждение
Однако со временем я понял, что сообщения об ошибках VMM могут вводить в заблуждение. Если вы не потратите время на то, чтобы действительно понять, что происходит, вы можете потратить много времени на поиск не той проблемы. Позвольте мне показать вам, что я имею в виду.
Сообщение об ошибке, показанное на снимке экрана выше, по-видимому, означает, что HTTP-соединение не может быть установлено между сервером Virtual Machine Manager и добавляемым хостом Hyper-V. Однако если вы изучите вкладку Details, вы увидите фактические шаги, которые были выполнены для добавления узла Hyper-V в VMM. Шаг 1.2 включал установку агента на хост Hyper-V. Этот шаг выполнен успешно.
Фактически, быстрый взгляд на панель управления узла Hyper-V показывает наличие установленного агента. Дата установки подтверждает, что это новый экземпляр агента и что агент не остался с другого времени. Так, что происходит?
Если мы внимательно посмотрим на окно Jobs, то увидим, что панель Details показывает, что проблема возникла при добавлении расширений виртуального коммутатора к хосту Hyper-V. Следовательно, это та область, на которой нам необходимо сосредоточить наши усилия по устранению неполадок.
Три рекомендации
Прежде чем углубляться в процесс устранения неполадок, я рекомендую сделать несколько вещей. Сначала сравните часы на сервере Virtual Machine Manager с часами на хосте Hyper-V, с которым у вас возникли проблемы. Перекос часов может вызвать множество проблем для Windows Server и диспетчера виртуальных машин.
Еще одна вещь, которую я бы порекомендовал сделать, — это сделать паузу на несколько минут или, возможно, даже перезагрузить сервер Virtual Machine Manager и хост Hyper-V. По общему признанию, этот совет настолько банален, что звучит почти смехотворно. Однако есть метод безумия. Позволь мне объяснить.
Сообщение об ошибке, которое я показал вам на самом первом рисунке в этой статье, реально. Я работал над чем-то несвязанным, и мне нужно было добавить хост Hyper-V в Virtual Machine Manager. К моему большому удивлению, процесс не удался. Так как мне все равно придется решать проблему, я решил написать об этом. Однако сначала я не осознавал, что мой хост Hyper-V работает почти на пике своей мощности. Ошибка при добавлении хоста произошла не из-за проблемы с конфигурацией, а из-за того, что хост был настолько занят, что время ожидания диспетчера виртуальных машин истекло, прежде чем он смог завершить работу. Примерно через пятнадцать минут хост Hyper-V появился в списках всех хостов, несмотря на сообщение об ошибке. Вы можете увидеть хост и его виртуальные машины на следующем снимке экрана.
Итак, очевидно, что эту проблему было легко решить. Я просто мигрировал несколько виртуальных машин на другой хост, чтобы освободить некоторые ресурсы, и тогда все заработало. Но что, если бы проблема не решилась сама собой?
В такой ситуации я бы рекомендовал проверить три вещи. Во-первых, я бы проверил, не установлено ли на сервере Hyper-V ничего, что могло бы мешать работе VMM. В родительской операционной системе не должно быть запущено ничего, кроме Hyper-V и, возможно, агента резервного копирования и приложения для защиты от вредоносных программ. Однако стоит отметить, что программное обеспечение для защиты от вредоносных программ может вызвать проблемы для Hyper-V, если оно не настроено специально для среды Hyper-V.
Второе, что я бы порекомендовал сделать, — это проверить записи DNS как для хоста Hyper-V, так и для сервера Virtual Machine Manager. Попробуйте выполнить nslookup как для имени NetBIOS, так и для полного доменного имени и убедитесь, что разрешается правильный IP-адрес. Вы можете проверить IP-адрес хоста с помощью команды IPConfig. На рисунке ниже вы можете увидеть, где я запустил IPConfig на хосте Hyper-V и nslookup на сервере Virtual Machine Manager, чтобы убедиться, что записи DNS указывают на правильный IP-адрес. За годы я столкнулся с несколькими ситуациями, когда IP-адрес или запись DNS были необъяснимо изменены.
Третье, что я рекомендую проверить, это открытые порты брандмауэра. Учитывая, что сообщение об ошибке ссылается на HTTP, само собой разумеется, что порты 80 и 443 должны быть открыты. Однако могут быть и другие порты, которые необходимо открыть. Например, VMM использует порт 5986 для связи с агентом на узле Hyper-V. Если вам интересно, этот номер порта используется WinRM, поэтому вам также необходимо проверить и убедиться, что служба удаленного управления Windows (WS-Management) работает на хосте Hyper-V, как показано ниже.
Основные причины проблем с добавлением хоста Hyper-V
За прошедшие годы я видел довольно много примеров, когда Virtual Machine Manager не мог добавить хост Hyper-V. В подавляющем большинстве таких ситуаций проблема была связана либо с рассогласованием часов, либо с блокировкой порта брандмауэром. Список портов брандмауэра, используемых VMM, можно найти здесь.