У меня есть гостевая виртуальная машина ubuntu 16.04 LTS, работающая внутри HyperV на Win10 pro v1803 (сборка 17134.345). У гостя есть подключение к Интернету через NAT виртуального адаптера Ethernet на хосте, но TCP-подключения к Интернету очень медленные (<5 КБ / с). Сам хост подключен к Wi-Fi и обычно обеспечивает соединения со скоростью МБ / с. Как я могу улучшить производительность гостевого трафика?
Виртуальная машина находится в двух разных сетях IPV4. Я не настраивал IPv6, и это единственная запущенная виртуальная машина.
гость eth0 включен 192.168.20.200/24
. В HyperV этот интерфейс подключен к VSwitch с хостом для трафика host-vm. Максимальная пропускная способность этого канала высока и соответствует ожиданиям. Задержка с хостом <1 мс.
гость eth1 включен 192.168.30.200/24
. В HyperV его интерфейс подключен к VSwitch NAT и обеспечивает подключение виртуальной машины к Интернету. Пропускная способность этой ссылки с точки зрения виртуальной машины очень мала, то есть постоянная скорость загрузки ~ 5 Кбайт / с. С другой стороны, задержка аналогична задержке хоста в диапазоне 8–9 мс для интернет-пингов.
VNat на хосте был создан с помощью PowerShell с использованием описанных шагов. в этой статье Microsoft
Я отключил функции разгрузки на гостевой системе, чтобы увидеть, увеличило ли это максимальную пропускную способность, с помощью следующих команд:
for i in rx tx sg tso ufo gso gro lro rxvlan txvlan rxhash; do
sudo ethtool --offload eth1 "$i" off
done
Но это не улучшило скорость гостевого интернета. Никакого эффекта не заметил. Я попытался перезагрузить хост и виртуальные машины, отключив и снова включив интерфейс NAT, но это тоже ничего заметно не улучшило.
Другие детали:
В PowerShell Get-NetAdapter сообщает следующую базовую информацию для vSwitch:
vEthernet (vNAT) Hyper-V Virtual Ethernet Adapter #6 19 Up 00-15-5D-02-E8-0F 10 Gbps
TCP-соединения быстро упадут ниже 5 КБ / с. Apt-get может часами сидеть на небольших пакетах:
0% [3 InRelease 104 kB/109 kB 95%] 2,889 B/s
...
Fetched 323 kB in 1min 1s (5,280 B/s)
Дома speedtest-cli на гостевом компьютере сообщает 1,91 Мбит / с вниз, 13,02 Мбит / с вверх. На хосте 80 Мбит / с вниз, 20 Мбит / с вверх.
В университете speedtest-cli на гостях сообщает о 5,9 Мбит / с вниз, 8,41 Мбит / с вверх. На хосте 112,53 Мбит / с вниз, 154,13 Мбит / с вверх.
Гостевое ядро - Ubuntu 16.04 (xenial) Linux host 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
. Похоже, что это ядро встроено в драйверы для Hyperv, если я в это верю. список.
Я нашел правдоподобное объяснение замедлению. Я думаю, это связано с небольшим объемом доступной виртуальной памяти. - хост - это среда с ограничениями по оперативной памяти (ноутбук).
Я заметил, что когда я страдаю от этих низких скоростей, в диспетчере задач процесс Vmmem
находится в торпоре, потребляя значительную часть доступной виртуальной памяти (~ ГБ) и с относительно высокой загрузкой процессора. Я подозреваю, что сетевые буферы запутываются в этом беспорядке, их меняют местами или просто отбрасывают, потому что они не могут быть поставлены в очередь в любом месте памяти.
Я не совсем уверен, как лучше всего заставить Vmmem исправлять свое состояние, когда он начинает действовать. Я попытался освободить память, закрыв все приложения на хосте и на виртуальной машине. Также попытался закрыть все виртуальные машины, но он продолжал вращаться. Как я уже упоминал в вопросе, я также пробовал перезагрузку хоста, но обычно перезагрузки хоста win10 поддерживают работу виртуальных машин, поэтому, вероятно, плохое состояние вернется и при новой загрузке хоста.
Один из способов решить эту проблему - закрыть виртуальную машину в Hyper-V, перезагрузить хост и затем снова запустить виртуальную машину. Вероятно, это не устраняет основную причину (недостаточно памяти ?, недостаточно памяти, выделенной в HyperV?), Но, по крайней мере, восстанавливает приличную скорость сети в-vm.
Эти скорости сети, которые я опубликовал в вопросе, повсюду. Я, конечно, не ожидал, что RX будет меньше TX на моем асимметричном домашнем интернет-соединении.