A Arquitetura do Hyper-V

Se o KVM transforma o kernel Linux inteiro em hipervisor, o Hyper-V faz o oposto: insere uma camada minúscula abaixo do Windows e rebaixa o próprio sistema operacional que você enxerga à condição de convidado privilegiado. Entender essa inversão é entender por que quase tudo no Hyper-V — partições, VMBus, VSP/VSC, VBS, Shielded VMs e Confidential Computing — tem o formato que tem. Este documento abre o capô peça por peça.

Parte I — O hipervisor Hyper-V: o microkernel em ring -1

1. Tipo 1, mas de outro tipo: microkernelizado vs. monolítico

Todo mundo repete que o Hyper-V é um hipervisor "Tipo 1" (bare-metal), e é. Mas essa etiqueta esconde a decisão de projeto mais importante da Microsoft: o Hyper-V é um hipervisor microkernelizado, e isso o separa radicalmente do KVM.

No modelo do KVM, o hipervisor é o kernel Linux. Todos os drivers de dispositivo, o escalonador, a pilha de rede, o subsistema de armazenamento — tudo roda no mesmo espaço privilegiado que faz a virtualização. É um hipervisor monolítico: a superfície de código com privilégio máximo é gigantesca, porque inclui o kernel de propósito geral inteiro.

O Hyper-V escolheu o caminho inverso. A camada que roda no nível de privilégio máximo da CPU é deliberadamente pequena: ela cuida de escalonamento de CPU virtual, gestão de tradução de memória, entrega de interrupções e o roteamento de mensagens entre partições — e nada de drivers de dispositivo. Não há driver de rede, de disco, de GPU dentro do hipervisor. Esses drivers ficam onde sempre estiveram: dentro de uma instância do Windows, que passa a ser apenas mais uma partição — a partição raiz.

A consequência prática é enorme. Quando você instala a função Hyper-V num Windows Server "normal", o que acontece no boot não é o Windows carregando um programa de virtualização. É o contrário: um pequeno hipervisor é carregado primeiro, assume o ring de maior privilégio, e então inicia o Windows dentro de uma partição. O Windows que você administra depois disso já está virtualizado — ele simplesmente é a partição que tem acesso privilegiado ao hardware. Essa é a diferença entre "o Linux vira hipervisor" (KVM) e "o hipervisor engole o Windows" (Hyper-V).

Modelo mental. No KVM, o hipervisor mora dentro do host. No Hyper-V, o host mora dentro do hipervisor. Não existe "sistema operacional hospedeiro" no sentido tradicional — existe uma partição raiz que é a primeira convidada e a única com privilégio de gestão.

Essa arquitetura tem um custo (todo I/O de dispositivo sintético precisa transitar até a partição raiz, que detém os drivers reais) e um benefício de segurança que só ficou óbvio anos depois: se a camada de privilégio máximo é minúscula e não contém drivers, ela é auditável e pequena o bastante para servir de raiz de confiança — é exatamente isso que a Virtualization-Based Security, as Shielded VMs e o Confidential Computing exploram.

2. Os binários do hipervisor: hvix64, hvax64, hvaa64 e a carga no boot

O hipervisor Hyper-V não é um serviço, um driver comum ou um processo. É uma imagem executável separada, carregada antes do kernel do Windows, com um binário específico por arquitetura de CPU:

• hvix64.exe — o hipervisor para processadores Intel (usa o conjunto de instruções VT-x/VMX).
• hvax64.exe — o hipervisor para processadores AMD (usa AMD-V/SVM).
• hvaa64.exe — o hipervisor para ARM64 (usa as extensões de virtualização do ARM).

Apesar da extensão .exe, esses não são programas de usuário. Eles são carregados pelo gerenciador de boot do Windows por meio do hvloader, antes de o winload.efi transferir o controle ao kernel. A sequência simplificada é: firmware UEFI → gerenciador de boot → hvloader detecta a CPU e carrega o hvix64/hvax64/hvaa64 correto → o hipervisor inicializa e assume o nível de privilégio de virtualização (VMX root no Intel, EL2 no ARM) → só então o Windows é iniciado, já como partição raiz.

Por que um binário por fabricante? Porque as extensões de virtualização de hardware da Intel e da AMD são incompatíveis no nível de instrução. A Intel expõe a família VMX com a estrutura de controle VMCS (Virtual Machine Control Structure); a AMD expõe SVM com a estrutura VMCB (Virtual Machine Control Block). Um "VM exit" — o evento em que o convidado devolve o controle ao hipervisor — tem semântica, campos e códigos de causa diferentes nas duas. Em vez de encher um único binário de desvios condicionais no caminho mais quente do sistema, a Microsoft compila hipervisores separados. É a mesma realidade que o KVM enfrenta com os módulos kvm-intel.ko e kvm-amd.ko; a diferença é apenas de empacotamento.

Você pode confirmar qual está no ar. Num host Hyper-V, msinfo32 (ou o comando systeminfo) mostra os requisitos de Hyper-V, e a presença do hipervisor aparece como "Um hipervisor foi detectado". No log de boot, o hvloader e a imagem carregada são registrados. O ponto conceitual: o hipervisor é uma peça de firmware-quase-software que se instala sob o Windows, não sobre ele.

