Como o KVM funciona internamente
O KVM converte o kernel Linux em um hipervisor Tipo-1 expondo um dispositivo de caractere /dev/kvm. Um processo de espaço de usuário (tipicamente o QEMU) abre esse dispositivo, pede ao kernel para criar uma CPU virtual e, em seguida, executa as instruções do guest diretamente na CPU física usando extensões de virtualização de hardware. O kernel lida com eventos privilegiados; tudo o mais executa em velocidade nativa.
Três componentes fazem o KVM funcionar. Primeiro, o módulo do kernel kvm.ko gerencia a virtualização de CPU e memória e expõe a interface /dev/kvm. Segundo, um módulo específico de arquitetura — kvm-intel.ko para Intel VT-x ou kvm-amd.ko para AMD-V — traduz entre a API genérica do KVM e as instruções de virtualização da CPU subjacente. Terceiro, um processo hipervisor de espaço de usuário, como QEMU, cloud-hypervisor ou Firecracker, fornece a emulação de dispositivos: discos virtuais, NICs, controladores USB e firmware BIOS ou UEFI. Como o próprio kernel Linux é o hipervisor, todo escalonador, gerenciador de memória e recurso de segurança do Linux se aplica às VMs da mesma forma que se aplica a processos nativos. Um guest KVM é simplesmente um processo pesado do ponto de vista do kernel, motivo pelo qual ferramentas como top, perf e cgroups funcionam nele sem modificação.
KVM vs OpenVZ vs VMware ESXi vs Hyper-V
O KVM oferece virtualização completa de hardware com um kernel guest separado para cada VM. O OpenVZ usa containerização em nível de SO, onde cada container compartilha o kernel host. O VMware ESXi é um hipervisor Tipo-1 bare metal proprietário com seu próprio kernel (VMkernel). O Hyper-V é o hipervisor Tipo-1 baseado em Windows da Microsoft. Apenas KVM, ESXi e Hyper-V oferecem um kernel guest realmente isolado.
OpenVZ (e seu sucessor Virtuozzo) é uma tecnologia de containers, não um hipervisor. Cada container OpenVZ compartilha o kernel Linux do host, o que significa que você não pode rodar uma versão diferente de kernel, não pode carregar módulos de kernel personalizados nem rodar um sistema operacional não Linux. O trade-off é a densidade: como não há overhead de kernel por VM, um host OpenVZ consegue acomodar mais containers no mesmo hardware, e por isso planos VPS compartilhados de baixo custo frequentemente o usavam. O VMware ESXi é o padrão empresarial para virtualização Tipo-1, mas é um produto de código fechado com licenciamento por socket que historicamente o tornava inviável para hospedagem VPS de mercado. O Hyper-V domina ambientes Windows Server e se integra fortemente com Active Directory e System Center, mas é menos comum em frotas de hospedagem com forte presença de Linux. O KVM se tornou o padrão para hospedagem VPS moderna porque é open source, está no mainline do kernel, suporta qualquer SO guest que rode em x86_64 ou aarch64 e tem um ecossistema de gerenciamento maduro (libvirt, oVirt, Proxmox, OpenStack Nova).
Por que o KVM é o padrão moderno para VPS
O KVM se tornou a tecnologia VPS dominante porque dá a cada cliente um kernel real e isolado sem pagar licenciamento estilo VMware. Suporta guests Linux, Windows, BSD e Solaris, roda em hardware comum x86_64 e ARM e está integrado em todas as principais stacks de orquestração em nuvem — OpenStack, Proxmox VE, Kubernetes via KubeVirt e o AWS Nitro são todos construídos sobre ele.
Três forças convergiram para tornar o KVM o padrão. Primeiro, as extensões de virtualização de hardware se tornaram universais: Intel VT-x foi lançado nos chips Core 2 em 2006 e AMD-V nos primeiros Athlon 64, então no início dos anos 2010 essencialmente toda CPU de servidor podia hospedar KVM em velocidade próxima à nativa. Segundo, a comunidade Linux recusou adotar a paravirtualização estilo Xen no mainline, mas adicionou o KVM ao mainline em 2007, dando instantaneamente a cada distribuição um hipervisor embutido. Terceiro, o ecossistema de nuvem pública investiu pesado: o Google Cloud Engine começou em KVM, a AWS migrou de Xen para uma arquitetura Nitro baseada em KVM e o OpenStack padronizou o KVM como hipervisor de referência. Provedores VPS menores se beneficiam dessa atração gravitacional porque as mesmas ferramentas que rodam frotas hyperscaler — libvirt, drivers virtio, cloud-init — também rodam em um único rack de servidores comuns.
Características reais de desempenho: CPU steal, I/O e overhead
Em um host KVM bem provisionado, espere overhead de CPU de um único dígito percentual versus bare metal, latência de rede submilissegundo adicionada a caminhos de rede local e 80-95% dos IOPS de disco nativos quando virtio-blk ou virtio-scsi é usado com driver paravirtualizado. CPU steal sustentado acima de 5% é o sinal canônico de overcommit do host e um forte indicador para upgrade.
Três números importam para um guest KVM em produção. O CPU steal time, exposto em /proc/stat como o oitavo campo, mede a porcentagem de tempo em que a CPU virtual estava pronta para executar mas a CPU física estava ocupada com outros guests. Qualquer valor abaixo de 1-2% é ruído normal de fundo; valores sustentados acima de 5% significam que o host está com overcommit e sua carga está sendo throttled. O IO wait, mostrado por ferramentas como iostat e top, mede a porcentagem de tempo em que a CPU ficou bloqueada em disco ou rede. Com drivers paravirtualizados virtio e armazenamento NVMe moderno, um IO wait sustentado acima de 20% em uma carga que deveria ser CPU-bound é um forte sinal de que o subsistema de disco está saturado. A taxa de rede em virtio-net deve atingir 80-95% da taxa de linha da NIC física; qualquer coisa significativamente abaixo aponta para um offload mal configurado ou um driver e1000 emulado antigo.
Quando NÃO usar KVM
O KVM é a escolha errada em três situações: cargas containerizadas de altíssima densidade onde o overhead de kernel por VM domina; implantações sensíveis ao licenciamento Windows onde o preço SPLA do Hyper-V é significativamente mais barato; e certos cenários de hardware passthrough de baixa latência onde SR-IOV ou GPU passthrough têm suporte ruim para seu modelo específico de NIC ou GPU.
Para microsserviços containerizados que não precisam de isolamento de kernel, containers Linux (Docker, Podman, Kubernetes) rodando diretamente no bare metal terão densidade 3-5x maior que qualquer VPS baseado em KVM, porque cada container é apenas um grupo de processos com namespaces e cgroups. Provedores VPS de baixo custo sensíveis à densidade historicamente escolheram OpenVZ pelo mesmo motivo. Implantações com forte presença de Windows — particularmente as que rodam licenças do Windows Server compradas via SPLA — às vezes pagam significativamente menos no Hyper-V do que no KVM por causa de como a Microsoft precifica licenças de guest em hipervisores concorrentes. Por fim, certos cenários de hardware passthrough ainda são dolorosos no KVM: GPU passthrough exige grupos IOMMU bem isolados, algumas NICs de consumo não têm suporte a SR-IOV e o passthrough PCIe de drives NVMe às vezes aciona workarounds para bugs de reset. Para 95% das cargas Linux VPS de uso geral, nada disso se aplica e o KVM é o padrão correto.
Como verificar se um VPS é realmente baseado em KVM
Dentro de um guest Linux, execute `systemd-detect-virt` — deve imprimir `kvm`. Confirme com `lscpu` (a linha 'Hypervisor vendor' deve dizer 'KVM') e `dmesg | grep -i kvm`. Se você vir 'OpenVZ', 'lxc' ou 'VMware', seu provedor está usando outra tecnologia, mesmo que o marketing afirme o contrário.
Antes de assinar um contrato, execute uma pequena bateria de diagnóstico em um VPS de teste. Execute `systemd-detect-virt` para a saída canônica de detecção. Execute `cat /proc/cpuinfo | grep -E 'vmx|svm'` para confirmar que as extensões de virtualização de hardware estão sendo passadas (alguns provedores as removem, quebrando a virtualização aninhada). Execute `uname -r` para verificar se você está vendo um kernel específico do guest, em vez de um kernel host compartilhado — em um VPS KVM real, você pode instalar um kernel diferente via `apt install linux-image-...` ou `dnf install kernel-...` e dar reboot nele. No OpenVZ, você não pode. Por fim, verifique `/proc/user_beancounters` — se esse arquivo existir, o host está rodando OpenVZ, não importa o que o marketing diga.