Desativar Jumbo Frames no Windows Server 2016 em VM Hyper‑V (MTU 1500) — Guia prático

Em VMs Windows Server 2016, a opção textual “Disabled” para Jumbo Frame muitas vezes não aparece. A forma efetiva de desativar é voltar o MTU para 1500 bytes — dentro da VM e, se fizer sentido, também no host.

Índice

Visão geral do problema

Administradoras e administradores que trabalham com Windows Server 2016 em ambientes virtualizados (especialmente Hyper‑V on‑premises) frequentemente procuram a entrada “Disabled” na propriedade Jumbo Packet do adaptador de rede e não a encontram. Em muitos drivers — inclusive o Microsoft Hyper‑V Network Adapter — a lista apresenta somente valores numéricos (por exemplo, 1514, 4088, 9014 bytes). Na prática, voltar o MTU para 1500 (ou 1514, conforme o driver) equivale a desativar Jumbo Frames.

Este guia mostra, de forma objetiva, como aplicar essa alteração na VM Windows Server 2016 e o que considerar no host Hyper‑V. Você verá comandos prontos para copiar, validações e notas de compatibilidade que evitam quedas de performance e problemas de fragmentação.

Conceitos rápidos e por que desativar

MTU (Maximum Transmission Unit): tamanho máximo do payload IP em um quadro Ethernet. Valor “clássico” em LANs é 1500 bytes.
Jumbo Frames: quadros acima de 1500 (ex.: 9000 bytes). Podem reduzir overhead em transferências grandes, mas exigem compatibilidade ponta a ponta.
Quando desligar: se parte do caminho não aceita MTU ampliado (firewalls, roteadores, túneis, balanceadores, overlay/encapsulamentos), surgem drops, latency spikes ou retransmissões. Voltar para 1500 elimina a assimetria.

O que realmente precisa ser configurado

Em redes virtualizadas, três camadas importam:

Adaptador virtual dentro da VM (onde o sistema operacional convidado envia/recebe quadros).
vSwitch/host Hyper‑V (que encaminha o tráfego das VMs).
NIC física do host (que conecta o servidor à rede física).

A desativação efetiva para a VM acontece quando o MTU da interface da própria VM está em 1500. Ajustes no host são úteis para manter consistência e prevenir gargalos, mas não substituem a configuração do convidado.

Soluções apresentadas

Abaixo estão duas abordagens complementares. A primeira, dentro da VM, é a mais direta para o cenário “Windows Server 2016 em VM”. A segunda ajuda a manter o ambiente coerente no host Hyper‑V.

Dentro da VM Windows Server 2016 (recomendado)

Etapa	Comando / ação	Explicação
1. Identificar o adaptador	`Get-NetAdapter \| ft Name, InterfaceDescription, Status, LinkSpeed`	Confirme o nome exato da interface (ex.: `Ethernet` ou outro). Use esse nome nos próximos comandos.
2. Definir MTU padrão (desligar Jumbo)	$nic = "Ethernet" Opção A: ajustar a propriedade avançada "Jumbo Packet" para 1500 Set-NetAdapterAdvancedProperty -Name $nic -RegistryKeyword "JumboPacket" -RegistryValue 1500 Opção B (quando o driver só aceita valores "em bytes Ethernet", ex.: 1514) Set-NetAdapterAdvancedProperty -Name $nic -RegistryKeyword "JumboPacket" -RegistryValue 1514 Opcional: reforçar MTU na pilha IP (IPv4 e IPv6) netsh interface ipv4 set subinterface "$nic" mtu=1500 store=persistent netsh interface ipv6 set subinterface "$nic" mtu=1500 store=persistent	Voltar o MTU para 1500 bytes equivale a “Disabled” para Jumbo Frames. Alguns drivers usam 1514 por contarem o cabeçalho Ethernet; ambos indicam quadro padrão.
3. Validar a alteração	`# Verificar a propriedade avançada "Jumbo Packet" Get-NetAdapterAdvancedProperty -Name $nic \| ? { $_.DisplayName -match "Jumbo" } Conferir MTU em subinterfaces netsh interface ipv4 show subinterfaces netsh interface ipv6 show subinterfaces Teste prático de fragmentação (IPv4): 1472 é o maior payload comum para MTU 1500 (1500 - 20 [IPv4] - 8 [ICMP] = 1472) ping -f -l 1472`	Confirme que “Jumbo Packet” voltou ao valor padrão e que o ping sem fragmentar (-f) funciona com carga 1472.