3. SLAT: a tradução de endereço de segundo nível

Nenhum hipervisor moderno de alto desempenho vive sem SLAT (Second Level Address Translation) — e o Hyper-V a exige como pré-requisito de hardware, não como opcional.

O problema que a SLAT resolve é o da memória. Dentro de uma VM, o sistema convidado acredita ter memória física começando em zero e mantém suas próprias tabelas de página, traduzindo endereços virtuais do convidado (GVA) para o que ele pensa serem endereços físicos (GPA — guest physical address). Mas esses GPAs são ficção: a memória "física" da VM é, na verdade, memória alocada pela partição raiz em algum lugar da RAM real (SPA — system physical address). Sem ajuda de hardware, toda vez que o convidado tocasse a memória, o hipervisor teria de interceptar e refazer a tradução por software — a antiga técnica das shadow page tables, que era correta, mas cara: cada alteração nas tabelas do convidado gerava um VM exit.

A SLAT coloca essa segunda tradução dentro da CPU. Na Intel chama-se EPT (Extended Page Tables); na AMD, NPT (Nested Page Tables), também comercializado como RVI. O mecanismo é o mesmo: a MMU passa a fazer duas traduções em cascata por acesso — primeiro GVA→GPA usando as tabelas do convidado, depois GPA→SPA usando uma segunda tabela mantida pelo hipervisor. Tudo em hardware, sem VM exit para acessos comuns de memória. É o análogo exato do que o EPT/NPT faz para o KVM; a Microsoft apenas exige que ele exista para sequer habilitar a função.

Além do ganho de desempenho, a SLAT é o que torna barato isolar memória entre partições e, mais tarde, entre níveis de confiança dentro da mesma partição (a base do HVCI, do Credential Guard e do HVPT). Guarde essa ideia: a mesma engrenagem que acelera a VM é a que permite trancar páginas contra o próprio kernel do host.

4. O modelo de partições: por que não existe "host"

A unidade de isolamento do Hyper-V não é a "VM" nem a "máquina host". É a partição. Uma partição é um contêiner de isolamento com seu próprio espaço de endereçamento físico (o conjunto de GPAs que a SLAT mapeia) e seus próprios processadores virtuais. O hipervisor conhece partições; ele não conhece "sistemas operacionais".

Existem dois tipos:

• Partição raiz (ou partição pai) — criada automaticamente quando o hipervisor sobe. É a primeira partição, roda o Windows completo e é a única com acesso direto ao hardware físico e às APIs de gestão. É ela que possui os drivers de dispositivo reais e que fabrica, monitora e destrói as demais partições.
• Partições filhas — as VMs propriamente ditas. Não têm acesso direto ao hardware físico. Quando uma partição filha quer ler um disco ou enviar um pacote, ela não fala com o hardware: fala, via VMBus, com um provedor de serviço que roda na partição raiz.

Essa hierarquia explica por que "host" é um termo impreciso no mundo Hyper-V. Aquilo que você chama de host é a partição raiz — poderosa, sim, mas ainda assim uma partição rodando sobre o hipervisor, sujeita ao escalonamento de vProcessors dele como qualquer outra. A partição raiz tem privilégios especiais (o direito de criar partições, de acessar hardware físico, de emitir determinadas hypercalls de gestão), mas não tem o privilégio máximo da máquina — esse pertence ao hipervisor.

Modelo mental. Pense em três anéis concêntricos. No centro, o hipervisor (privilégio máximo, minúsculo). No anel do meio, a partição raiz (Windows completo, drivers, gestão). No anel externo, as partições filhas (as VMs). O I/O das filhas sempre flui para dentro, até a raiz, que detém o hardware — nunca direto ao metal.

5. Hypercalls: a interface com o hipervisor

Se as partições não podem tocar o hardware nem o hipervisor diretamente, como elas pedem qualquer coisa a ele? Por hypercalls — o equivalente, no mundo da virtualização, de uma chamada de sistema. Uma hypercall é uma instrução deliberada que causa uma transição para o hipervisor, passando um código de operação e parâmetros. É o caminho "de baixo para cima" simétrico ao VM exit (o caminho involuntário, em que o convidado é interrompido por tentar algo que exige mediação).

A Microsoft documenta esse contrato numa especificação pública, a Hypervisor Top-Level Functional Specification (TLFS). É um detalhe estratégico e não decorativo: a TLFS transforma a interface do hipervisor em algo estável e implementável por terceiros. Graças a ela, o KVM no Linux consegue emular a interface Hyper-V para convidados Windows — apresentando os mesmos "enlightenments" que o Windows espera —, e projetos como o OpenVMM/OpenHCL conseguem construir sobre a mesma superfície. É o oposto de uma caixa-preta.

Hypercalls carregam trabalho real: sinalização entre partições, gestão de mapeamentos de memória, envio de interrupções inter-processador virtuais, e as operações que sustentam a comunicação por VMBus. Junto delas, o hipervisor expõe às partições um conjunto de MSRs sintéticos (registradores de modelo específico virtuais) e páginas compartilhadas — por exemplo, uma página de código de hypercall que o convidado mapeia, e páginas de "SynIC" (Synthetic Interrupt Controller) para entrega de eventos e mensagens. Um convidado "iluminado" descobre tudo isso lendo folhas específicas da instrução CPUID, nas quais o hipervisor se anuncia e lista quais recursos oferece.

