Tenho uma configuração bem simples: Windows Server 2012 Hyper V Host, com duas VMs (ambas Server 2012), uma para IIS, outra para SQL Server. Todos estão se conectando por meio da NIC física
Ontem à noite tentei adicionar um switch virtual e configurar NICs virtuais nas duas VMs (além da NIC física).
Eu ainda não tinha trocado os servidores para realmente usar as NICs virtuais, mas por algum motivo, isso destruiu a velocidade de conexão entre as duas VMs - mesmo que as NICs virtuais não estivessem sendo usadas. Estamos falando de 200 a 500 milissegundos a 30 a 90 segundos por solicitação!
Então, esta manhã, depois de ver o terrível impacto que teve no meu site, desativei as duas NICs virtuais, pois foi tudo o que mudei e, com certeza, as velocidades voltaram.
Em última análise, preciso fazer com que eles passem a usar v-NICs, mas primeiro preciso superar esse problema.
O que poderia estar causando isso? E o que posso fazer para solucionar isso?
Detalhes adicionais:
A configuração é realmente muito simples (o que pode ser parte do meu problema, posso estar simplificando demais o que é necessário para fazer essa configuração).
Eu tenho um único servidor com uma única NIC (física). Atualmente, esta NIC é utilizada para comunicação entre o v-host e a internet, bem como entre as duas VMs e a internet. Também é usado para comunicação intra entre as duas VMs.
Porém, estou tentando mudar a intracomunicação para passar pelo switch virtual via vNICs, liberando a NIC física para ser usada apenas para comunicação externa.
Então, adicionei um switch virtual interno ao v-host e, em seguida, adicionei uma NIC virtual a cada VM.
Depois de fazer isso, foi quando a velocidade da minha conexão – na NIC física – caiu drasticamente. Desabilitar os vNICs (por meio da configuração de rede das VMs) restaurou a velocidade ao normal.
Abaixo estão as telas de configuração da VM para a NIC física externa e vNICs internas (em apenas uma VM, pois ambas estão configuradas de forma idêntica).
Outra rodada de detalhes
Ao aprofundar um pouco mais sobre o assunto, parece que as NICs da Broadcom são notórias por problemas de desempenho. Este servidor possui duas NICs Broadcom BCM5716C. Aqui estão alguns links para discussão de problemas conhecidos:
Acesso lento à rede em máquinas virtuais - Broadcom e Hyper-V
Rede muito lenta de máquina virtual Hyper-V – VMQ – Broadcom
Então comecei a brincar com as configurações, desabilitando várias configurações, uma de cada vez. Nenhuma das alterações pareceu ter qualquer impacto no problema – se eu ativar o vNIC convidado, as velocidades de carregamento caem para mais de 25 segundos. Desative-o novamente, eles retornam para 250ms -um fator de 100!
Também tentei instalar os drivers mais recentes da Broadcom, sem diferença.
Neste ponto, sinto que é uma questão de compatibilidade entre a NIC Broadcom e o Hyper-V. Mas não quero encomendar novas NICs e ter o trabalho de fechar o site, instalá-las e configurá-las, apenas para que o problema persista.
Portanto, seria bom se eu pudesse descartar definitivamente a inclusão ou exclusão da NIC.
Configuração física da NIC no gerenciador de switch
Configuração de switch virtual no gerenciador de switch
Configuração física da NIC na VM do banco de dados
Configuração de NIC virtual na VM do banco de dados
Responder1
Eu tenho uma configuração muito semelhante. Encontrei a resposta aqui (Transferências de arquivos extremamente lentas para VM Hyper-V na máquina local)
Com o chipset Broadcom desativei as filas virtuais e toda a latência desapareceu. Faça essa alteração na NIC física, não na NIC virtual.
Responder2
AFAIK, não existe passagem física de NIC no Hyper-V. Você criou um vSwitch chamado "NIC físico", que é mapeado para um adaptador físico e habilitou o uso do sistema operacional de gerenciamento. Em cada VM, há um vNic usando essa opção. Por que você deseja mudar de um vswitch para outro? Além do "novo" não estar conectado a nada, eu realmente não vejo sentido.
O Hyper-V é inteligente o suficiente para enviar tráfego apenas do vswitch para a placa de rede física quando o tráfego é roteado para fora do host, o que significa que você já está fazendo o que está tentando alcançar.