WSL2 on kenji.blog

Hyper-V vs WSL2: Comparação de tecnologias de virtualização no Windows

Sun, 13 Sep 2026 07:00:00 +0900

1. Introdução: A evolução da virtualização no Windows

A tecnologia de virtualização na plataforma Windows passou por uma evolução dramática nas últimas décadas. No passado, hipervisores Type 2 de terceiros (como VMware Workstation e VirtualBox) eram a norma, mas desde que a Microsoft introduziu o “Hyper-V” no Windows Server 2008, hipervisores Type 1 também foram incorporados em SOs desktop como o Windows 10/11.

E nos últimos anos, o que mais tem chamado a atenção dos desenvolvedores é o “WSL2 (Windows Subsystem for Linux 2)”. Enquanto o WSL1 dependia da conversão de chamadas de sistema (tradução), o WSL2 adota uma “Lightweight Utility VM” (Máquina Virtual Utilitária Leve) que aplica a tecnologia do Hyper-V, alcançando total compatibilidade com o Linux e uma melhoria dramática de desempenho.

Neste artigo, vamos comparar e explicar minuciosamente essas duas poderosas tecnologias de virtualização — o “Hyper-V” completo e o “WSL2” focado na experiência do desenvolvedor — abordando suas arquiteturas, desempenho (CPU, memória, E/S de disco), configuração de rede e os melhores casos de uso, juntamente com profundos detalhes técnicos.

2. Teoria básica dos hipervisores e comparação de arquiteturas

Ao entender a tecnologia de virtualização, classificar os tipos de hipervisores (Monitores de Máquina Virtual: VMM) é essencial.

2.1. Diferenças entre hipervisores Type 1 e Type 2

Um hipervisor é uma camada de software que abstrai o acesso ao hardware e permite que vários sistemas operacionais (SOs convidados) sejam executados simultaneamente em uma única máquina física.

Type 1 (Bare-metal): Executado diretamente no hardware. Não existe o conceito de um SO host (embora, estritamente falando, possa existir um SO de gerenciamento com privilégios). Tem sobrecarga extremamente baixa e oferece alto desempenho e segurança. Exemplos: Hyper-V, VMware ESXi, Xen.
Type 2 (Hospedado): Executado como um aplicativo no SO host (como Windows ou macOS). Como todo o acesso ao hardware passa pelo SO host, a sobrecarga é maior. Exemplos: VMware Workstation, Oracle VirtualBox.

O Hyper-V do Windows é um puro hipervisor Type 1. Quando o Hyper-V é ativado, na verdade, o próprio SO Windows que o usuário opera normalmente passa a ser executado dentro de uma máquina virtual especial chamada “Partição Raiz (Root Partition)”.

2.2. Detalhes da arquitetura do Hyper-V

A arquitetura do Hyper-V adota um design de microkernel e baseia-se em unidades de separação lógicas chamadas Partiçõoes (Partitions).

graph TD
A["Hardware (CPU, RAM, Disco, NIC)"] --> B["Hipervisor do Windows (Ring -1)"]
B --> C["Partição Raiz (SO Windows)"]
B --> D["Partição Filha 1 (VM Windows)"]
B --> E["Partição Filha 2 (VM Linux)"]
C --> F["VMBus (Barramento de Máquina Virtual)"]
D --> F
E --> F
C --> G["VID (Driver de Infraestrutura de Virtualização)"]
C --> H["VMWP.exe (Processo de Trabalho)"]

Hipervisor do Windows (Windows Hypervisor): Opera no estado de nível de privilégio mais alto da CPU (Ring -1 ou VMX Root Mode) e é responsável apenas pela alocação de memória e escalonamento da CPU. Não inclui drivers de dispositivo.
Partição Raiz (Root Partition): A partição onde o SO Windows host é executado. Ela possui todos os drivers de dispositivo e controla o hardware diretamente. Também fornece funções de gerenciamento para as partições filhas (como provedores WMI e VMWP.exe).
Partição Filha (Child Partition): A partição onde o SO convidado é executado. O acesso direto ao hardware não é permitido e as solicitações de E/S são enviadas à partição raiz (I/O Sintético) por meio de um barramento de compartilhamento de memória lógico chamado “VMBus”.

2.3. O mecanismo do WSL2 e da Lightweight Utility VM

O WSL2 utiliza a mesma tecnologia base de hipervisor Type 1 que o Hyper-V, mas utiliza um subconjunto de recursos chamado “Plataforma de Máquina Virtual (Virtual Machine Platform: VMP)”, que é diferente de uma máquina virtual Hyper-V completa.