O par conceitual a fixar é este: VM exit é o convidado sendo puxado para o hipervisor porque fez algo que exige mediação; hypercall é o convidado escolhendo chamar o hipervisor para pedir um serviço. Um é involuntário, o outro é uma API. Os dois, juntos, são toda a conversa entre uma partição e a camada que está por baixo dela.

Parte II — A partição raiz e o modelo de processo por VM

6. A partição raiz: o kernel privilegiado

Vale insistir no que a partição raiz é, porque é onde mora quase todo o software que os administradores associam ao Hyper-V. O hipervisor é minúsculo e mudo; a inteligência operacional vive na raiz.

A raiz é uma instância completa do Windows (Server, ou o Windows cliente com a função habilitada) com três responsabilidades que nenhuma partição filha tem: ela possui os drivers de dispositivo físico (a placa de rede real, a controladora de disco real, a GPU real são enxergadas e operadas por drivers Windows na raiz); ela oferece serviços de dispositivo às filhas por meio dos provedores que rodam nela; e ela hospeda a pilha de gestão — os serviços, drivers e processos que criam, configuram, monitoram e destroem partições.

É importante frisar que "ter os drivers" não significa "ter o privilégio máximo". A raiz é privilegiada em relação às filhas, mas ainda é escalonada pelo hipervisor e ainda emite hypercalls para conseguir o que quer. Quando um pacote precisa sair pela NIC física, ele percorre um caminho longo: chega da partição filha via VMBus até um provedor na raiz, que então entrega o pacote ao driver físico real, que fala com o hardware. A raiz é o intermediário obrigatório de todo I/O sintético.

Isso responde a uma dúvida comum: "por que meu host Hyper-V consome CPU mesmo com as VMs 'ociosas'?" Porque a raiz está fazendo trabalho real de I/O por todas elas. Ela não é um observador passivo; é o motor de dispositivos de todo o sistema.

7. VID (vid.sys): o driver de infraestrutura de virtualização

Dentro da raiz, o primeiro componente que precisa ser nomeado é o VID — Virtualization Infrastructure Driver, o vid.sys. Ele é a ponte de baixo nível entre o software de gestão (que roda em modo usuário na raiz) e o hipervisor (que roda abaixo de todos).

O VID cuida das coisas que exigem intimidade com o hipervisor e com o hardware: a gestão de memória das partições (reservar e mapear as páginas físicas do sistema que se tornarão a "RAM" de cada VM, montando as tabelas SLAT correspondentes) e a gestão dos processadores virtuais (criar os vProcessors de uma partição e mediar seu ciclo de vida). Quando o software de gestão em modo usuário quer alocar 16 GB para uma VM, ele não fala com o hipervisor diretamente — ele pede ao VID, que traduz o pedido em hypercalls e em manipulação de tabelas de memória.

Ao lado do VID trabalha a WinHvr (a biblioteca/driver de interface de hypercall do Windows), que padroniza como os componentes da raiz emitem hypercalls. Pense no VID como o gerente de recursos físicos de cada partição, operando logo acima do hipervisor e logo abaixo dos processos de gestão.

8. VMMS (vmms.exe): o gerente de estado

Um nível acima, em modo usuário, está o VMMS — Virtual Machine Management Service, o vmms.exe. Se o VID é o gerente de recursos, o VMMS é o gerente de estado e ciclo de vida. É o serviço com o qual toda ferramenta de administração conversa.

O VMMS mantém a verdade sobre cada VM: sua configuração, seu estado (desligada, salva, em execução, em pausa), seus snapshots, suas permissões. Ele orquestra as transições — ligar, desligar, salvar estado, criar checkpoint, iniciar uma live migration — coordenando os componentes de baixo nível para que a operação aconteça de forma consistente. Quando você clica em "Iniciar" no Hyper-V Manager, ou roda Start-VM no PowerShell, é o VMMS que recebe o pedido, valida, aloca o que precisa (via VID) e sobe a máquina.

Crucialmente, o VMMS não executa a VM. Ele é o maestro, não o instrumento. A execução propriamente dita — o laço que roda os vProcessors e serve o I/O — pertence a outro processo, um por VM.

9. O Worker Process (vmwp.exe): um processo por VM

Aqui está o paralelo mais direto entre Hyper-V e QEMU, e ele surpreende quem só conhece um dos dois mundos.

No Hyper-V, cada máquina virtual em execução é respaldada por uma instância separada do Virtual Machine Worker Process — o vmwp.exe. Uma VM ligada, um vmwp.exe. Dez VMs ligadas, dez processos vmwp.exe na partição raiz, cada um rodando sob uma conta de segurança dedicada e isolada daquela VM. É exatamente o mesmo princípio do QEMU no mundo KVM, onde cada VM é um processo QEMU separado no espaço de usuário do Linux.

