Устранение распространенных ошибок Hyper-V (часть 2)

Введение

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

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

Мой сервер был настроен так, что он действовал исключительно как хост-сервер и даже не был членом домена. По сути, это было развертывание Windows Server 2008 R2 по умолчанию с Hyper-V. Все мои виртуальные серверы находились на внешнем массиве хранения, на который не повлиял скачок напряжения.

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

Сначала казалось, что мой план работает без сучка и задоринки. Однако вскоре я понял, что у меня были периодические проблемы с подключением к сети. Например, мне иногда не удавалось подключиться к сетевым дискам. У меня также были проблемы с подключением к удаленному рабочему столу. Иногда к удаленному рабочему столу не подключались все, а в других случаях соединение некоторое время работало нормально, а затем прерывалось.

Мне не потребовалось много времени, чтобы обнаружить, что причиной моих проблем с сетью было то, что Windows Server 2008 R2 неправильно идентифицировал мой основной сетевой адаптер. Несмотря на то, что я использовал карту Netgear, Windows идентифицировала ее как карту Realtek. Излишне говорить, что я загрузил правильный драйвер и установил его в систему.

Я бы подумал, что установка правильного драйвера будет простым решением, но исправление драйвера на самом деле привело к цепной реакции других проблем. Первая из этих проблем заключалась в том, что после исправления сетевого драйвера ни одна из моих виртуальных машин не смогла получить доступ к сети. Причина, по которой это произошло, заключалась в том, что единственным программным компонентом, привязанным к физическому сетевому адаптеру, является протокол виртуального коммутатора Microsoft. Раздел хоста и все виртуальные машины полагаются на виртуальные сетевые адаптеры, которые связаны с физическим сетевым адаптером, как если бы физический сетевой адаптер был сетевым коммутатором. Смена драйвера для моей сетевой карты привела к разрыву связи виртуального коммутатора.

Самый простой способ решить эту проблему — просто удалить роль Hyper-V, а затем переустановить ее. По прошлому опыту я знал, что при удалении роли Hyper-V все виртуальные машины остаются в системе. Если позже вы решите переустановить роль Hyper-V, все виртуальные машины останутся нетронутыми.

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

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

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

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

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

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

Я буду первым, кто признает, что этот шаг не всегда может быть необходим. Большинство сетей настроены на динамическое назначение IP-адресов машинам по мере их подключения к сети. Однако в моем случае все виртуальные серверы, которые работали на этом конкретном хосте Hyper-V, ранее были настроены со статическими IP-адресами. На самом деле все мои лабораторные хосты подключены к изолированному сегменту сети, который даже не имеет доступа к DHCP-серверу. Как только я повторно применил статические IP-адреса к каждой виртуальной машине, сетевое подключение было восстановлено, и с миром все было в порядке.

Вывод

Поскольку Windows Server 2008 R2 является зрелым продуктом, мне кажется странным, что операционная система все еще может неправильно идентифицировать физические сетевые адаптеры. По-видимому, урок, который нужно усвоить здесь, заключается в том, что при настройке нового хост-сервера хорошей идеей будет уделить немного времени и убедиться, что Windows правильно идентифицировала все ваше серверное оборудование. Потратив несколько минут на предварительную быструю проверку оборудования, вы сэкономите немало времени в дальнейшем.

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