O hypervisor é o software que cria e gerencia máquinas virtuais, fazendo a mediação entre as VMs e o hardware físico. A distinção entre Type 1 e Type 2 define onde esse software reside na pilha: diretamente no hardware (bare metal) ou sobre um sistema operacional já instalado (hosted). Essa diferença de posição tem impacto direto em performance, segurança e uso adequado.
O que é um hypervisor e por que a posição dele importa
Para entender a diferença entre os tipos, você precisa entender o que o hypervisor faz. Ele senta entre o hardware físico e as máquinas virtuais, interceptando todas as operações que as VMs tentam executar no hardware — acesso à CPU, leitura de disco, escrita em memória, chamadas de rede — e as gerencia de forma controlada e isolada.
Agora, pense no seguinte: se existe um sistema operacional convencional entre o hypervisor e o hardware, toda operação de uma VM precisa passar por mais uma camada antes de chegar ao metal. Isso é exatamente o que diferencia os dois tipos — e é por isso que a posição importa.
Hypervisor Type 1 — o bare metal que roda produção
O hypervisor Type 1 é instalado diretamente sobre o hardware físico, sem nenhum sistema operacional como intermediário. Ele é, na prática, o próprio “sistema operacional” do servidor — mas um SO mínimo e especializado, projetado exclusivamente para gerenciar VMs.
Os exemplos mais conhecidos são VMware ESXi, Microsoft Hyper-V (quando instalado como Hyper-V Server), e KVM integrado ao kernel Linux. Em todos esses casos, o hardware é entregue ao hypervisor sem intermediários. As VMs acessam os recursos físicos com o menor overhead possível.
O resultado é performance previsível e segurança melhor. Como não há um SO hospedeiro generalista com seus próprios processos, drivers e vulnerabilidades rodando entre as VMs e o hardware, a superfície de ataque é menor. Se um SO hospedeiro fosse comprometido num setup Type 2, todas as VMs estariam em risco. No Type 1, esse vetor não existe da mesma forma.
Ambientes de produção usam exclusivamente Type 1. Datacenters, clouds privadas, clouds públicas — tudo roda sobre hypervisors bare metal. Não existe exceção razoável para isso.
Hypervisor Type 2 — o hosted para dev e labs
O hypervisor Type 2 roda como um aplicativo normal sobre um sistema operacional já instalado. VirtualBox rodando no seu macOS ou Windows, VMware Workstation Pro no seu notebook Linux — esses são exemplos clássicos de Type 2.
A vantagem é óbvia: você não precisa de um servidor dedicado. Qualquer máquina com recursos suficientes pode rodar VMs de desenvolvimento, laboratórios, testes locais e ambientes de treinamento. O setup é trivial — instala o software como qualquer aplicação, cria uma VM, pronto.
O custo dessa conveniência é camadas adicionais. Quando uma VM no VirtualBox faz uma operação de disco, essa operação passa pelo VirtualBox, depois pelo SO hospedeiro (com seu próprio scheduler e sistema de I/O), e só então chega ao hardware. Isso introduz latência e variabilidade que são aceitáveis para desenvolvimento mas completamente inadequadas para produção.
Há também o problema de competição de recursos: o SO hospedeiro está rodando ao mesmo tempo que as VMs, consumindo CPU, memória e I/O para seus próprios processos. Em produção, esses recursos desperdiçados são inaceitáveis.
O caso especial do KVM — Type 1 ou Type 2?
Aqui é onde a taxonomia clássica fica imprecisa, e vale a pena ser honesto sobre isso.
O KVM (Kernel-based Virtual Machine) é tecnicamente um módulo do kernel Linux. Você precisa de um Linux instalado para usá-lo — o que, na definição estrita, o colocaria na categoria Type 2. Mas na prática, o KVM se comporta como um hypervisor Type 1 em todos os aspectos que importam.
Quando você instala um servidor Linux com KVM em produção, o Linux não está rodando como um SO de propósito geral servindo usuários — ele existe para hospedar o hypervisor. O kernel Linux com KVM tem acesso direto ao hardware via extensões de virtualização da CPU (Intel VT-x, AMD-V), e o overhead é mínimo, comparável ao ESXi. AWS, Google Cloud e a plataforma ACS da Adentro todos rodam sobre KVM em produção — não existe questionamento razoável sobre a capacidade do KVM em ambiente bare metal.
A classificação correta, aceita pela maioria dos arquitetos de TI, é: KVM se comporta como Type 1 em produção, mesmo que sua arquitetura técnica o coloque numa categoria híbrida.
Comparativo direto
| Característica | Type 1 (Bare Metal) | Type 2 (Hosted) |
|---|---|---|
| Roda sobre | Hardware diretamente | Sistema operacional |
| Overhead de performance | Mínimo (2–10%) | Maior (variável) |
| Caso de uso principal | Produção, datacenters | Dev, labs, testes |
| Exemplos | VMware ESXi, KVM, Hyper-V | VirtualBox, VMware Workstation |
| Superfície de ataque | Menor | Maior (SO hospedeiro é vetor) |
| Custo de setup | Servidor dedicado necessário | Qualquer PC/notebook |
| Suporte a clustering | Sim (nativo) | Limitado ou inexistente |
| Live migration de VMs | Sim | Não (na maioria) |
Quando usar cada um
A resposta é quase sempre óbvia se você pensar no contexto:
Se é produção — qualquer workload que usuários reais dependem — use Type 1. Não existe razão para usar Type 2 em produção, e tentar fazer isso é criar problemas desnecessários de performance, disponibilidade e segurança.
Se é desenvolvimento local, laboratório de estudos, testes de compatibilidade, ou você quer rodar um Linux dentro do seu macOS para experimentar uma distribuição — use Type 2. VirtualBox gratuito faz o trabalho perfeitamente. VMware Workstation Pro oferece mais recursos se você precisar.
A confusão acontece quando empresas menores tentam rodar produção em Type 2 por comodidade ou desconhecimento. Um servidor Windows com VirtualBox rodando VMs de produção é um antipadrão que você vai lamentar na primeira vez que o Windows hospedeiro precisar de reboot ou travar com um BSOD.
A plataforma ACS da Adentro usa KVM como hypervisor Type 1, com Apache CloudStack como camada de orquestração. Conheça a Cloud Privada Adentro.