O que o Worker Process faz: ele é o espaço de usuário daquela VM dentro da raiz. Ele hospeda a emulação dos dispositivos virtuais legados (o chipset, o controlador de interrupção emulado, a BIOS/UEFI, os dispositivos IDE em VMs de Geração 1), gerencia o estado de runtime da máquina e serve de ponto de contato entre aquela partição filha e o resto da pilha de gestão. Quando um convidado de Geração 1 acessa uma porta de I/O emulada, o VM exit correspondente acaba sendo tratado, em última instância, pelo vmwp.exe daquela VM — assim como um acesso emulado numa VM KVM é tratado pela thread do processo QEMU.

Esse desenho traz três benefícios que valem nomear:

1. Isolamento por falha. Se o Worker Process de uma VM travar ou for comprometido, ele carrega consigo apenas aquela VM. Os outros vmwp.exe, o VMMS e a raiz seguem de pé. Um único processo não derruba o host.
2. Isolamento por segurança. Cada Worker Process roda com uma identidade única e mínima (quase no estilo AppContainer). A superfície de ataque a partir de dentro de uma VM está confinada ao processo que a serve.
3. Contabilidade natural. Como cada VM é um processo, a atribuição de CPU e memória da raiz a uma VM específica é observável no nível do sistema operacional — você literalmente vê o vmwp.exe da VM no gerenciador de tarefas.

Modelo mental. VMMS é o maestro (um, coordena todos). Cada vmwp.exe é um músico (um por VM, toca só a sua parte). O hipervisor é a sala de concerto (fornece o espaço e o tempo — CPU e memória — a todos). A analogia com QEMU é quase perfeita: vmwp.exe está para o Hyper-V como o processo qemu-system-x86_64 está para o KVM.

10. WMI, PowerShell, WHP e o HCS: as portas de gestão

A camada com a qual humanos e automações interagem fica acima do VMMS. O Hyper-V expõe um provedor WMI (Windows Management Instrumentation) rico, com namespaces dedicados que descrevem VMs, adaptadores, discos, snapshots e migrações como objetos gerenciáveis. Toda a superfície gráfica (Hyper-V Manager, Failover Cluster Manager, Windows Admin Center) e todo o módulo Hyper-V do PowerShell (Get-VM, New-VM, Set-VMProcessor, Move-VM…) são, no fundo, clientes desse provedor WMI, que por sua vez conversa com o VMMS. É a razão de tudo no Hyper-V ser automatizável: a GUI não tem poderes que o script não tenha.

Há ainda uma porta lateral que merece destaque por ser o análogo mais próximo do /dev/kvm: a Windows Hypervisor Platform (WHP). É uma API pública, em modo usuário, que permite a pilhas de virtualização de terceiros usar o hipervisor Hyper-V como motor de execução — criar partições, mapear memória, rodar vProcessors — sem passar pela pilha de VMs da Microsoft. É graças à WHP que VirtualBox, VMware Workstation e o QEMU para Windows conseguem coexistir com o Hyper-V ligado, executando suas VMs sobre o hipervisor da Microsoft em vez de brigar com ele pelo controle das extensões de virtualização da CPU. Onde o Linux oferece /dev/kvm como o motor de virtualização reutilizável, o Windows oferece a WHP.

Há, porém, um cenário em que o VMMS e o WMI são pesados demais: contêineres e WSL2 precisam criar e destruir "VMs" (na prática, Utility VMs efêmeras) em frações de segundo, não em segundos — o tempo típico de uma chamada WMI. Para isso, a Microsoft construiu um caminho paralelo, mais enxuto: o HCS — Host Compute Service. É um serviço próprio (vmcompute.exe) exposto por uma API nativa em C (vmcompute.dll/ComputeCore.dll, com funções como HcsCreateComputeSystem) que cria e gerencia diretamente os compute systems — VMs e contêineres — sem passar pelo WMI nem, na maior parte do caminho, pelo VMMS. O vmcompute.exe fala diretamente com o VID e pode instanciar o vmwp.exe da VM quando necessário. Ferramentas como o Docker Desktop e o containerd no Windows não conversam com Get-VM; conversam com o HCS via a biblioteca hcsshim. Junto dele vem o HNS/HCN (Host (Compute) Network Service), o equivalente do HCS para redes de contêiner. Em suma: o VMMS continua sendo o gerente de VMs persistentes e de longa duração; o HCS é o motor voltado a cargas efêmeras.

Isso fecha o retrato da partição raiz: do hipervisor para cima, temos o VID (recursos), o VMMS (estado, para VMs persistentes), um vmwp.exe por VM (execução), o HCS/HNS (o motor rápido para VMs e contêineres efêmeros) e, no topo, WMI/PowerShell (gestão) mais a WHP (motor para terceiros). Nenhuma dessas peças toca a VM sem passar pelas de baixo — é uma pilha, não um amontoado.

Parte III — Virtualização de dispositivos: emulado, sintético e passthrough

Toda a Parte III responde a uma pergunta: se a partição filha não pode tocar o hardware, como ela ganha disco, rede, vídeo e USB? Há três respostas, em ordem crescente de desempenho e decrescente de compatibilidade universal — e elas espelham, quase um a um, as três formas de entrega de hardware do mundo QEMU/KVM (emulação total, VirtIO/paravirtualização e passthrough).

11. Dispositivos emulados: compatibilidade a custo de desempenho