A “Lightweight Utility VM” (Máquina Virtual Utilitária Leve) adotada no WSL2 elimina completamente a emulação de hardware legado (como BIOS virtual ou placa-mãe virtual) encontrada em VMs tradicionais.

graph TD
A["SO Host Windows (Espaço do Usuário)"]
B["Sistema de Arquivos NTFS"]
C["Servidor de Protocolo 9P (Plan 9)"]
D["Lightweight Utility VM (Kernel Linux)"]
E["ext4.vhdx (Disco Virtual)"]
F["Espaço do Usuário Linux (Distribuições WSL2)"]
A --> C
C -->| Compartilhamento de Arquivos Cross-OS | D
D --> E
D --> F

A maior característica do WSL2 é a velocidade de inicialização e a integração perfeita com o SO host. O kernel do Linux é inicializado em menos de alguns segundos e o sistema de arquivos do lado do Windows (NTFS) é acessado por meio do protocolo de sistema de arquivos de rede 9P do Plan 9.

3. Análise detalhada de desempenho: Recursos computacionais e E/S

O desempenho da máquina virtual é expresso como a soma das sobrecargas em cada componente de CPU, memória e E/S de disco.

3.1. Sobrecarga de CPU e troca de contexto

Tanto o Hyper-V quanto o WSL2 usam virtualização assistida por hardware (Intel VT-x / AMD-V). As instruções da CPU são executadas basicamente na velocidade nativa, mas ao executar instruções privilegiadas ou processar E/S, ocorre uma interrupção chamada “VM Exit”, realizando uma troca de contexto para o hipervisor.

A sobrecarga de CPU neste momento, $T_{overhead}$, pode ser expressa pelo seguinte modelo matemático:

$$ T_{overhead} = \sum_{i=1}^{N} (t_{vm\_exit} + t_{hypercall\_process} + t_{vm\_entry}) $$

Onde:

$N$: Número de ocorrências de VM Exit por unidade de tempo
$t_{vm\_exit}$: Tempo de transição do convidado para o hipervisor
$t_{hypercall\_process}$: Tempo de processamento de E/S ou interrupções via VMBus
$t_{vm\_entry}$: Tempo de retorno do hipervisor para o convidado

Como o WSL2 não possui emulação de legado, $t_{hypercall\_process}$ é otimizado para ser extremamente pequeno. Portanto, em operações de CPU puras (como compilação de kernel ou inferência de modelos de aprendizado de máquina), a degradação de desempenho fica dentro de alguns por cento em comparação com um ambiente bare-metal.

3.2. Mecanismos de alocação de memória

Existem diferenças claras nas filosofias de design entre os dois na abordagem de gerenciamento de memória.

Hyper-V (Memória Dinâmica): A partição raiz aloca e recupera dinamicamente a memória de acordo com a demanda de memória da VM convidada. No entanto, a memória reservada como cache de página dentro do SO convidado tende a não ser liberada a menos que o sistema esteja sob pressão.
WSL2 (Recuperação dinâmica de memória): O WSL2 tem seu próprio mecanismo e retorna periodicamente (Reclaim) a memória que não é mais necessária na VM Linux (incluindo o cache) para o host Windows. Nos primórdios do WSL2, havia o problema do cache de páginas do Linux consumir a memória do Windows (inchaço do processo Vmmem), mas isso foi melhorado agora com patches de kernel.

3.3. Características de E/S de disco (VHDX vs ext4.vhdx)

A E/S de disco é o gargalo mais provável no desempenho de uma máquina virtual.

A latência de E/S, $L_{total}$, é calculada da seguinte forma:

$$ L_{total} = L_{guest\_fs} + L_{vmbus} + L_{host\_fs} + L_{physical\_disk} $$

No caso do Hyper-V: Convidados gerais do Hyper-V usam discos virtuais no formato VHDX. As solicitações de E/S emitidas pelo sistema de arquivos (ext4 ou NTFS) dentro do SO convidado passam pelo driver de armazenamento de dispositivo de bloco (storvsc) do VMBus e são processadas como acessos ao arquivo VHDX no NTFS do lado do Windows.

No caso do WSL2: As distribuições Linux no WSL2 operam em um sistema de arquivos ext4 nativo construído dentro de um arquivo ext4.vhdx dedicado. Operações de arquivo dentro do Linux (como dentro do diretório ~) apresentam desempenho nativo equivalente ao do Hyper-V acima. No entanto, o processo é muito diferente quando o Linux no WSL2 acessa arquivos no lado do Windows (como /mnt/c/), ou vice-versa. Para esse acesso cross-OS, o 9P (Plan 9 File System Protocol) é usado.

