Проблемы с развертыванием агента VMM? Попробуйте эти решения

Опубликовано: 16 Апреля, 2023

Пару лет назад я написал статью, в которой рассказал о некоторых препятствиях, с которыми столкнулся при устранении неполадок при развертывании агента System Center Virtual Machine Manager (VMM) на хосте Hyper-V. Однако недавно кто-то связался со мной, потому что у них были собственные проблемы с развертыванием агентов. Моей первой мыслью было отправить им ссылку на упомянутую выше статью. Однако после просмотра статьи я понял, что есть несколько дополнительных методов устранения неполадок, которые мне не хватило места для описания в исходной статье. Таким образом, я хотел бы вернуться к этой теме и поговорить о некоторых вещах, которые нужно проверить, если у вас возникнут проблемы с добавлением узла Hyper-V в VMM.

Вне времени

Если у вас возникли проблемы с развертыванием агента Virtual Machine Manager на хосте Hyper-V, первое, что вы должны сделать, — это убедиться, что часы сервера Virtual Machine Manager синхронизированы с хостом Hyper-V. Я думаю, что упоминал эту технику в своей оригинальной статье, но я хотел подчеркнуть этот момент, потому что он очень важен. Проблемы с перекосом часов могут привести к сбою процесса развертывания агента, даже если все остальное настроено правильно.

Ошибка установки агента VMM

Часто агент Virtual Machine Manager не устанавливается должным образом из-за того, что сервер VMM физически не может скопировать агент на хост Hyper-V. Когда это происходит, вы обычно видите ошибку 415, указанную в истории заданий. Полный текст этого сообщения об ошибке:

Ошибка (415) Установка агента не удалась при копировании C:Program Files:Microsoft System CenterVirtual Machine ManageragentsI3863.1.6011.0msiInstaller.exe в \имя_сервераADMIN$msiInstaller.exe.

Как и многие другие ошибки, создаваемые System Center Virtual Machine Manager, описательный текст этой ошибки может немного вводить в заблуждение. Иногда ошибка 415 сопровождается дополнительными сведениями, указывающими на то, что процесс не может получить доступ к файлу, поскольку он используется другим процессом. Сведения также могут указывать на то, что имя целевой учетной записи неверно. Мой собственный опыт показывает, что эти два фактора редко, если вообще когда-либо, указывают на истинную причину проблемы. Таким образом, я хотел поговорить о некоторых вещах, которые вы должны проверить.

Порты брандмауэра

Предполагая, что часы сервера Hyper-V совпадают с часами сервера Virtual Machine Manager и что оба сервера находятся в одном и том же домене, вам следует продолжить работу по устранению неполадок, убедившись, что никакие правила брандмауэра не препятствуют развертыванию агента. На вашем сервере Hyper-V должны быть открыты пять портов брандмауэра. Это включает:

Порт 80 (WinRM)
Порт 135 (RPC)
Порт 139 (NetBIOS)
Порт 445 (SMB через TCP)
Порт 443 (HTTPS, используемый для передачи BITS)
5985 (WinRM)
5986 (WinRM)

Есть две важные вещи, которые следует помнить об этих требованиях к порту брандмауэра. Во-первых, хотя эти порты должны быть открыты на узле Hyper-V, на котором устанавливается агент, любые брандмауэры между сервером Virtual Machine Manager и узлом Hyper-V также должны разрешать прохождение трафика через эти порты.

Второе важное замечание относительно портов брандмауэра заключается в том, что это не единственные порты брандмауэра, которые использует Virtual Machine Manager. Перечисленные выше порты используются для связи агентов, но дополнительные порты используются для других функций. Например, порт 1433 используется при обмене данными с удаленной базой данных SQL. Другой пример: порт 22 используется для связи с сервером VMware. Microsoft предлагает полный список портов, которые использует Virtual Machine Manager здесь.

Проверьте роли сервера Hyper-V.

Еще одна вещь, которую вы должны сделать, если у вас возникли проблемы с установкой агента VMM на хост Hyper-V, — это проверить роли сервера Hyper-V. Лучшие практики Microsoft уже давно утверждают, что узлы Hyper-V не должны запускать какие-либо дополнительные роли или службы. Исключением являются вспомогательные службы, необходимые для поддержки роли Hyper-V. Несколько распространенных примеров включают агенты резервного копирования и антивирусное программное обеспечение.

Однако, как бы странно это ни звучало, существует дополнительная роль сервера, которую необходимо включить перед развертыванием агента VMM. Это роль файлового сервера. Роль файлового сервера обычно включена по умолчанию на серверах Windows, но некоторые администраторы отключают ее в целях безопасности. Однако сервер Virtual Machine Manager не сможет развернуть агент на сервере Hyper-V, если на этом сервере не включена роль файлового сервера.

Проверьте общие ресурсы сервера Hyper-V.

Серверы Windows обычно включают в себя множество скрытых общих ресурсов. Эти общие папки аналогичны любым другим общим папкам с путями к файлам, за исключением того, что они создаются по умолчанию, а имя общего ресурса заканчивается знаком доллара (что говорит Windows скрыть общий ресурс). Например, для каждого из томов локального хранилища сервера существует скрытый общий ресурс.

Чтобы диспетчер виртуальных машин мог развернуть агент на сервере Hyper-V, машина Hyper-V должна включать скрытый общий ресурс с именем Admin$. Этот общий ресурс создается по умолчанию, поэтому он должен существовать, если его кто-то не удалил.

Самый простой способ убедиться, что общий ресурс Admin$ существует, — открыть окно командной строки с повышенными привилегиями на вашем сервере Hyper-V и ввести следующую команду:

Net view \<hyper-v server name> /all

Если, например, ваш сервер Hyper-V называется Hyper-v-1, тогда команда будет такой:

Net view \Hyper-v-1 /all

Когда все остальное терпит неудачу

Если вы испробовали все, что было предложено в этой статье, но по-прежнему не можете развернуть агент Virtual Machine Manager, вы можете попробовать еще одну вещь. System Center Virtual Machine Manager использует учетную запись запуска от имени, которую он использует для выполнения различных задач на узлах Hyper-V. Предполагая, что учетная запись запуска от имени является учетной записью домена (как и должно быть), попробуйте вручную добавить учетную запись запуска от имени в локальную группу администраторов сервера Hyper-V. Это гарантирует, что учетная запись запуска от имени (и диспетчер виртуальных машин) имеют разрешение делать все, что им нужно, на хосте Hyper-V.

Виртуализация