A forma mais antiga e mais compatível é a emulação. Aqui, o Hyper-V finge, em software, ser uma peça de hardware real e conhecida — tão conhecida que praticamente qualquer sistema operacional já traz o driver de fábrica. Em VMs de Geração 1, os exemplos clássicos são o chipset Intel 440BX, uma controladora IDE para o disco de boot, uma placa de rede DEC/Intel 21140 ("Legacy Network Adapter") e uma placa de vídeo VGA básica.

O mecanismo é o VM exit. Quando o convidado escreve numa porta de I/O ou num registrador mapeado em memória daquele "hardware", a CPU intercepta a operação e a devolve ao hipervisor, que a encaminha para ser tratada em software — em última instância pelo vmwp.exe daquela VM. Cada operação de I/O vira, portanto, uma saída cara da VM. Funciona com tudo, mas é lento.

Por isso a emulação tem um único papel legítimo hoje: compatibilidade e boot. Você emula o mínimo necessário para o sistema convidado iniciar e reconhecer que está vivo; depois, se o convidado for "iluminado", ele troca para os dispositivos sintéticos, muito mais rápidos.

12. VMBus: o barramento entre partições

O coração do caminho rápido do Hyper-V é o VMBus. Ele é um canal de comunicação em memória, ponto a ponto, de alta velocidade, que liga uma partição filha à partição raiz. Não é um barramento de hardware emulado — é um mecanismo de software, sustentado por memória compartilhada e pela sinalização por hypercall/SynIC. É a fundação sobre a qual todos os dispositivos sintéticos operam, e o análogo funcional do transporte do VirtIO (as virtqueues e vrings).

O funcionamento essencial: partição filha e raiz estabelecem um canal sobre o VMBus. A troca de dados em volume não passa por cópia byte a byte mediada pelo hipervisor — ela usa memória compartilhada entre as duas partições, na forma de anéis (buffers circulares) onde uma ponta deposita requisições e a outra as consome. A sinalização de "há trabalho novo" é feita por interrupções virtuais leves entregues pelo SynIC. Ou seja: o volume de dados trafega por memória compartilhada (barato), e apenas a notificação usa o hipervisor (raro). É precisamente o desenho que dá ao VirtIO sua eficiência.

O VMBus também descobre e conecta dispositivos dinamicamente: quando você adiciona um adaptador de rede sintético a uma VM, um novo canal é oferecido pelo VMBus, o convidado o enxerga e associa seu driver sintético a ele.

13. VSP/VSC: o modelo provedor/consumidor

Sobre o VMBus roda o modelo que dá nome e forma à paravirtualização do Hyper-V: o par VSP/VSC.

• VSP — Virtualization Service Provider. Roda na partição raiz. É a ponta que tem acesso ao dispositivo físico real (via os drivers do Windows na raiz) e que oferece o serviço daquele tipo de dispositivo às partições filhas. Há um VSP por classe de dispositivo: storvsp.sys para armazenamento, netvsp.sys (dentro do vSwitch) para rede.
• VSC — Virtualization Service Consumer. Roda na partição filha, dentro do sistema convidado. É um driver sintético que consome o serviço oferecido pelo VSP. O convidado enxerga um disco ou uma placa de rede "normais", mas o driver por trás deles não fala com hardware — fala, via VMBus, com o VSP na raiz. Os nomes espelham os do provedor: storvsc para armazenamento, netvsc para rede.

O fluxo de uma leitura de disco numa VM iluminada, ponta a ponta: a aplicação no convidado pede a leitura → o sistema convidado entrega ao driver sintético VSC (storvsc) → o VSC empacota a requisição e a deposita no anel de memória compartilhada do canal VMBus → o VMBus sinaliza a raiz → o VSP (storvsp) na raiz retira a requisição, repassa-a ao driver de armazenamento físico real, que executa o I/O no hardware verdadeiro → o resultado volta pelo mesmo caminho. Nenhuma emulação de porta de I/O, nenhum VM exit por operação; apenas depósito em anel e uma notificação.

Esse par VSP/VSC é o VirtIO do Hyper-V. A correspondência é quase literal: o VSC é o front-end (driver no convidado); o VSP é o back-end (o servidor do dispositivo); e o VMBus com seus anéis é o transporte.

Modelo mental. VSC pergunta, VSP responde, VMBus carrega a conversa. O convidado "iluminado" sabe que é uma VM e conversa nesse protocolo enxuto em vez de fingir operar hardware físico — que é, palavra por palavra, a definição de paravirtualização.

14. O comutador virtual extensível: a rede em camada 2

O ponto onde todo o tráfego de rede das partições se encontra é o Hyper-V Extensible Virtual Switch — um switch Ethernet de camada 2 implementado em software, que roda na partição raiz e comuta quadros entre as VMs e a rede física.

A estrutura básica reaproveita o modelo VSP/VSC: cada VM tem um ou mais adaptadores de rede sintéticos, cujo driver VSC (netvsc) conversa, via VMBus, com o VSP de rede (netvsp) na raiz. Mas o netvsp não entrega o quadro diretamente à NIC física — ele o entrega a uma porta do vSwitch. É o vSwitch quem decide o destino do quadro com base no endereço MAC.

Há três tipos de vSwitch: externo (ligado a uma NIC física), interno (comuta entre as VMs e a raiz) e privado (comuta só entre as VMs).

