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

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

Экспериментально я попробовал что-то отличное от обычного сетевого моста: я включил общий доступ к подключению к Интернету на своей сетевой плате, предоставив доступ к коммутатору внутренней виртуальной сети ("vEthernet (nat) 2"). Пока все хорошо - нет заметного влияния на хост, и виртуальная машина теперь также имеет полный доступ к Интернету.

Я подтверждаю наличие этой проблемы в Windows 10 1903. Для меня работал внутренний обходной путь коммутатора. Подключение к внешнему коммутатору с помощью общего ресурса карты могло бы убить мой хост-интернет, и очевидно, что vm не получит его.

Поэтому вот шаги:

1) В hyper-v -> Virtual Switch Manager создайте новый внутренний коммутатор и в типе соединения выберите Internal Network

2) В панели управления хостом перейдите в Сеть и Интернет \ Сетевые подключения -> щелкните правой кнопкой мыши на сетевой карте хоста -> Свойства. Затем перейдите на вкладку " Общий доступ " и установите флажок "Разрешить других пользователей сети...", затем выберите переключатель внутренней сети, созданный на предыдущем шаге.

3) Зайдите в настройки вашей виртуальной машины и выберите внутренний сетевой адаптер

Наслаждайся своим интернетом на своем вм. Microsoft приведёт в порядок ваши техники и исправит эту проблему.

Ура!

Для тех, у кого проблемы с ответом мистера Малины:

Имя сетевого адаптера, распознаваемое командами *-VMNetworkAdapter, отличается от того, что отображается в Windows. Вы должны перечислить доступные сетевые адаптеры с помощью "Get-VMNetworkAdapter -ManagementOS" и "Get-VMNetworkAdapter *", чтобы получить имена адаптеров, которые команда распознает. Для меня было исправлено изменение адаптера в виртуальной машине, а не в операционной системе управления (т.е. без опции -ManagementOS).

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

Попробуйте отключить VMQ

Чтобы отключить VMQ на виртуальном коммутаторе, используйте командлет Set-VMNetworkAdapter PowerShell следующим образом:

Set-VMNetworkAdapter –ManagementOS -Name <VirtualNetworkAdapterName> -VmqWeight 0

Чтобы отключить VMQ на физическом сетевом адаптере, снимите соответствующий флажок на вкладке "Дополнительно" на странице свойств сетевого адаптера.

Чтобы изменить MAC-адрес виртуального коммутатора, измените его в диспетчере Hyper-V или с помощью одного из следующих командлетов PowerShell Set-VMNetworkAdapter:

• Используя статический MAC-адрес:

  Set-VMNetworkAdapter –ManagementOS -Name <VirtualNetworkAdapterName> -StaticMacAddress <MacAddress>

• Используя динамический MAC-адрес:

  Set-VMNetworkAdapter –ManagementOS -Name <VirtualNetworkAdapterName> -DynamicMacAddress

Источник: http://www.dell.com/support/article/us/en/19/sln132131/windows-server--slow-network-performance-on-hyper-v-virtual-machines-with-virtual-machine-queue--vmq--enabled?lang=en

Я боролся с этой проблемой некоторое время сейчас сам. Тот же сценарий, та же самая дилемма. Не так много помощи онлайн, пришлось экспериментировать (даже было несколько голубых экранов), пока я не нашел решение.

Выпустив обновление Fall Creators, Microsoft объединила всех, заставив всех нас использовать их новый "переключатель по умолчанию". Проблема заключается в том, что указанный коммутатор монополизирует один из ваших сетевых адаптеров, создав NAT через службу "Общий доступ к подключению к Интернету". Если у вас был только один сетевой адаптер, вам не повезло подключить внешний виртуальный коммутатор. Хотя это позволит вам сделать это, это приводит к скорости загрузки, которую вы видите. Внутренне происходит нечто странное с NAT, но что касается того, чего я не знаю.

Следующее действительно работает, хотя, чтобы получить намеченный конечный результат:

1. Создать внутренний переключатель
2. Назначить доц. виртуальный адаптер Ethernet для коммутатора со статическим IP-адресом вне вашего диапазона DHCP (например: 192.168.1.1) и маску подсети.
3. На шаге 2 выберите сетевой адаптер и адаптер и добавьте их в мост.

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

Если вы хотите добавить больше "псевдо-внешних" переключателей, просто выполните шаги № 1 и № 2 и добавьте их в существующий мост.

Для меня я сделал некоторые из вышеперечисленных, так что, возможно, это помогло, но я также отключил "разрешить операционной системе управления совместно использовать этот сетевой адаптер" в Hyper-V Virtual Switch Manager для адаптера, который я использовал (я использую Интернет беспроводной для Hyper-V и внешний для хоста)