$$ L_{cross\_os} = L_{9p\_client} + L_{socket\_transfer} + L_{9p\_server} + L_{ntfs} $$

O acesso através deste protocolo 9P possui uma grande sobrecarga de processamento de serialização e, para o propósito de ler e escrever um grande número de arquivos pequenos (por exemplo: um npm install ou operações do Git em um projeto Node.js localizado em um diretório no lado do Windows), o desempenho diminui significativamente (às vezes mais de 10 vezes mais lento). Portanto, ao usar o WSL2, é uma regra de ouro sempre colocar os arquivos de projeto no sistema de arquivos nativo do Linux (sob ~/).

4. Estrutura de rede: NAT, Default Switch e Bridged

A flexibilidade de rede é uma das maiores diferenças entre o Hyper-V e o WSL2.

4.1. Rede do WSL2 (Baseada em NAT)

Por padrão, a rede do WSL2 usa uma configuração “NAT (Network Address Translation)” usando a tecnologia de comutador virtual (Virtual Switch) do Hyper-V. A VM Linux recebe automaticamente um endereço IP privado diferente do host Windows (por exemplo: 172.20.x.x). Está integrado um mecanismo onde o host Windows usa localhost para encaminhar para serviços (portas) iniciados no WSL2, permitindo que os desenvolvedores testem servidores web e outros sem precisar estar cientes da rede.

Recentemente, um novo modo de rede chamado “Mirrored mode” (Modo espelhado) foi introduzido em versões de visualização do WSL2. Isso visa melhorar o suporte IPv6 e a compatibilidade com conexões VPN (pode ser configurado em .wslconfig).

4.2. Comutador Virtual do Hyper-V (Virtual Switch)

O Hyper-V permite a construção de redes avançadas de nível corporativo. Através do “Gerenciador de Comutador Virtual”, ele fornece principalmente 3 modos.

Externo (External): Vincula a NIC física da máquina host ao comutador virtual e permite que as VMs convidadas participem diretamente da rede física (conexão em ponte). A VM obtém um IP da mesma sub-rede da rede física através de um servidor DHCP.
Interno (Internal): Permite a comunicação apenas entre o SO host e a VM, e entre as VMs. Não pode acessar diretamente redes externas.
Privado (Private): Permite a comunicação apenas entre as VMs e bloqueia a comunicação com o SO host. Usado para construir ambientes de teste isolados.

4.3. Construção avançada de rede Hyper-V com PowerShell

Em ambientes de desenvolvimento ou teste, quando você deseja construir uma rede NAT personalizada para VMs, o PowerShell permite um controle detalhado. Abaixo está um exemplo de script que cria um comutador virtual interno, configura NAT nele e fornece acesso à internet para as VMs.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. Criação do comutador virtual interno
$SwitchName = "HyperV-NatSwitch"
New-VMSwitch -SwitchName $SwitchName -SwitchType Internal

# 2. Definir endereço IP na NIC virtual do host (IP que servirá como gateway)
$GatewayIP = "192.168.100.1"
$NetPrefix = 24
$InterfaceAlias = "vEthernet ($SwitchName)"
New-NetIPAddress -IPAddress $GatewayIP -PrefixLength $NetPrefix -InterfaceAlias $InterfaceAlias

# 3. Configuração da rede NAT
$NatName = "HyperV-NatNetwork"
$NatSubnet = "192.168.100.0/24"
New-NetNat -Name $NatName -InternalIPInterfaceAddressPrefix $NatSubnet

# Comando para verificação
Get-NetNat

Com esta configuração, ao definir manualmente um IP de 192.168.100.x e o gateway 192.168.100.1 no convidado Hyper-V especificado, você pode construir um segmento NAT próprio capaz de se comunicar externamente através do host.

5. Casos de uso e guia prático de seleção

Com base nas diferenças em arquitetura e desempenho discutidas até o momento, vamos definir em quais situações qual tecnologia deve ser adotada.

5.1. Cenários onde o WSL2 deve ser selecionado

O WSL2 foi projetado especificamente para “melhorar a produtividade do desenvolvedor”. É ideal para os seguintes usos:

Desenvolvimento Web e nativo de nuvem: Desenvolvimento de contêineres usando Docker Desktop (backend WSL2) ou Podman.
Uso de ferramentas exclusivas do Linux: Ao usar diariamente bash, grep, awk, sed ou compiladores GCC ou Clang para Linux.
Aplicativos com GUI (WSLg): Quando se deseja executar aplicativos Linux X11/Wayland nativamente na área de trabalho do Windows sem problemas.
Aprendizado de Máquina e Desenvolvimento de IA: Treinamento rápido de TensorFlow ou PyTorch usando a função de repasse de GPU (NVIDIA CUDA on WSL).