O que dá o sobrenome "extensível" é que o caminho de dados do vSwitch é aberto a extensões de terceiros, implementadas como drivers de filtro NDIS ou como callouts da WFP. São três classes:

• Captura (capturing) — inspeciona e monitora, mas não modifica.
• Filtragem (filtering) — pode modificar, inserir e descartar pacotes e aplicar políticas.
• Encaminhamento (forwarding) — substitui a lógica de encaminhamento nativa do switch. É assim que o Open vSwitch se integra ao Hyper-V.

Sobre esse comutador se apoiam VLANs, PVLANs, ACLs, QoS, espelhamento de porta, DHCP guard e router guard. Quando uma função virtual de SR-IOV é atribuída a uma VM, o caminho de dados contorna o vSwitch e vai direto ao hardware — mas o caminho de controle e um fallback sintético continuam de pé.

15. Enlightenments: as iluminações do convidado

"Iluminação" (enlightenment) é o termo da Microsoft para qualquer ponto em que o sistema convidado sabe que é uma VM e coopera com o hipervisor. Os drivers VSC são a forma mais visível, mas não a única:

• Gestão de memória e TLB (hypercalls de flush coordenado).
• Spinlocks e sinalização entre vCPUs (evita busy-wait).
• Relógio e temporização (fontes sintéticas).
• Entrega de interrupções via SynIC.

O convidado descobre quais iluminações estão disponíveis lendo as folhas de CPUID. Como a interface é a TLFS pública, o Linux implementa as iluminações do Hyper-V — um Linux moderno é um convidado de primeira classe.

16. Passthrough: DDA, GPU-P e SR-IOV

A terceira via entrega um pedaço de hardware físico diretamente a uma partição filha.

DDA — Discrete Device Assignment. Passthrough clássico de um dispositivo PCIe inteiro (GPU, NVMe, NIC). Exige IOMMU (Intel VT-d / AMD-Vi). Historicamente impede live migration.

SR-IOV — Single-Root I/O Virtualization. Passthrough com compartilhamento. A placa se apresenta como PF + várias VFs. O Hyper-V nunca entrega a VF "pelada": a VM continua tendo o adaptador sintético associado, formando um teaming interno. Isso viabiliza o VF failover — durante live migration ou falta de VFs, o tráfego cai graciosamente para o caminho sintético sem derrubar conexões TCP.

GPU-P — GPU Partitioning. Novidade do Windows Server 2025. Fatia uma GPU física em partições isoladas via SR-IOV e entrega frações a VMs. Suporta live migration (embora caia para TCP/IP com compressão). Ideal para VDI e inferência de IA.

O quadro fecha: emulado (compatível, lento) → sintético via VSP/VSC sobre VMBus (padrão, rápido) → passthrough DDA/SR-IOV/GPU-P (quase nativo).

Parte IV — Montando uma VM de ponta a ponta

17. Geração 1 vs. Geração 2

Geração 1 reproduz um PC tradicional: firmware BIOS legado, dispositivos emulados para boot (IDE, Legacy Network Adapter). Compatível com sistemas antigos.

Geração 2 é a máquina redesenhada: firmware UEFI + Secure Boot, boot a partir de disco SCSI sintético, sem dispositivos legados emulados. Mais rápida, mais segura e pré-requisito para Shielded VMs e recursos modernos de segurança. Use Geração 2 sempre que o convidado suportar.

Paralelo com QEMU/Proxmox: Geração 1 ≈ i440fx + SeaBIOS; Geração 2 ≈ q35 + OVMF/UEFI.

18. Anatomia dos arquivos: .vmcx, .vmrs, .vhdx e companhia

• .vmcx — configuração (formato binário desde 2016).
• .vmrs — estado de runtime (save state).
• .vhdx — disco virtual (fixo, dinâmico ou diferencial). Sucessor do .vhd, até 64 TB, resiliente a queda de energia.
• .avhdx — disco diferencial criado por checkpoint.
• .vhds — VHD Set. É o disco virtual compartilhável entre várias VMs, a fundação dos guest clusters (clusters formados por VMs, como um SQL Server AlwaysOn FCI ou um cluster de File Server rodando dentro de convidados). Substituiu o antigo Shared VHDX a partir do Windows Server 2016 e removeu suas limitações: com VHD Set dá para fazer backup a nível de host (sem agente no convidado), redimensionar online e usar Hyper-V Replica. Na prática são dois arquivos — o .vhds guarda os metadados que coordenam o compartilhamento entre os nós, e um .avhdx associado guarda os dados. O ganho arquitetural: monta-se um cluster de convidados com disco compartilhado sem precisar recorrer a iSCSI, NPIV ou Fibre Channel virtual dentro da VM.
• .vmgs — Virtual Machine Guest State (vTPM + bases de assinatura do Secure Boot). Crítico: em VMs com BitLocker protegido por vTPM, perder o .vmgs sem backup é perder o acesso aos dados.
• .rct e .mrt — Resilient Change Tracking (o CBT nativo do Hyper-V). O .rct é write-back (dia a dia); o .mrt é write-through (sobrevive a dirty shutdown).

