Решение проблем с созданием виртуального коммутатора Hyper-V

В большинстве случаев создание виртуального коммутатора Hyper-V — несложная задача. Однако время от времени вы можете обнаружить, что Hyper-V отклоняет ваш запрос и выдает сообщение об ошибке, в котором говорится, что произошла ошибка при применении изменений свойств виртуального коммутатора. Пример такой ошибки вы можете увидеть ниже.

Приведенное выше сообщение об ошибке появляется только при создании внешнего виртуального коммутатора. Причина этого в том, что в отличие от внутреннего или частного виртуального коммутатора внешний виртуальный коммутатор привязан к физическому сетевому адаптеру. Именно эта привязка позволяет виртуальным машинам, подключенным к виртуальному коммутатору, взаимодействовать с внешним миром.

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

Таким образом, правило состоит в том, что у вас может быть только один виртуальный коммутатор для каждого физического адаптера Ethernet. Но что произойдет, если вы получите эту или аналогичную ошибку при попытке привязать виртуальный коммутатор к адаптеру Ethernet, который в данный момент не привязан к другому виртуальному коммутатору?

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

nvspbind /u «Дружественное имя сетевой карты»

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

Поскольку утилита NVSPBind больше недоступна, лучше всего попробовать использовать PowerShell. Вы можете использовать командлет Get-VMSwitch для отображения списка виртуальных коммутаторов, которые отображаются на вашем узле Hyper-V. Если старый виртуальный коммутатор (тот, который использовал адаптер, который вы хотите использовать для нового виртуального коммутатора) все еще существует, вы можете использовать командлет Remove-VMSwitch, чтобы избавиться от виртуального коммутатора.

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

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

Хитрость заключается в запуске команды netcfg -d. Опять же, это полностью разрушает конфигурацию вашей сети. Вы можете увидеть, как это выглядит на следующем рисунке.

После выполнения команды netcfg -d вам придется перезагрузить сервер Hyper-V. Дальнейшие действия зависят от состояния вашего сервера Hyper-V. Если вы посмотрите на рисунок ниже, вы увидите, что Windows отключила мой виртуальный адаптер Ethernet (тот, который используется виртуальным коммутатором Hyper-V), но снова включила мой обычный сетевой адаптер. Кстати, причина, по которой этот адаптер говорит Microsoft Hyper-V, заключается в том, что снимок экрана был сделан с вложенной виртуальной машины.

Если вы откроете диспетчер виртуальных коммутаторов, вы увидите, что виртуальный коммутатор также исчез.

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

Вывод

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