Nota: Você pode encontrar limitações se quiser personalizar o kernel em detalhes ou construir serviços complexos que dependem fortemente do systemd (o systemd agora é suportado, mas desabilitado ou restrito por padrão).

5.2. Cenários onde o Hyper-V deve ser selecionado

O Hyper-V visa “virtualização e isolamento completo da infraestrutura”. Ele se torna indispensável para os seguintes casos de uso:

Execução de VMs Windows: Para executar diferentes versões do Windows (Windows Server, Windows 10 mais antigo, etc.) como um ambiente de teste.
Virtualização aninhada (Nested Virtualization): Quando se deseja executar ainda mais máquinas virtuais (Hyper-V ou KVM) dentro de uma máquina virtual. É essencial para ambientes de verificação de engenheiros de infraestrutura.
Requisitos avançados de rede: Quando se precisa controlar rigorosamente as configurações de rede, como conexões de ponte externa (participação na mesma LAN), marcação de VLAN ou alocação de várias NICs.
Instantâneos (Snapshots/Checkpoints): A capacidade de salvar o estado de uma VM em um momento específico e reverter instantaneamente a qualquer momento. Extremamente útil para testes destrutivos de software ou análise de malware.
Alocação de recursos fixos: Quando se deseja fixar rigorosamente o número de núcleos de CPU e a quantidade de memória para minimizar o impacto no SO host.

6. Considerações sobre a taxa de transferência (throughput) de E/S por meio de modelos matemáticos (Apêndice)

Como um engenheiro de sistemas, ao avaliar os limites de desempenho de E/S de ambos, é importante entender teoricamente a relação entre a taxa de transferência $S$ e o tamanho do bloco $B$.

A taxa de transferência de transferência de dados $S$ é a quantidade de transferência de dados por unidade de tempo, e é modelada da seguinte forma:

$$ S(B) = \frac{B}{L_{setup} + \frac{B}{R_{max}}} $$

$B$: Tamanho do bloco (Bytes)
$L_{setup}$: Latência fixa associada à configuração de solicitações de E/S e à troca de contexto
$R_{max}$: A largura de banda máxima do hardware na cópia ou transferência de dispositivo

No acesso a arquivos por meio do protocolo 9P do WSL2, este $L_{setup}$ é muito grande (devido à comunicação de soquete e à serialização/desserialização do protocolo). Portanto, quando o tamanho do bloco $B$ é pequeno (como leitura e gravação em massa de arquivos pequenos de cerca de alguns KB), a influência do $L_{setup}$ no denominador se torna dominante, e a taxa de transferência $S$ diminui drasticamente. Por outro lado, em acessos VHDX via VMBus do Hyper-V, como o $L_{setup}$ é otimizado para um nível próximo a interrupções de hardware, operações altas de IOPS podem ser mantidas mesmo com blocos de pequeno tamanho.

Esta realidade matemática é o fundamento lógico por trás da melhor prática de que “você não deve colocar arquivos de projeto no lado do Windows no WSL2”.

7. Conclusão: Duas tecnologias de virtualização que coexistem

O Hyper-V e o WSL2 não se tratam de um ser superior ao outro; eles são “duas soluções com propósitos diferentes”.

O WSL2 é a “melhor ferramenta de integração” para romper a casca do SO Windows e entregar o ecossistema Linux aos usuários do Windows de forma contínua e rápida. Não é exagero dizer que é o melhor ambiente CLI para desenvolvedores.
O Hyper-V é um “hipervisor completo” que traz o robusto isolamento e capacidade de gerenciamento cultivados em data centers corporativos para o desktop. Não tem rival na construção de redes, no teste de SOs Windows e na simulação de ambientes de infraestrutura.

Nos ambientes Windows modernos, essas duas tecnologias não competem uniformemente, mas coexistem lindamente na mesma plataforma de VM. Ao usá-las nos lugares certos, dependendo da finalidade, o Windows será indiscutivelmente a estação de trabalho de engenharia mais poderosa e flexível do mundo.

Guia de Configuração Definitivo do Ambiente de Desenvolvimento para WSL2 (Windows Subsystem for Linux)

Sat, 12 Sep 2026 23:00:00 +0900

O “WSL2 (Windows Subsystem for Linux 2)”, que fornece um ambiente de desenvolvimento nativo do Linux no Windows, tornou-se uma ferramenta indispensável no desenvolvimento de software moderno. No entanto, há uma diferença imensa em desempenho e experiência de desenvolvimento entre usá-lo em seu estado padrão e ajustá-lo adequadamente após entender sua arquitetura.