No host Hyper‑V (coerência de ambiente)

Etapa	Comando / ação	Explicação
1. Identificar o vSwitch	`Get-VMSwitch`	Liste os virtual switches e anote o nome exato (ex.: `vSwitch-LAN`).
2. Voltar o MTU do vNIC do host	`$vsw = "NOMEDOSWITCH" $hostVnic = "vEthernet ($vsw)" Get-NetAdapterAdvancedProperty -Name $hostVnic \| ? { $_.DisplayName -match "Jumbo" } Set-NetAdapterAdvancedProperty -Name $hostVnic -RegistryKeyword "*JumboPacket" -RegistryValue 1500`	Ajusta o vNIC do próprio host vinculado ao vSwitch para o tamanho padrão. Isso evita discrepâncias no tráfego de/para o host.
3. Validar a alteração	`Get-NetAdapterAdvancedProperty -Name $hostVnic -DisplayName "Jumbo Packet"`	Confirma que o valor foi aplicado ao vNIC do host.

Importante

O vSwitch não “replica” automaticamente a propriedade Jumbo Packet para os vNICs das VMs. Cada VM tem sua própria pilha e precisa ser configurada individualmente.
Se a NIC física do host estiver com Jumbo habilitado e o restante da rede não estiver coerente, podem ocorrer problemas. Mantenha a coerência ponta a ponta.

Por que “Disabled” não aparece na interface

Em muitos drivers, a propriedade “Jumbo Packet” apresenta apenas valores numéricos. O valor mais baixo — 1500 (ou 1514) — corresponde ao padrão Ethernet e, portanto, a Jumbo Frames desativado. Essa escolha de design força a configuração explícita do tamanho em bytes, evitando ambiguidade entre “desligado” e “ligado com valor X”.

Validações práticas e testes de caminho

Verificar o que o driver aceita

$nic = "Ethernet"
Get-NetAdapterAdvancedProperty -Name $nic -RegistryKeyword "*JumboPacket" | 
  Select-Object Name, DisplayName, DisplayValue, RegistryValue

Se precisar descobrir os valores de exibição aceitos, confira:

# Nem todos os drivers expõem esta propriedade, porém quando exposta é útil:
(Get-NetAdapterAdvancedProperty -Name $nic -RegistryKeyword "*JumboPacket").ValidDisplayValues

Ping sem fragmentação

Para MTU 1500 em IPv4, o maior buffer no ping sem fragmentar é 1472 bytes (1500 − 20 cabeçalho IP − 8 ICMP):

ping <ip-alvo> -f -l 1472
Se retornar "Packet needs to be fragmented", há um trecho no caminho abaixo de 1500.

Para redes que usam 9000 (Jumbo), o teste usual seria 8972 (9000 − 20 − 8), mas como a meta aqui é desligar Jumbo, foque em 1472.

Boas práticas de implementação

Documente o padrão: em ambientes mistos, defina 1500 como baseline. Habilite Jumbo apenas nos segmentos e cargas que comprovadamente se beneficiam.
Considere overlays: VXLAN, GRE, IPsec e outros túneis consomem overhead extra. Muitas vezes 1500 já evita fragmentação dentro do túnel.
Cuide do empilhamento: se o host estiver com Jumbo e a VM com 1500 (ou vice‑versa), podem surgir drops intermitentes em fluxos específicos (por exemplo, SMB large I/O).
Reinício do adaptador: alguns drivers aplicam o novo valor sem down/up, outros exigem reativação; se necessário, use Disable-NetAdapter e Enable-NetAdapter com cautela (via console).

Exemplos prontos para copiar

Voltar tudo para 1500 dentro da VM

$nic = "Ethernet"

1) Desligar Jumbo na propriedade avançada

Set-NetAdapterAdvancedProperty -Name $nic -RegistryKeyword "*JumboPacket" -RegistryValue 1500