CSV (Cluster Shared Volume). Num cluster, os discos vivem em CSV. O CSVFS fica sobre o NTFS/ReFS e separa metadados (sempre pelo nó coordenador) de dados (Direct I/O quando possível, Redirected I/O via SMB como fallback). É o que torna live migration e failover rápidos: o disco já está acessível no destino.

19. Do config aos vProcessors: o agendamento de CPU

O Hyper-V oferece três escalonadores:

• Classic scheduler — histórico, pool de processadores lógicos. Pode colocar vProcessors de VMs diferentes nas duas threads SMT do mesmo núcleo, o que abre caminho para vazamento entre VMs via canal lateral. Por causa disso, após as mitigações de L1TF e MDS a Microsoft deixou de usá-lo como padrão — o Core scheduler assumiu como default a partir do Windows Server 2019. Usar o Classic hoje num host multi-tenant é um risco de segurança que a própria plataforma desencoraja.
• Core scheduler — padrão desde Windows Server 2019. Agenda por núcleo físico: as duas threads SMT nunca hospedam VMs diferentes ao mesmo tempo. Recomendado para multi-tenant.
• Root scheduler — usado no Windows cliente e em Utility VMs (WSL2, Sandbox, containers Hyper-V). Delega a decisão ao escalonador do Windows da partição raiz.

vNUMA (NUMA virtual). Escalonar vCPU é metade da história; a outra metade é onde está a memória que esses vProcessors acessam. Em servidores físicos com vários soquetes, a RAM é dividida em nós NUMA: um núcleo acessa a memória do seu próprio nó (local) muito mais rápido do que a de outro nó (remota). Numa VM grande — pense num SQL Server com dezenas de vCPUs e centenas de GB —, ignorar isso mata o desempenho. O Hyper-V resolve com o vNUMA: ele projeta a topologia NUMA física para dentro do convidado, de modo que o sistema operacional e a aplicação da VM enxergam os nós NUMA e conseguem otimizar seus acessos (alocando memória e agendando threads no nó local). SQL Server, JVMs e outros softwares NUMA-aware exploram isso diretamente. Por padrão, a topologia vNUMA apresentada espelha a do host; se a VM for maior que um nó NUMA físico, o vNUMA é o que evita que ela sofra penalidade de acesso remoto sem saber por quê. É também um ponto de atenção em Dynamic Memory, que interage com o alinhamento dos nós.

20. Integration Services: o "guest agent" do Hyper-V

Equivalente ao QEMU Guest Agent / VMware Tools. Componentes principais:

• Operating System Shutdown
• Time Synchronization
• Data Exchange (KVP)
• Heartbeat
• Backup (VSS) — essencial para Production Checkpoints
• Guest Services (cópia de arquivos)

21. Dynamic Memory, Live Migration e Checkpoints

Dynamic Memory. Combina hot-add + driver de balão no convidado (parte dos Integration Services). Mesmo princípio do virtio-balloon.

Live Migration. Algoritmo de pre-copy clássico: transferência de memória em background + rodadas de dirty pages + pause curto final. Transporte pode usar TCP/IP, compressão ou SMB Direct/RDMA. VMs com GPU-P migram (com restrições); VMs com DDA puro não.

Checkpoints. - Standard — captura memória + dispositivos (bom para testes, arriscado para produção). - Production — usa VSS para quiesce (padrão recomendado).

No ReFS, o merge de .avhdx vira operação de metadados graças ao Block Cloning (quase instantâneo).

Parte V — Hyper-V além das VMs: segurança, nested, ARM e Confidential Computing

22. VBS: quando o hipervisor protege o próprio host

A Virtualization-Based Security (VBS) usa o mesmo hipervisor para isolar partes do Windows do resto do próprio Windows — inclusive do seu kernel. É por isso que, em máquinas modernas, o Hyper-V está frequentemente "ligado" mesmo em desktops que nunca rodaram uma VM.

O mecanismo se chama VSM — Virtual Secure Mode, baseado em VTLs (Virtual Trust Levels):

• VTL0 — o "mundo normal": Windows completo, kernel, drivers, aplicativos.
• VTL1 — o "mundo seguro": Secure Kernel + serviços críticos. O VTL0 não consegue ler nem escrever a memória do VTL1, porque a fronteira é imposta pelo hipervisor via SLAT.

Sobre essa base:

• HVCI (Hypervisor-Enforced Code Integrity) — o "Memory Integrity". O VTL1 decide quais páginas de código o kernel do VTL0 pode executar. Mesmo com kernel comprometido no VTL0, código não assinado não executa.
• Credential Guard — hashes NTLM e tickets Kerberos ficam no VTL1. Um comprometimento total do VTL0 não entrega as credenciais.
• HVPT (Hypervisor-enforced Paging Translation) — proteção mais recente das traduções GVA→GPA. Impede ataques de aliasing e remapping que tentam subverter proteções como Kernel Data Protection, Shadow Stacks e CFG. Ativo por padrão em Windows 11 24H2 e Windows Server 2025 em hardware compatível (Intel Alder Lake+ vPro, com VBS/HVCI).

Modelo mental. Antes da VBS, o kernel era o ponto mais privilegiado e mais confiável do sistema. Com a VBS, o hipervisor cria um cômodo trancado (VTL1) dentro do sistema, e nem o kernel tem a chave.

23. Shielded VMs e Host Guardian Service (HGS)