Neste artigo, explicaremos detalhadamente todo o processo para construir o “ambiente de desenvolvimento definitivo” exigido por engenheiros profissionais. Começando com uma explicação da arquitetura fundamental do WSL2, abordaremos configurações para maximizar o desempenho, a construção de um ambiente de terminal confortável, a integração perfeita com Docker e VS Code, e configurações avançadas de rede.

1. A Arquitetura do WSL2 e a Evolução a partir do WSL1

Para extrair totalmente o potencial do WSL2, é importante primeiro entender sua estrutura interna. O WSL original (WSL1) e o WSL2 têm abordagens fundamentalmente diferentes para executar binários do Linux no Windows.

WSL1: Camada de Tradução de Chamadas de Sistema

O WSL1 adotava um mecanismo que traduzia chamadas de sistema do Linux para a API NT do Windows em tempo real. Isso tinha a vantagem de uma sobrecarga de recursos muito baixa, já que não usava uma máquina virtual (VM). No entanto, era difícil emular perfeitamente chamadas de sistema complexas, como operações de E/S do sistema de arquivos, resultando em uma degradação de desempenho terrível ao lidar com um grande número de arquivos pequenos, como npm install do Node.js ou operações de repositório do Git.

WSL2: VM Utilitária Leve e Kernel Linux Completo

No WSL2, a arquitetura foi renovada, e um kernel Linux real construído pela Microsoft agora roda diretamente em uma “VM utilitária leve” que utiliza um subconjunto da arquitetura Hyper-V. Isso garante 100% de compatibilidade de chamadas de sistema, e o uso de um disco virtual (VHDX) com o sistema de arquivos ext4 nativo do Linux melhorou drasticamente o desempenho de E/S de arquivos em comparação com o WSL1.

O diagrama Mermaid a seguir mostra as diferenças estruturais entre o WSL1 e o WSL2.

flowchart TD
subgraph "Ambiente do SO Windows"
A["Kernel Windows NT"]
A --> F["Sistema de Arquivos NTFS (Unidade C:)"]
end
subgraph "Arquitetura do WSL2"
B["Hypervisor Hyper-V"]
B --> C["VM Utilitária Leve"]
C --> D["Kernel Linux (Microsoft)"]
D --> E["Espaço de Usuário Ubuntu (glibc, bash, etc.)"]
D --> G["Disco Virtual ext4 (.vhdx)"]
end
A -.->|"Compartilhamento de Arquivos de Rede via Protocolo Plan 9 (9P)"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

A lição importante a ser tirada dessa estrutura é que “o acesso aos arquivos no lado do Linux (dentro do VHDX) é extremamente rápido, mas o acesso aos arquivos no lado do Windows (/mnt/c/) é muito lento porque passa pelo protocolo 9P”. O código-fonte do projeto deve ser sempre colocado no diretório inicial (~) do lado do WSL.

2. Análise Matemática do Desempenho: Por que o WSL2 é rápido?

Vamos avaliar quantitativamente a melhoria de desempenho do WSL2 usando um modelo matemático. Uma das operações mais demoradas no desenvolvimento de software é o processamento que envolve E/S de um grande número de arquivos (por exemplo, instalação de bibliotecas e compilação).

O tempo total de execução $T_{total}$ de um determinado processo é expresso como a soma do tempo de computação pela CPU $T_{compute}$ e o tempo de E/S de disco $T_{io}$.

$$ T_{total} = T_{compute} + T_{io} $$

No caso do WSL1, ocorre uma sobrecarga ao converter as operações do lado do Linux em operações NTFS, então o tempo de E/S é modelado da seguinte forma. Aqui, $n$ é o número de operações de arquivo, $t_{ntfs\_syscall}$ é o tempo de execução da chamada de sistema do lado do Windows, e $t_{trans}$ é a sobrecarga da camada de tradução.

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

Por outro lado, no caso do WSL2, o kernel emite E/S diretamente para o sistema de arquivos ext4, então a sobrecarga é apenas um pequeno atraso $t_{virt}$ devido à virtualização.

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

Em sistemas de arquivos comuns, como $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$, quando $n$ é muito grande (dezenas a centenas de milhares de operações de arquivo), a diferença no tempo de E/S entre o WSL1 e o WSL2 aumenta exponencialmente.

Além disso, assumindo que a taxa de sobrecarga do cálculo da CPU em um ambiente virtualizado seja $\rho$, na virtualização mais recente assistida por hardware (Intel VT-x / AMD-V), ela fica em torno de $\rho \approx 0.01 \sim 0.03$ (1 a 3%). Portanto, mesmo em tarefas puramente computacionais, ele oferece $97\% \sim 99\%$ de desempenho comparável ao de um ambiente Linux nativo.