2) Ajustar a pilha IPv4/IPv6

netsh interface ipv4 set subinterface "$nic" mtu=1500 store=persistent
netsh interface ipv6 set subinterface "$nic" mtu=1500 store=persistent

3) Verificações

Get-NetAdapterAdvancedProperty -Name $nic | ? { $_.DisplayName -match "Jumbo" }
netsh interface ipv4 show subinterfaces
netsh interface ipv6 show subinterfaces
ping  -f -l 1472

Aplicar no vNIC do host associado ao vSwitch

$vsw = "NOMEDOSWITCH"
$hostVnic = "vEthernet ($vsw)"
Set-NetAdapterAdvancedProperty -Name $hostVnic -RegistryKeyword "*JumboPacket" -RegistryValue 1500
Get-NetAdapterAdvancedProperty -Name $hostVnic -DisplayName "Jumbo Packet"

Erros comuns e como evitar

Sintoma	Causa provável	Correção
Transferências SMB lentas entre duas VMs	Uma VM usa 9000 e a outra 1500; o caminho físico não suporta 9000	Padronize ambas em 1500; valide com `ping -f -l 1472`
Driver não mostra “Jumbo Packet”	Interface sintética sem suporte exposto ou driver legado	Use `netsh` para forçar MTU 1500 na pilha IP
Sem parâmetro em cmdlet do vSwitch	Tentativa de ajustar Jumbo pelo `Set-VMSwitch`	A propriedade é do adaptador, não do vSwitch. Use `Set-NetAdapterAdvancedProperty`
Quedas ao acessar recursos do host	vNIC do host em Jumbo e VMs/infra em 1500	Volte o `vEthernet (Switch)` para 1500 também

Perguntas frequentes

É obrigatório mexer no host Hyper‑V?

Para desativar Jumbo na VM, basta configurar a própria VM. Ainda assim, manter o vNIC do host coerente com 1500 evita discrepâncias em tráfego que passa pelo host.

Preciso mudar a NIC física?

Se a NIC física do host estiver com Jumbo habilitado e a rede física não for end‑to‑end 9000, volte para 1500 para prevenir fragmentação.

E se eu usar outro hipervisor?

O princípio é o mesmo: volte o MTU para 1500 dentro da VM. Em VMware/Proxmox/KVM, as opções de Jumbo no nível do vSwitch/PortGroup também não “forçam” a VM; a configuração do convidado é quem determina o que ele envia.

Observações úteis e complementares

Sem entrada “Disabled” — Em adaptadores virtuais, os drivers geralmente expõem apenas valores numéricos. 1500 (ou 1514) corresponde a “desativado” para Jumbo.
Onde aplicar primeiro? — Priorize a VM. Ajustes no host são desejáveis para consistência, porém não substituem a configuração do convidado.
Alternativa por VM (linha de comando clássica) — Além de Set‑NetAdapterAdvancedProperty, use: netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent netsh interface ipv6 set subinterface "Ethernet" mtu=1500 store=persistent
Impacto — Desligar Jumbo Frames remove a otimização para cargas muito grandes, mas melhora a compatibilidade onde o caminho não é 100% 9000, evitando fragmentação e perdas.

Checklist final de validação

Na VM, “Jumbo Packet” voltou a 1500/1514 e o netsh mostra MTU 1500 para IPv4/IPv6.
ping -f -l 1472 funciona para o gateway e para destinos relevantes.
No host Hyper‑V, o vEthernet (NOMEDOSWITCH) também está em 1500 se houver tráfego direto do host para a rede das VMs.
Se aplicável, NIC física do host alinhada com 1500.

Conclusão

Para VMs Windows Server 2016, desativar Jumbo Frames é, essencialmente, restaurar o MTU para 1500 diretamente no adaptador da VM. Essa prática substitui a ausência da opção textual “Disabled” na interface gráfica e elimina os efeitos colaterais de uma malha que não suporta 9000 ponta a ponta. Ajustes no host Hyper‑V (vNIC e, quando necessário, NIC física) completam a coerência do ambiente, mas o sucesso da mudança depende primeiro da configuração no convidado.