В данной инструкции мы рассмотрим варианты настройки сетей Hyper-V, расскажем для чего служат каждый тип виртуального коммутатора и базовую настройку каждого из них.
Используются 2 виртуальные машины на ОС Windows Server 2019. Для выполнения действий ниже необходимо иметь процессор с поддержкой аппаратной виртуализации, а также в настройках BIOS/UEFI включить виртуализацию. Также необходимо установить Hyper-V.
Для того, чтобы создать виртуальное сетевое устройство необходимо зайти в Диспетчер Hyper-V → Диспетчер виртуальных коммутаторов. На выбор Hyper-V предлагает 3 типа коммутаторов: внешний, внутренний и частный. Разберемся для чего нужен каждый из них.
Настройка внешней сети
Если вам необходимо, чтобы ваша виртуальная машина была доступна в вашей локальной сети и могла выходить в интернет, то выберите тип внешний.
Для этого в диспетчере виртуальных коммутаторов выберете внешний коммутатор, нажмите создать виртуальный коммутатор присвойте ему имя, а затем подключите его к вашей виртуальной машине.
Рисунок 1 — Диспетчер виртуальных коммутаторов
Для этого зайдите в параметры виртуальной машины, выберите слева пункт Установка оборудования, затем в списке справа сетевой адаптер → добавить.
Рисунок 2 — Параметры сетевого адаптера
Далее перейдите в пункт слева сетевой адаптер и в списке виртуальный коммутатор выберете ваш новый виртуальный коммутатор. Теперь он должен появиться внутри ВМ.
Принцип работы с ним практически не отличается от работы с сетевым адаптером на обычном компьютере. В настройках сети вам необходимо будет прописать IP вашего сетевого шлюза (роутера/свича) и назначить IP машины.
Для этого нужно открыть выполнить ввести и открыть ncpa.cpl на виртуальной машине, нажать ПКМ на сетевой адаптер vEthernet (в случае, если на вашей ВМ установлен только один виртуальный сетевой адаптер, то в оснастке он будет единственным), зайти в Свойства → IP версии 4 → Свойства и прописываем IP-адрес, маску подсети и адрес сетевого шлюза.
Далее на ВМ включите сетевое обнаружение. Зайдите в Панель управления → Центр управления сетями и общим доступом → Изменить дополнительные параметры общего доступа и в каждом профиле сети включите сетевое обнаружение.
Рисунок 3 — Настройка общего доступа
Затем попробуйте запустить ping до машины по этому внешнему адресу. Если ВМ пингуется, значит она доступна для других устройств в локальной сети.
Настройка внутренней сети
Если вы хотите настроить доступ с вашей хост-машины и между виртуальными машинами, то выбирайте тип внутренний.
В данном случае сетевой шлюз указывать не нужно; только прописать IP-адрес и маску подсети и включить сетевое обнаружение на ВМ.
Также после того, как вы создали внутренний коммутатор, на хост-машине зайдите в выполнить (Win+R) → введите ncpa.cpl → Enter. Там вы обнаружите Hyper-V Virtual Ethernet Adatpter, зайдите в свойства этого устройства и также пропишите IP-адрес и маску подсети в свойствах IPv4 в свойствах адаптера, чтобы хост-машина смогла взаимодействовать с ВМ по внутренней сети.
Обратите внимание! Для того, чтобы виртуальные машины и хост-машина смогли общаться между собой по внутреннему виртуальному коммутатору, необходимо, чтобы они были в одной подсети.
Например:
Вы назначили ВМ1 IP-адрес 187.255.1.1 и маску подсети 255.255.255.0
Значит, у ВМ2 и хост-машины должен быть IP-адрес в диапазоне 187.255.1.2-254 и такая же маска подсети.
Проверяем работу внутренней сети так же через PING.
Рисунок 4 — Скриншот с хост-машины
Настройка частной сети
Если вам нужна сетевая коммуникация только между ВМ, то выберите частную сеть.
Частная сеть практически ничем не отличается от внутренней; только тем, что хост-машина не может подключаться к виртуальным машинам.
Действия для настройки частной сети идентичны таковым при внутренней, с тем отличием, что виртуальный сетевой адаптер не появится на хост-машине, и вам нужно будет только прописать сетевые конфигурации ВМ в ncpa.cpl.
Что такое Default Switch?
Этот тип виртуального коммутатора создаётся гипервизором автоматически и использует технологию NAT для выхода в интернет.
Подходит только в тех случаях, когда на ВМ вам нужен только выход в интернет.
IP-адрес назначается автоматически и динамически, что значит, что он будет постоянно меняться, а hostname не успевать обновляться, поэтому не подходит для настройки сетевого взаимодействия между виртуальными машинами и устройствами в локальной сети.
Продолжая цикл статей посвященный виртуализации, сегодня мы поговорим о настройке сети в Hyper-V. Основное внимание мы уделим теории, а именно разберем как устроены виртуальные сети и как они взаимодействуют с реальными. Потому что, как показывает практика, многие администраторы, в отсутствие простых и понятных материалов по данному вопросу, вынуждены осваивать настройку сети в Hyper-V методом «научного тыка».
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
С одной стороны, ничего сложного в настройке сетей для виртуальных машин нет, с другой многие начинают путаться во всех этих адаптерах, с трудом понимая, где реальный, где виртуальный, и чем они друг от друга отличаются. Постараемся внести ясность.
За настройку сетей в Hyper-V отвечает Диспетчер виртуальных коммутаторов, если мы откроем его, то увидим следующую картину:
Как видим, нам доступно создание трех типов сетей: внешней, внутренней и частной. Разберемся подробнее, для чего нужны эти сети и в чем разница между ними.
Внешняя сеть
Самый распространенный тип сети, который позволяет виртуальным машинам взаимодействовать с внешними сетями и хостом. При ее создании необходимо выбрать один из физических сетевых адаптеров, через который данная виртуальная сеть будет соединяться с внешними сетями.
Как мы уже писали, основу виртуальной сети составляет виртуальный коммутатор. При создании внешней сети, Hyper-V создает виртуальный коммутатор, к которому через виртуальные сетевые адаптеры (vNIC) подключаются как виртуальные машины, так и хост. Физический адаптер отключается от хоста и по сути становится физическим портом виртуального коммутатора, через который он подключается к внешней сети.
В этом нетрудно убедиться, после создания внешней сети на хосте появляется Адаптер Ethernet для виртуальной сети Hyper-V, на который переносятся все настройки с физического адаптера.
А в свойствах физического адаптера остался только Расширяемый виртуальный сетевой коммутатор в Hyper-V.
В случае с внешней сетью следует четко понимать, что хост, точно также как и виртуальные машины, подключается к виртуальному коммутатору через виртуальный сетевой адаптер. Физический сетевой адаптер, после создания внешней сети становится портом виртуального коммутатора, через который он подключается к внешней сети. Поэтому все сетевые настройки хоста следует производить только на виртуальном сетевом адаптере.
Также имеется возможность создания внешних сетей, изолированных от хоста, в этом случае виртуальный сетевой адаптер не создается, а физический интерфейс отключается от хоста, обслуживая только виртуальный коммутатор. Для этого при создании внешней сети необходимо снять галочку Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру.
Данная конфигурация позволяет успешно виртуализировать пограничные сетевые устройства, надежно отвязав их от внутренней сети и хоста. Например, мы можем создать две внешних сети, одна из которых будет подключена к локальной сети, вторая к интернет и осуществлять выход во внешнюю сеть через роутер на виртуальной машине, при этом и хост, и локальная сеть будут надежно изолированы от интернет, несмотря на то, что кабель внешней сети физически будет подключен к сетевому адаптеру хоста.
Внутренняя сеть
Как следует из ее названия, внутренняя сеть предназначена для подключения виртуальных машин и хоста и не предусматривает соединения с внешними сетями. При ее создании также создается виртуальный сетевой адаптер для хоста, который оказывается подключен к виртуальному коммутатору внутренней сети и должен быть сконфигурирован в соответствии с настройками виртуальной сети.
К внешней сети хост остается подключен через физический адаптер, настройки которого не затрагиваются. Данная конфигурация чаще всего используется для учебных и исследовательских целей, позволяя создавать и моделировать различной сложности сетевые конфигурации не затрагивая рабочие сети предприятия.
Внутренняя сеть c NAT
Данная возможность появилась начиная с Windows Server 2016, Hyper-V Server 2016 и Windows 10. Подробнее читайте в нашей статье: Настраиваем сеть NAT в Hyper-V
Частная сеть
Частная сеть отличается от внутренней тем, что виртуальный коммутатор может быть подключен только к виртуальным машинам и изолирован от хоста.
Данный вид сетей может быть использован также в учебных и исследовательских целей, а также для создания изолированных участков сети, например DMZ.
В этом случае связь между внешней и частной сетью будет осуществляться через одну из виртуальных машин, которая должна быть подключена к обеим сетям.
Как видим, Hyper-V дает в руки администратора весьма гибкий и мощный инструмент, позволяющий создавать весьма сложные сетевые конфигурации и управлять ими.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Статья посвящена особенностям управления виртуальными машинами Hyper-V из консоли PowerShell. Мы рассмотрим создание виртуальных коммутаторов и виртуальных машин, изменение настроек ВМ и управление ими. Вы сможете использовать рассмотренные команды для ручного управления своими ВМ или в PowerShell скриптах для автоматизации различных задачей.
Содержание:
- Установка роли Hyper-V в Windows Server и Windows 10
- Создаем виртуальный коммутатор Hyper-V с помощью PowerShell
- Создание и изменение настроек виртуальной машины Hyper-V с помощью PowerShell
- Используем PowerShell для управления виртуальными машинами Hyper-V
Установка роли Hyper-V в Windows Server и Windows 10
Для установки роли Hyper-V хост должен иметь процессор, поддерживающий виртуализацию со SLAT. В Windows Server для установки роли Hyper-V используется команда:
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
В десктопных редакциях (Windows 10 и 11) роль Hyper-V устанавливается так:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V –All
Для управления хостом Hyper-V на компьютере должен быть установлен модуль Hyper-V. Полный список команд в модуле (зависит от версии Windows) можно вывести так:
Get-Command -Module hyper-v
В Windows Server 2022 в модуле Hyper-V доступно 245 командлетов.
Вывести полный список настроек хоста Hyper-V можно с помощью команды:
Get-VMHost|fl *
Чтобы вывести только информацию о количестве доступных ядер и RAM:
Get-VMHost| select LogicalProcessorCount, MemoryCapacity
Чтобы изменить настройки хоста Hyper-V используется командлет Set-VMHost. Следующая команда изменит пути по-умолчанию для хранения виртуальных дисков и конфигурационных файлов ВМ:
Set-VMHost -VirtualMachinePath D:\VM -VirtualHardDiskPath 'D:\VM\VHD'
Создаем виртуальный коммутатор Hyper-V с помощью PowerShell
Прежде всего на сервере Hyper-V нужно создать виртуальный коммутатор. Виртуальные машины смогут получать доступ к сети только через виртуальный коммутатор.
Выведем список доступных физических адаптеров на хосте Hyper-V:
Get-NetAdapter | where {$_.status -eq "up"}
Если ваш сервер поддерживает SR-IOV (Single-Root Input/Output (I/O) Virtualization), обратите внимание, что нужно включать эту опцию во время создания коммутатора. Включить SR-IOV для существующего vSwitch нельзя. Более подробно это описано в статье Включаем поддержку SR-IOV для виртуальных машин Hyper-V.
Создайте виртуальный внешний коммутатор:
New-VMSwitch -Name "ExtVMSwitch" -AllowManagementOS $True -NetAdapterName Ethernet0 -SwitchType External
Создание и изменение настроек виртуальной машины Hyper-V с помощью PowerShell
Для создания новой виртуальной машины используется командлет New-VM. В этом примере мы создадим новую ВМ второго поколения с 1 ГБ RAM и vhdx диском размером 5 Гб.
$VMName = "spb-dmz2"
$VM = @{
Name = $VMName
MemoryStartupBytes = 1Gb
Generation = 2
NewVHDPath = "C:\HV\$VMName\$VMName.vhdx"
NewVHDSizeBytes = 5Gb
BootDevice = "VHD"
Path = "C:\HV\$VMName"
SwitchName = "ExtVMSwitch"
}
New-VM @VM
Рассмотрим команды, которые можно использовать для изменения настроек виртуальных машин.
Увеличить размер RAM для ВМ:
Get-VM -Name spb-dmz1| Set-VMMemory -StartupBytes 2Gb
Изменить количество vCPU:
Set-VMProcessor spb-dmz1 -Count 2
Разрешить автозапуск для виртуальной машину Hyper-V:
Get-VM –VMname spb-dmz1 | Set-VM –AutomaticStartAction Start
Чтобы подключить дополнительный виртуальный диск в ВМ, нужно сначала создать его:
New-VHD -Path 'C:\VM\test1.vhdx' -SizeBytes 2GB
А затем подключить к ВМ:
Add-VMHardDiskDrive -VMName spb-dmz1 -Path 'C:\VM\test1.vhdx'
Используем PowerShell для управления виртуальными машинами Hyper-V
Вывести список виртуальных машин на хосте Hyper-V:
Get-VM
Команда вернула список ВМ с несколькими базовыми характеристиками. Чтобы вывести все свойства ВМ, выполните:
Get-VM -Name spb-dmz1 | fl *
Вывести только включенные ВМ:
Get-VM | where {$_.State -eq 'Running'}
Запустить виртуальную машину:
Start-VM -Name spb-app01
Запустить все выключенные виртуальные машины:
Get-VM | where {$_.State -eq 'Off'} | Start-VM
Выключить ВМ (корректное выключение через гостевую ОС):
Stop-VM -Name spb-app01
Чтобы выключить ВМ по питанию используется ключ TurnOff:
Stop-VM -Name spb-app01 –TurnOff
Зависшие ВМ можно выключить так.
Подключить ISO файл в виртуальное CD/DVD устройство:
Set-VMDvdDrive -VMName spb-app01 -Path c:\iso\WinSrv2022.iso
Чтобы перенести все файлы ВМ на лету на другой диск, используйте команду:
Move-VMStorage spb-app01 -DestinationStoragePath D:\VM\spb-app01
Увеличить или сжать виртуальный диск можно с помощью команды Resize-VHD:
Resize-VHD -Path 'C:\VM\fs01.vhdx' -SizeBytes 50Gb
Создать чекпоинт (снапшот) указанной ВМ:
Get-VM -Name spb-app01| Checkpoint-VM -SnapshotName "before install patch"
Вывести список доступных чекпоинтов:
Вернуть состояние ВМ из предыдущему чекпоинту:
Restore-VMCheckpoint -Name "before install patch" -VMName spb-app01 -Confirm:$false
Удалить снапшот:
Remove-VMCheckpoint -VMName spb-app01 -Name "before install patch"
Экспорт, импорт и клонирование ВМ описаны подробно в статье по ссылке:
Export-VM -Name spb-app01 -Path 'C:\VHD\export' -CaptureLiveState CaptureCrashConsistentState
Получить IP адреса гостевых ОС виртуальных машин:
Get-VM | Select -ExpandProperty NetworkAdapters | Select VMName, IPAddresses, Status
Подключиться к консоли определенной виртуальной машины:
vmconnect.exe localhost spb-app01
Для подключения PowerShell сессией напрямую к гостевым ОС виртуальных машин через шину vmbus можно использовать PowerShell Direct (доступен для гостевых ОС Windows Server 2016, Windows 10 и новее). Можно использовать командлеты Invoke-Command (для запуска скриптов) и Enter-PSSession (для входа в интерактивную PowerShell сессию):
Invoke-Command -VMName spb-app01 -ScriptBlock {Get-Process}
Enter-PSSession -VMName spb-app01
Для копирования файлов с хоста Hyper-V в виртуальную машину через PowerShell Direct используйте:
$PSSession1 = New-PSSession --VMName spb-app01 -Credential (Get-Credential)
Copy-Item -ToSession $PSSession1 -Path C:\iso\win10.iso -Destination D:\ISO\
Вы можете использовать PowerShell для локального или удаленного управления виртуальными машинами на хостах Hyper-V (как на Windows Server в режимах Full GUI или Core, так и на Free Windows Hyper-V Server, или Windows 10) как отдельно, так и в дополнении к графическим средствам управления Hyper-V Manager и Windows Admin Center.
This article will examine how to create and configure an internal virtual switch to enable the running of virtual machines wholly isolated from a physical network with Hyper-V Manager, an excellent virtualization solution used in Windows 10 or Windows 11 operating systems.
How to Create an Internal Network on Hyper-V
The main reason for using an Internal network in the Hyper-V Manager virtualization program is to ensure that the virtual machines are entirely independent of the physical network and only communicate with the host computer.
Creating an Internal Switch with Hyper-V is very simple. Before making this network structure, you can take a look at our article, Create External Virtual Switch.
To better understand the Internal network using Hyper-V, create two virtual machines and follow the steps in this article. Ping between virtual machines will be successful, and Ping will also be available on the physical computer’s network card.
How to Configure an Internal Network
Here are the steps to configure the Internal Switch with Hyper-V on the Windows 10/11 operating system:
Step 1
First, run Hyper-V Manager from the Windows menu.
Step 2
From the Actions panel, click the Virtual Switch Manager option.
Step 3
In the Switch Manager window, select the Internal network and click the Create Virtual Switch button.
Step 4
Type a name for the Internal Switch and click the OK button.
Step 5
To configure the settings of a virtual pc installed on Hyper-V, you need to open its settings window within the Hyper-V Manager. For example, you can access the settings by clicking the Right Button / Settings on the Windows 7 virtual machine.
Step 6
Click Network Adapter in the left panel, select the HyperVInternal you created from the Virtual Switch setting, and click OK.
Step 7
Configure a second virtual machine configuration to test the network structure. Select HyperVInternal for Windows 10 as below and click OK.
Step 8
Run the Windows 7 and Windows 10 virtual machines.
Step 9
Configure the Windows 7 network adapter IP settings as follows.
Step 10
Configure the Windows 10 virtual machine IP settings as follows.
Step 11
To test the network connection, ping the default gateway of 192.168.10.1 from the virtual appliances. The ping operation will fail, as shown in the following image.
Step 12
Ping from Windows 7 to Windows 10 virtual machine will be successful.
Step 13
Pinging from Windows 10 to Windows 7 machines will be successful as follows.
Step 14
The reason for the failed result when pinging the default gateways of the virtual machines is the absence of a configured Internet Network Switch on your physical computer.
Step 15
Configure the vEthernet IP configuration and click OK to save the settings.
Step 16
Finally, the network connection can be tested by pinging the virtual machines to the default gateway. The image below illustrates that pinging the IP address 192.168.10.1 from Windows 7 and Windows 10 guest machines is successful.
Hyper-V Internal Network Configuration ⇒ Video
You can watch the video below to perform the Internal network configuration steps using Hyper-V and subscribe to our YouTube channel to support us!
Conclusion
In this article, we have created an Internal Virtual Switch and examined how virtual machines communicate in this network structure. In short, with this type of network, virtual machines operate independently of the physical network. Also, virtual machines can only access the physical device. Thanks for following us!
TolgaBagci
Hi, I’m Tolga, a computer expert with 20 years of experience. I help fix computer issues with things like hardware, systems, networks, virtualization, servers, and operating systems. Check out my website for helpful info, and feel free to ask me anything. Keep yourself in the loop about the newest technologies!
Вы тут: Главная → Windows → Нюансы виртуальных коммутаторов Hyper-V и приоритета сетевых интерфейсов
Однажды я заметил, что с ноутбука очень долго загружались фотографии в Google Photos. Я посмотрел торренты, и они тоже раздавались со скоростью значительно ниже ожидаемой. Зайдя в SpeedTest, я увидел такую картину:
Я начал разбираться…
[+] Сегодня в программе
Первый этап диагностики
Мой ноутбук был подключен по Wi-Fi к двухдиапазонному маршрутизатору ASUS RT-N66U. Низкая скорость наблюдалась на обеих частотах, однако в других ПК и телефоне все было нормально. С подключением к проводной сети при отключенном Wi-Fi все тоже было в порядке.
Все пути вели к беспроводному адаптеру Intel Centrino Advanced-N 6205 в ноутбуке. Он был не новый, и свежие драйверы к нему давно не выпускали. У меня была установлена последняя версия с WU. Поэтому я с легким сердцем удалил адаптер из диспетчера устройств, добавил снова, и все наладилось.
Повод для рассказа появился, когда спустя какое-то время проблема повторилась. Я воткнул кабель Ethernet, но скорость исходящего соединения осталась низкой. Отключился от Wi-Fi – скорость поднялась к ожидаемым 90+ Мбит/с.
Получается, при подключении одновременно к Ethernet и Wi-Fi система использовала беспроводное соединение с возродившейся проблемой.
На каждом заборе написано, что в Windows проводное подключение имеет приоритет над беспроводным. Другими словами, если вы одновременно подключены к Ethernet и Wi-Fi, в Интернет вы будет ходить по проводу.
У меня все было наоборот, и тут стоит достать из коробки еще один фрагмент пазла, который я держал в уме, но пока не пытался пристроить в картину.
Виртуальные коммутаторы
У меня виртуальные машины крутятся на Hyper-V, а в сеть ходят через созданный виртуальный коммутатор. Поскольку ноутбук почти всегда был подключен только к Wi-Fi, виртуальный коммутатор я создавал на основе адаптера беспроводной сети. Появившийся позже в 1709 «коммутатор по умолчанию» я не использовал.
Когда я удалил беспроводной адаптер из диспетчера устройств, мой виртуальный коммутатор исчез, но я заметил это не сразу, а только спустя некоторое время при следующем включении ВМ – в ней не было сети.
Я создал виртуальный коммутатор заново, но измерить скорость исходящих подключений в тот момент мне в голову не пришло. Лишь напоровшись на проблему снова, я назначил Hyper-V главным подозреваемым.
Дело в том, что хост использует виртуальный сетевой адаптер vEthernet для подключения к сети. Даже если виртуальный коммутатор Hyper-V основан на беспроводном адаптере, подключение к vEthernet считается проводным.
Это не вполне очевидно, хотя название адаптера намекает 
Приоритет маршрутов
При этом у меня подключение по vEthernet преобладало над обычным проводным подключением Ethernet. Сам я приоритеты не менял, но на всякий случай убедился в этом.
Приоритет маршрута определяется метрикой, и в дополнительных параметрах IPv4 сетевого адаптера можно посмотреть, задается ли она автоматически (и указать значение, если нужно). Но давайте перейдем в командную строку.
Настройка приоритетa для сетевых интерфейсов
Из вывода всех команд я убрал лишнее, чтобы сфокусироваться на проблеме, а английский – язык моей ОС.
Команда ipconfig /all выводит список сетевых адаптеров и их IP-адреса.
ipconfig /all Ethernet adapter Ethernet: Description . . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection IPv4 Address. . . . . . . . . . . : 192.168.1.149(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Ethernet adapter vEthernet (Wi-Fi): Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter IPv4 Address. . . . . . . . . . . : 192.168.1.211(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Ethernet adapter vEthernet (Default Switch): Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2 IPv4 Address. . . . . . . . . . . : 192.168.70.17(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.240
Сводку по сетевым интерфейсам выдает команда netstat -rn | more.
netstat -rn | more ===========================================================================
Interface List
4...3c 97 0e ce b8 41 ......Intel(R) 82579LM Gigabit Network Connection
32...a4 4e 31 94 9a 28 ......Hyper-V Virtual Ethernet Adapter
22...a4 4e 31 94 9a 29 ......Microsoft Wi-Fi Direct Virtual Adapter #4
10...a6 4e 31 94 9a 28 ......Microsoft Wi-Fi Direct Virtual Adapter #5
9...3c 77 e6 ed 0d 46 ......Bluetooth Device (Personal Area Network)
1...........................Software Loopback Interface 1
64...00 15 5d 18 c5 02 ......Hyper-V Virtual Ethernet Adapter #2
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.211 10
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.149 20
===========================================================================
В первом блоке можно определить приоритет сетевого интерфейса по номеру слева – чем меньше номер, тем выше приоритет. Значение метрики для интерфейса отображается во втором блоке – таблице маршрутов IPv4.
В результатах команд видно, что маршрут через виртуальный адаптер 192.168.1.211 преобладает над проводным 192.168.1.149.
Раз уж я был в консоли с правами администратора, то задал метрики для каждого интерфейса на месте. Сначала вывел их список, чтобы получить имена:
netsh interface show interface Admin State State Type Interface Name ------------------------------------------------------------------------- Enabled Connected Dedicated Wi-Fi Enabled Connected Dedicated Local Area Connection* 3 Enabled Connected Dedicated vEthernet (Wi-Fi) Enabled Connected Dedicated Network Bridge Enabled Connected Dedicated Ethernet Enabled Connected Dedicated vEthernet (Default Switch)
Затем указал метрики, поменяв значения местами:
netsh interface IP set interface interface="Ethernet" metric=10 netsh interface IP set interface interface="vEthernet (Wi-Fi)" metric=20
Теперь, подключив одновременно Ethernet и Wi-Fi, я убедился в высокой скорости исходящего соединения. Проводное соединение получило приоритет, но проблему низкой скорости по Wi-Fi это не решало, конечно.
Второй этап диагностики
В настройках Hyper-V я удалил попавший под подозрение коммутатор, что убрало связь между адаптером Wi-Fi и виртуальным адаптером Hyper-V. Без лишней прокладки адаптер беспроводной сети работал как положено – скорость исходящего соединения пришла в норму.
Я пообщался с Денисом Дягилевым, и он, в принципе, задал верное направление диагностики – параметры Virtual Machine Queue (VMQ). Однако такой настройки в настройках адаптера у меня не нашлось.
Решение
Первой мыслью было занести баг в Feedback Hub, но сначала положено искать, чтобы не плодить дубликатов. По запросу hyper- v switch нашлось описание моей проблемы, а заодно и обходной путь – отключение параметра Large Send Offload Version 2 (IPv4) в параметрах виртуального адаптера Hyper-V.
Эти же сведения можно посмотреть в PowerShell:
Get-NetAdapterAdvancedProperty -Name vEthernet* | ? DisplayName -like 'Large Send Offload*' | ft -wrap
Name DisplayName DisplayValue RegistryKeyword RegistryValue
---- ----------- ------------ --------------- -------------
vEthernet (Wi-Fi) Large Send Offload Version 2 Enabled *LsoV2IPv4 {1}
(IPv4)
vEthernet (Wi-Fi) Large Send Offload Version 2 Enabled *LsoV2IPv6 {1}
(IPv6)
и поменять значение, не покидая консоль:
Get-NetAdapterAdvancedProperty -Name vEthernet* | ? DisplayName -like 'Large Send Offload*v4*' | Set-NetAdapterAdvancedProperty -DisplayValue "Disabled"
Изменив настройки адаптера, я заново создал виртуальный коммутатор и проверил скорость – все наладилось.
Конец квеста!
Заключение
Эта история произошла в 2018 году. Регрессия возникла в Windows 10 1809. Поскольку основная система у меня была в кольце Release Preview (RP), я напоролся на проблему еще до того, как сборку отозвали. Дефект устранили в декабре 2018 года накопительным обновлением KB4469342, первом после перевыпуска 1809. Мне в RP оно пришло чуть раньше, я протестировал и отписался в комментариях к статье о белках-истеричках.
Я писал материал по горячим следам, но Денис Дягилев подал идею протестировать пользу параметра Large Send Offload в практических сценариях. Времени на это я так и не нашел. А когда Microsoft устранила проблему, публикация вроде бы стала неактуальной. И я замариновал статью в черновиках – почти на 5 лет 🤷♂️
Однако за эти годы вопросы приоритета сетевых интерфейсов и особенно параметра Large Send Offload обсуждалась в чате неоднократно. И каждый раз я сетовал, что не выпустил статью в свет. На прошлой неделе тема LSO вновь всплыла 🍑🔥 со вполне современным сетевым адаптером, что окончательно убедило меня выложить материал в блог.
Бонус: о приоритете сетевых интерфейсов (когда метрики не помогают)
Иногда желаемого результата не удается достичь, меняя метрики маршрутов. Все равно LAN имеет приоритет над Mobile broadband, а Bluetooth PAN над WWAN (внезапно). В таких случаях должна помочь групповая политика, о которой я написал в канале.