3. Instalação e Construção da Base

No Windows 10/11, a instalação do WSL2 tornou-se muito simples. Basta abrir o PowerShell com privilégios de administrador e executar o seguinte comando:

1
2
3
4
5
6


# WSL2 e Ubuntu são instalados por padrão
wsl --install

# Ao especificar uma distribuição específica
# Pode ser verificado com wsl --list --online
wsl --install -d Ubuntu-24.04

Após a instalação e reinicialização, você será solicitado a configurar um nome de usuário UNIX e senha na primeira inicialização. Esse usuário é independente do usuário do Windows e é válido apenas dentro do WSL.

Se você já estiver usando o WSL1, poderá convertê-lo para o WSL2 com os seguintes comandos:

1
2
3
4
5


# Converter uma distribuição existente para WSL2
wsl --set-version Ubuntu 2

# Definir o WSL2 como padrão para distribuições adicionadas no futuro
wsl --set-default-version 2

4. Os Segredos do Controle de Recursos: .wslconfig e wsl.conf

Uma das maiores armadilhas do WSL2 é o “consumo ilimitado de memória (inchaço do processo Vmmem)”. Como o WSL2 usa o cache de página do kernel Linux, ele consome infinitamente a memória do host (Windows) a cada E/S. Para evitar isso, é essencial limitar os recursos por meio de arquivos de configuração.

Os arquivos de configuração do WSL2 são divididos em dois: .wslconfig que afeta todo o Windows e wsl.conf que afeta o interior de cada distribuição.

4.1. .wslconfig (Lado do Windows)

Crie um arquivo no diretório de perfil de usuário do Windows (C:\Users\<NomeDoUsuario>\.wslconfig) para controlar a alocação de recursos para a VM.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<NomeDoUsuario>\.wslconfig
[wsl2]
# Quantidade máxima de memória alocada à VM. Recomenda-se cerca de 50% a 75% da memória total do host
memory=16GB

# Número de núcleos de CPU a serem usados (usa todos os núcleos se omitido)
processors=8

# Tamanho do arquivo de swap
swap=8GB

# Destino de salvamento do arquivo de swap (se desejar economizar espaço na unidade C)
# swapfile=D:\\wsl\\swap.vhdx

# Habilitar o encaminhamento do localhost (para acessar o WSL do lado do Windows através do localhost)
localhostForwarding=true

# Liberar memória automaticamente (Apenas Windows 11)
# Libera dinamicamente o cache de página para evitar o inchaço do Vmmem
autoMemoryReclaim=dropcache

[experimental]
# Recursos avançados de rede disponíveis no Windows 11 22H2 e posteriores
# Isso permite suporte a IPv6 e compartilhamento do mesmo endereço IP entre o WSL e o Windows
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (Lado do Linux)

Edite /etc/wsl.conf dentro do WSL para controlar o comportamento específico da distribuição.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (Editado dentro do WSL)
[network]
# Desativa a geração automática de /etc/resolv.conf na inicialização do WSL
# Útil se você deseja definir um DNS personalizado (por exemplo, 8.8.8.8)
generateResolvConf=false

# Define um nome de host personalizado
hostname=WSL-DevNode

[automount]
# Configurações de montagem para unidades do Windows
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# Muda o ponto de montagem da unidade C de /mnt/c para /c (encurta o caminho)
root=/

[boot]
# Ativa o systemd (WSL 0.67.6 e posteriores)
# Isso permite que snap e vários daemons (como o Docker) sejam executados nativamente
systemd=true

[user]
# Usuário de login padrão
default=kenji

Para aplicar essas configurações, você deve executar wsl --shutdown no PowerShell para parar completamente a VM do WSL antes de reiniciar.

5. O Ambiente de Terminal Definitivo: Zsh + Powerlevel10k

A produtividade não aumentará se você mantiver o bash padrão. Combinaremos o Zsh, que se orgulha de funções poderosas de autocompletar e visibilidade, com o tema ultrarrápido “Powerlevel10k” para construir o prompt mais forte.

5.1. Introdução e Configuração do Windows Terminal

Instale o “Windows Terminal” a partir da Microsoft Store. Abra as configurações JSON (settings.json), defina o perfil padrão para o WSL (Ubuntu) e altere a fonte para uma Nerd Font focada em desenvolvimento (por exemplo, HackGen Console NF ou MesloLGS NF).

5.2. Instalação do Zsh e Oh My Zsh