W10 21H2, новая установка, сетевой адаптер Wi-Fi с подключением 5 ГГц. Я попробовал предложенные обходные пути, но ничего не помогло. Проблема была решена после отключения IPv6 и повторного подключения к внешнему виртуальному коммутатору.

Это не совсем правильное решение, а скорее уродливый взлом, который работает вокруг этой проблемы:

Гостевая ОС, скорее всего, не подвержена этой проблеме, поэтому ее использование в качестве маршрутизатора (т. Е. Настройка пересылки и NAT в гостевой ОС) решит проблему - и представит кучу новых, поскольку ваша хост-машина находится за NAT сейчас.

Я почти уверен, что это ошибка, которая была введена в обновлении Fall Creators для Win10 (выпуск 1709), поскольку точно такая же настройка работала у меня до того, как я обновился. Таким образом, другой вариант будет ждать патча от Microsoft, который восстановит их порядок.

Обновление драйверов сетевого адаптера, в частности беспроводного драйвера Dell, устранило проблему медленной скорости интернета (пока).

У меня была та же проблема с Windows 10 v 1709, работающей на ноутбуке Dell M6800, подключенном к моему локальному маршрутизатору через WiFi. Я только что установил Windows 10 пару месяцев назад, поэтому я подумал, что все мои драйверы были обновлены.

После создания внешнего виртуального коммутатора скорость интернета снизилась примерно до 10% от нормальной скорости.

Я попытался использовать статические настройки DNS IPV4 в сетевых адаптерах, и это не решило медленную скорость.

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

Надеюсь это поможет.

Если вы теряете интернет при создании виртуального адаптера, вам нужно просто перейти в свойства сетевых подключений (windows+r, типа ncpa.cpl), найти свойства интернет-протокола версии 4 и снова щелкнуть свойства IPv4, а затем настроить его. выглядеть примерно так

IP-адрес: 192.168.1.55, маска подсети: 255.255.255.0, шлюз по умолчанию: 192.168.1.1

предпочтительный DNS 1.1.1.1

Хотя на основании того, что я прочитал, может быть, вам просто нужно сделать DNS 1.1.1.1, и это все

Недавно столкнулся с той же проблемой с Hyper-V 10.0.1904 на моей Windows 20H2. Пробовал кучу вещей, таких как использование внутреннего коммутатора, изменение конфигурации беспроводной сетевой карты или обновление драйвера. У меня ничего не получилось.

Кажется, эта проблема возникает только с беспроводным сетевым адаптером и Wi-Fi 5G Гц. Переключите мой Wi-Fi на 2,4G (более низкая скорость), и проблема исчезнет.

Та же проблема для меня, и, похоже, она вернется после обновлений.

Я пользователь VMWare, и меня "заставили" работать с Hyper-V. Первая заметная вещь, которая отсутствует при создании виртуального коммутатора, - это отсутствие опции NAT. Поэтому я в конечном итоге использовал "Внешний" для подключения своих виртуальных машин к физической сети. Моей первой проблемой была не скорость интернета, а неправильное поведение интернет-соединения. Это был факт, что я выставлял свои виртуальные машины внешней сети! Тогда проблема медленного / беспорядочного соединения возникла поверх этого!

Поэтому я использовал найденные здесь команды PS для создания адаптера NAT, и это работает как шарм!

https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/setup-nat-network предоставляет хороший шаг за шагом по настройке NAT для внутреннего Hyper-V сетей.

TLDR, например:

PS C:\> New-VMSwitch -SwitchName "SwitchName" -SwitchType Internal

PS C:\> Get-NetAdapter

Name                  InterfaceDescription               ifIndex Status       MacAddress           LinkSpeed
----                  --------------------               ------- ------       ----------           ---------
"SwitchName"          Hyper-V Virtual Ethernet Adapter        40 Up           00-15-5D-00-6A-01      10 Gbps
Wi-Fi                 Marvell AVASTAR Wireless-AC Net...      18 Up           98-5F-D3-34-0C-D3     300 Mbps
Bluetooth Network ... Bluetooth Device (Personal Area...      21 Disconnected 98-5F-D3-34-0C-D4       3 Mbps

PS C:\> New-NetIPAddress -IPAddress 192.168.99.1 -PrefixLength 24 -InterfaceIndex 40
PS C:\> New-NetNat -Name HyperVNat -InternalIPInterfaceAddressPrefix 192.168.99.0/24

Машины во внутренней сети не получат назначенные адреса DHCP, поэтому вам нужно будет настроить их самостоятельно. Я использовал Google DNS (8.8.8.8/8.8.4.4) в качестве DNS-серверов для внутренних машин.