Shielded VMs são a proteção máxima contra o administrador de fabric malicioso ou comprometido. Elas:

• Criptografam o estado da VM (memória e saved state).
• Criptografam os discos virtuais.
• Impedem console, PowerShell Direct e certas Integration Components.
• Só rodam em hosts que passaram por attestation (medição de integridade do host).

O Host Guardian Service (HGS) é um papel separado (idealmente em cluster de 3 nós, em floresta dedicada) que fornece:

1. Attestation Service — verifica se o host atende à política de segurança (Secure Boot, TPM, CI policies, etc.).
2. Key Protection Service — só libera as chaves de descriptografia da VM para hosts atestados.

Diferença importante:

Shielded VMs exigem Geração 2 + Secure Boot + vTPM.

24. Confidential Computing e Isolated VMs

A evolução natural: tirar o host e o hipervisor do Trusted Computing Base (TCB) da VM.

Isolated VMs (também chamadas de Confidential VMs / CoCo VMs) usam:

• AMD SEV-SNP ou Intel TDX.
• Um paravisor (muitas vezes OpenHCL) que roda em um nível de confiança mais alto dentro da VM.
• Confidential VMBus — canal seguro entre o guest e o paravisor, sem passar pelo host não confiável.

Nesse modelo, o host Hyper-V tradicional continua existindo, mas a memória da VM é criptografada com chaves que o host não conhece. O hipervisor e a partição raiz veem apenas ciphertext. Isso é fundamentalmente diferente do VBS (que protege o host) e das Shielded VMs (que protegem a VM de um admin de fabric, mas ainda confiam no hipervisor).

O trabalho em open source (OpenVMM / OpenHCL e contribuições no kernel Linux) está tornando esse caminho cada vez mais transparente.

25. Nested virtualization, containers e WSL2

Nested virtualization permite rodar Hyper-V dentro de uma VM Hyper-V (expondo VT-x/AMD-V ao convidado). Essencial para WSL2 e containers com isolamento Hyper-V quando o Windows já está virtualizado.

Containers Windows com isolamento Hyper-V — cada container roda numa Utility VM minúscula e otimizada, com kernel próprio. Fronteira de segurança de VM com custo próximo de container. Mesma linhagem de ideia dos microVMs (Firecracker, Kata).

WSL2 — um kernel Linux real rodando numa Utility VM gerida pelo Hyper-V, com integração profunda de filesystem e rede. Habilitar WSL2 habilita componentes do Hyper-V sob o capô.

26. Hyper-V em ARM64

O binário é o hvaa64.exe, operando em EL2. Com VHE (Virtualization Host Extensions) o Windows da partição raiz pode rodar eficientemente em EL2. O modelo lógico continua idêntico: microkernel em EL2, partição raiz com drivers, VMBus/VSP/VSC, VTLs.

Limitações práticas: só Geração 2; convidados ARM64 (não x86).

27. Diferenças Client vs Server e threat model resumido

• Windows cliente usa Root Scheduler e tem restrições (DDA limitado ou ausente, menos recursos de cluster).
• Windows Server oferece o conjunto completo (Core Scheduler, Failover Clustering, Shielded VMs, GPU-P, etc.).

Threat model essencial:

• Comprometer uma VM filha → isolado pelo vmwp.exe + SLAT + IOMMU.
• Comprometer a partição raiz → afeta todas as VMs sintéticas (é o ponto único de falha operacional e de confiança para I/O).
• VBS/HVCI/Credential Guard reduzem o impacto de um kernel da raiz comprometido.
• Shielded VMs + HGS protegem a VM mesmo de um admin da raiz malicioso.
• Confidential Computing (SEV-SNP/TDX) tira a raiz e o hipervisor do TCB da VM.

Fecho: o mapa mental atualizado do Hyper-V

Se você guardar uma única imagem deste documento, guarde a inversão da primeira seção: o Hyper-V não é um programa que roda no Windows — é uma camada sob a qual o Windows roda. Todo o resto decorre disso.

Um microkernel minúsculo em ring -1 (ou EL2) detém o privilégio máximo e não faz nada além de escalonar CPU, mediar memória via SLAT e rotear mensagens. Acima dele, a partição raiz — um Windows completo rebaixado a convidado privilegiado — detém os drivers reais e a pilha de gestão (VID, VMMS, vmwp.exe, HCS, WMI/WHP). As partições filhas ganham hardware por três vias (emulado → sintético via VMBus/VSP/VSC → passthrough). O mesmo hipervisor que isola VMs foi reaproveitado para isolar o próprio host (VBS/VTLs/HVCI/HVPT), para proteger VMs de administradores maliciosos (Shielded VMs + HGS) e, no limite, para tirar o host e o hipervisor do TCB da carga de trabalho (Confidential Computing com SEV-SNP/TDX).

Quem vem do universo QEMU/KVM reconhece cada peça por tradução. O que muda é a filosofia de fundo — monolítico contra microkernelizado — e é dessa escolha que nascem tanto o custo (todo I/O sintético transita pela raiz) quanto a virtude que o KVM não replica de graça: um hipervisor pequeno o bastante para ser a raiz de confiança do próprio sistema e, em última instância, para sustentar os modelos de confiança mais fortes da indústria.