Melhorando o fraco desempenho da rede no Hyper-V

2

Estou usando o Hyper-V em um Surface Pro que executa o Windows 10 (compilação 17134). Existe uma VM convidada única executando o Debian mais recente para desenvolvimento. Esta é uma superfície de alta especificação com 1 TB SSD, i7 e 16 GB de RAM.

As interfaces de rede são incorporadas:

  • Adaptador sem fio "Marvell AVASTAR", driver mrvlpcie8897.sys (versão 15.68.9120.47, 18/10/2017).
  • "Adaptador Ethernet de superfície", driver msux64w10.sys (versão 10.4.124.2017, 27/02/2017).

Os drivers são do Windows Update e o firmware do sistema está atualizado.

O desempenho da rede para a VM parece ser ruim, especialmente quando o host está conectado a uma rede sem fio. Observe que este é o desempenho da rede interna entre o host e a máquina virtual. O tráfego não está saindo do host para outras redes.

Testes com ping

Estatísticas com rede desativada (sem conexão com fio ou sem fio):

Ping statistics for 172.19.2.236:
    Packets: Sent = 1000, Received = 998, Lost = 2 (0% loss)

Versus estatísticas conectadas a uma rede sem fio local:

Ping statistics for 172.19.2.236:
    Packets: Sent = 1000, Received = 958, Lost = 42 (4% loss)

Ambos os testes foram realizados sequencialmente sob a mesma carga, eles são repetíveis. O host não é esticado para desempenho. Dois pacotes perdidos são incomuns para uma rede virtualizada, mas a perda de 4% é notável. Antes de migrar para o Hyper-V, o mesmo host executava vários Windows & VMs Linux em VMware Workstation sem problemas.

Uma seqüência típica se parece com:

Reply from 172.19.2.236: bytes=32 time<1ms TTL=64
Request timed out.
Reply from 172.19.2.236: bytes=32 time=1976ms TTL=64

A pausa de 2 segundos é evidente, pois o console parece congelar e as sessões X encaminhadas não respondem. Isso torna as sessões interativas frustrantes, mas não inutilizáveis.

Informações de rede do Hyper-V

O comutador virtual padrão é usado, que fornece o NAT para a Internet. Nenhuma alteração foi feita nas configurações de rede dentro do Hyper-V.

Eu tentei desativar o recurso Virtual Machine Queue (VMQ), que não fez diferença mensurável.

Depuração dentro da VM

A depuração dentro da VM mostra que a eth0 parece se conectar regularmente, sugerindo que a rede da VM seja redefinida ou desconectada temporariamente:

Jun  7 21:35:34 vm NetworkManager[1327]: <info>  [1528403734.3473] device (eth0): carrier: link connected

Observe que o desempenho ruim acontece mesmo quando o NetworkManager não está em execução.

Descobri separadamente que as conexões são redefinidas quando as conexões do host mudam, por exemplo, passando de com fio para sem fio ou para uma VPN. Em comparação com outros produtos hipervisores, isso parece incomum.

Alguém pode sugerir mais diagnósticos ou uma solução potencial para esse desempenho?

    
por David 07.06.2018 / 16:13

0 respostas