O que é KVM?

KVM expõe as extensões de virtualização da CPU através de um módulo de kernel; um modelo de dispositivo no espaço do usuário (QEMU, geralmente combinado com drivers paravirtualizados virtio para velocidade de disco e rede) monta o restante da máquina virtual. O guest inicializa seu próprio bootloader e kernel exatamente como hardware físico faria. O trabalho do host se resume a agendar vCPUs e mediar I/O — ele não interpreta as syscalls do guest, porque o guest tem seu próprio kernel para isso. Recursos de hardware também passam de forma útil: um guest KVM pode usar seu próprio iptables/nftables, carregar módulos do kernel, montar sistemas de arquivos e executar qualquer coisa que o hardware virtual suporte.

Contêineres compartilham o kernel do host. Isso os torna leves — overhead quase zero, inicialização rápida, empacotamento denso — e é precisamente o problema em um ambiente multi-inquilino:

• Isolamento. Um escape de contêiner está a um bug de kernel de distância, e cada inquilino compartilha a superfície de ataque desse único kernel. Um escape KVM deve cruzar uma barreira de VM imposta por hardware — uma classe de vulnerabilidade muito mais rara.
• Liberdade. Contêineres executam apenas o que o kernel do host permite: sem kernels personalizados, sem o módulo WireGuard que o host não carregou, sem FreeBSD, sem Windows, frequentemente sem Docker-em-contêiner. Um guest KVM executa WireGuard, Docker aninhado, sysctls personalizados, qualquer SO dos nossos dez templates.
• Recursos honestos. O histórico do OpenVZ está cheio de “burst RAM” sobrevendida e truques de contabilidade de kernel compartilhado. Memória KVM e vCPUs são alocadas para a VM; a sobresubscrição ainda é possível no nível do host, mas o contrato por guest é muito mais difícil de falsificar.

Contêineres são tecnologia excelente quando você controla o host (é para isso que serve o Docker, em cima do seu próprio VM). Como produto vendido a desconhecidos, o kernel compartilhado é um compromisso que usuários preocupados com privacidade deveriam recusar.

Três razões mantêm o KVM como padrão para hospedagem de privacidade. Recursos a nível de kernel: VPNs (WireGuard/OpenVPN), Tor com sysctls endurecidos, firewalls personalizados e criptografia de disco precisam de controle de kernel que um contêiner não pode oferecer. Isolamento mais forte de inquilinos: sua memória e processos estão atrás de uma barreira de hardware, não de um namespace, o que importa quando você não pode verificar seus vizinhos. Escolha de SO: virtualização completa executa Debian, Alpine, FreeBSD ou qualquer outra coisa — útil quando seu modelo de ameaça dita a pilha. Adicione criptografia de disco completo dentro do guest e a visibilidade do operador do host se reduz a texto cifrado e padrões de tráfego.

KVM nomeia o hipervisor, não a qualidade da implantação. Vale confirmar: tipo de armazenamento (KVM em discos giratórios ainda é lento — veja NVMe vs SSD); drivers virtio (o padrão de facto; sua ausência sinaliza uma pilha antiquada); política de vCPU dedicada vs compartilhada; e se o IP é dedicado e limpo. Todos os planos aqui são KVM em NVMe RAID10 com virtio, root completo e um IPv4 limpo dedicado — a ficha de dados declara isso de forma verificável.