Execute os seguintes comandos no terminal do WSL:

1
2
3
4
5
6


# Atualização de pacotes e instalação do Zsh
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# Executa o script de instalação do Oh My Zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. Introdução ao Powerlevel10k e Plugins

Introduziremos plugins (realce de sintaxe e autocompletar) e o tema Powerlevel10k que aprimoram ainda mais o Zsh.

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Edite ~/.zshrc para ativar o tema e os plugins.

1
2
3
4
5


# Alterações em ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"

# Adicionar ao array de plugins
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

Ao salvar e executar source ~/.zshrc, o assistente de configuração do Powerlevel10k (p10k configure) será iniciado. Siga as instruções na tela para personalizar o prompt ao seu gosto (estilo do prompt, presença de ícones, informações a serem exibidas, etc.). O nome e o status do branch do Git, a versão do Node.js, o tempo de execução do comando, entre outros, serão exibidos em tempo real, melhorando drasticamente a eficiência do desenvolvimento.

6. VS Code Remote - Integração Perfeita com o WSL

No desenvolvimento com o WSL2, a extensão “Remote - WSL” é o mecanismo que permite o acesso perfeito aos arquivos dentro do WSL a partir do IDE (Visual Studio Code) instalado no lado do Windows.

Explicação da Arquitetura

O diagrama de sequência a seguir mostra como o VS Code se comunica com o WSL2.

sequenceDiagram
autonumber
participant U as "Desenvolvedor"
participant V as "IU do VS Code (Windows)"
participant S as "Servidor VS Code (WSL2)"
participant F as "Sistema de Arquivos ext4 (WSL2)"
U->>V: "Digitar `code .` no Terminal WSL"
V->>S: "Estabelecer Conexão RPC via Vsock"
Note over V,S: Comunica-se por soquetes Hyper-V sem usar TCP/IP
S->>F: "Ler Arquivos de Origem / Executar Linter"
F-->>S: "Retornar Dados e Análise"
S-->>V: "Transmitir resultados do Servidor de Idioma para a IU"
V-->>U: "Exibir realce de sintaxe e erros"

O VS Code no lado do Windows funciona como um mero “cliente fino (IU)”, e todos os processos pesados como Servidor de Linguagem (Language Server), depurador e execução no terminal são tratados pelo “VS Code Server” no lado do WSL. Isso permite que você mantenha seu ambiente limpo usando apenas o lado do WSL, sem ter que instalar o Node.js ou Python no lado do Windows.

Configurações Essenciais do VS Code

Instale a extensão “WSL” (ms-vscode-remote.remote-wsl) a partir de “Extensões” no VS Code. Em seguida, navegue até o diretório do seu projeto no terminal do WSL e simplesmente execute code . para iniciar o VS Code no lado do Windows com esse diretório aberto.

Nota importante (Problema com o código de quebra de linha): Windows e Linux usam códigos de quebra de linha diferentes (Windows usa CRLF, Linux usa LF). Ao desenvolver no WSL, certifique-se de unificar a configuração core.autocrlf do Git e as configurações padrão de arquivos do VS Code para LF. Se não fizer isso, você poderá sofrer com erros misteriosos ao executar scripts de shell ou contêineres Docker.

1
2


# Configuração do código de quebra de linha do Git no lado do WSL
git config --global core.autocrlf input

Adicione também o seguinte ao settings.json (configurações remotas) do VS Code:

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. Otimização do Docker Desktop e Integração WSL2

Para usar o Docker no ambiente WSL2, existem principalmente duas abordagens:

Instalar o Docker Desktop for Windows e ativar o recurso de integração com o WSL2
Instalar o Docker Engine nativo diretamente dentro do WSL2 (Ubuntu, etc.)

Abordagem 1: Docker Desktop (Recomendado)

Esta abordagem é recomendada na maioria dos casos porque facilita o gerenciamento via GUI e o acesso transparente a contêineres entre Windows/WSL. Verifique o seguinte nas Configurações (Settings) do Docker Desktop:

Em General, marque a opção Use the WSL 2 based engine.
Em Resources -> WSL Integration, marque a opção Enable integration with my default WSL distro e ligue a chave seletora para a distribuição (Ubuntu) a ser usada.

Isso permite que o comando docker seja executado diretamente do terminal do WSL2, e a comunicação com o daemon do Docker ocorra por meio de uma VM leve dedicada (docker-desktop e docker-desktop-data) gerenciada pelo Docker Desktop.

Abordagem 2: Instalação Direta do Docker Engine Nativo

Se houver restrições de rede corporativa (como evitar taxas de licenciamento do Docker Desktop) ou se você quiser reduzir ao máximo a sobrecarga de desempenho, ative o systemd em /etc/wsl.conf e instale o Docker como um servidor Ubuntu puro.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Trecho do procedimento oficial de instalação do Docker no Ubuntu WSL2 com systemd ativado
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Adição do repositório
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Adicionar o usuário atual ao grupo docker (para executar sem sudo)
sudo usermod -aG docker $USER

Após a reinicialização, o systemctl start docker funcionará exatamente como em um ambiente Linux nativo, oferecendo alto desempenho.

8. Integração da Chave SSH: Autenticação Perfeita entre Windows e WSL

Ao clonar repositórios Git via SSH ou conectar-se a servidores remotos via SSH, é muito trabalhoso gerenciar chaves SSH separadamente nos lados do Windows e do WSL. Para equilibrar segurança e conveniência, configuraremos uma ponte entre o agente SSH em execução no lado do Windows (ou um gerenciador de senhas como o 1Password) e o lado do WSL.

Aqui, explicaremos o método de usar a funcionalidade de agente SSH do 1Password ou o OpenSSH Authentication Agent do Windows como a abordagem mais segura e moderna, encaminhando-o para o soquete de domínio UNIX do WSL2 usando npiperelay e socat.

Encaminhamento de Soquete do ssh-agent

O agente SSH, que normalmente é fornecido como um Named Pipe (pipe nomeado) no Windows, deve ser convertido em um arquivo de soquete no lado do WSL. É fácil fazer isso usando recursos fornecidos pelo wsl-ssh-agent ou pelo 1Password.

Na tela de configurações do 1Password, ative “Developer” -> “Usar Agente SSH”. Em seguida, adicione as seguintes configurações ao ~/.zshrc ou ~/.bashrc do lado do WSL para vincular automaticamente o soquete ao fazer login.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Adição ao ~/.zshrc (Exemplo ao usar o 1Password SSH Agent)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# Encaminhar usando socat e npiperelay se o soquete não existir ou o processo não estiver vinculado quando o WSL iniciar
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # Inicia o socat em segundo plano e conecta o Named Pipe do lado do Windows ao soquete UNIX do lado do WSL
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

É necessário instalar o npiperelay.exe no lado do Windows e adicionar seu caminho ao PATH antecipadamente.

Quando essa configuração estiver concluída, a execução de ssh-add -l a partir do terminal do WSL exibirá uma lista de chaves públicas das chaves SSH registradas no 1Password ou no lado do Windows. Isso permite que você passe pela autenticação com segurança, sem copiar arquivos de chave privada para dentro do WSL.

9. Manutenção: Otimização (Compactação) de VHDX Inchado

Uma das maiores falhas do WSL2 é a especificação de que “mesmo se você excluir imagens do Docker ou arquivos, o tamanho do arquivo do disco virtual do lado do Windows (.vhdx) não será reduzido automaticamente”. Após um longo período de desenvolvimento, o arquivo ext4.vhdx pode inchar para dezenas a centenas de gigabytes.

Para liberar espaço em disco, você deve otimizar (Compactar) periodicamente o VHDX no lado do Windows.

Primeiro, desligue completamente o WSL.
1

wsl --shutdown
Abra o PowerShell com privilégios de administrador e execute o comando diskpart a seguir ou o comando Optimize-VHD do módulo Hyper-V (o último só pode ser usado se o Hyper-V estiver ativado).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Quando o módulo Hyper-V está disponível
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# Quando usar o diskpart
diskpart
# Digite interativamente no prompt abaixo
DISKPART> select vdisk file="C:\Users\<NomeDoUsuario>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

Ao executar essa operação regularmente, você pode recuperar o espaço consumido desnecessariamente na unidade C.

10. Conclusão

O WSL2 transcendeu completamente o quadro de ser apenas um “Linux de bônus rodando no Windows” e evoluiu para uma plataforma de desenvolvimento poderosa que rivaliza ou até supera o MacOS ou máquinas Linux nativas.

Ao aplicar todas as configurações explicadas desta vez (otimização de recursos com .wslconfig, aprimoramento de terminal com Zsh + Powerlevel10k, acesso transparente com VS Code Remote e integração SSH e manutenção de VHDX), o “ambiente de desenvolvimento definitivo” livre de estresse, rápido e seguro estará completo.

Demora um pouco para configurar o ambiente, mas uma vez que você consolide suas configurações, não há dúvida de que sua produtividade em engenharia melhorará drasticamente de agora em diante. Sinta-se à vontade para explorar mais personalizações com base neste guia para atender aos seus próprios projetos e preferências.