KVM vs OpenVZ: qual virtualização escolher?

Resposta direta

Na comparação KVM vs OpenVZ, KVM costuma ser a escolha mais flexível para produção porque entrega uma máquina virtual com kernel próprio, isolamento mais forte e compatibilidade com diferentes sistemas operacionais. OpenVZ usa virtualização em nível de sistema operacional: os containers compartilham o kernel do host, consomem menos recursos e podem oferecer bom custo para aplicações Linux simples. Isso não torna todo KVM rápido nem todo OpenVZ inseguro. O resultado depende dos limites de CPU, memória, disco e rede aplicados pelo provedor, além da densidade do nó físico. Escolha KVM para Docker, módulos de kernel, VPN, bancos sensíveis e configurações personalizadas. Considere OpenVZ quando o workload for Linux convencional, previsível e compatível com as restrições documentadas pelo fornecedor.

Resumo rápido

• KVM virtualiza hardware e permite que cada VPS execute seu próprio kernel.
• OpenVZ isola containers Linux que compartilham o kernel do servidor físico.
• KVM oferece maior compatibilidade para Docker, VPN, firewalls e ajustes de sistema.
• OpenVZ tende a consumir menos memória no host e pode sustentar planos de menor custo.
• O desempenho depende mais de contenção, limites e hardware do que da tecnologia isoladamente.
• Backups, snapshots, swap e recursos de kernel precisam ser confirmados com o provedor.
• Uma avaliação séria deve incluir testes curtos de CPU, disco, memória e rede.

Como KVM e OpenVZ virtualizam uma VPS

KVM cria máquinas virtuais completas

KVM, sigla de Kernel-based Virtual Machine, transforma o kernel Linux do host em um hipervisor. Cada VPS recebe hardware virtual, como processadores, memória, controladoras de disco e interfaces de rede, e inicializa um sistema operacional com kernel próprio. O provedor pode usar QEMU para emulação de dispositivos e VirtIO para reduzir o custo de entrada e saída. Na prática, uma instância com 2 vCPUs e 4 GB de RAM enxerga esses recursos como se estivessem instalados em uma máquina independente, embora o hardware físico continue compartilhado.

Essa separação permite executar distribuições Linux com kernels diferentes e, quando o provedor oferece as imagens e licenças necessárias, outros sistemas operacionais. Também facilita personalizações como parâmetros de inicialização, criptografia dentro do guest e carregamento de módulos autorizados. Um servidor de VPN que depende de TUN/TAP, por exemplo, tende a encontrar menos restrições em KVM. Outro caso é uma aplicação que precisa testar um kernel LTS específico antes de atualizar a frota de produção.

OpenVZ compartilha o kernel do host

OpenVZ trabalha em nível de sistema operacional. Cada ambiente recebe processos, rede, filesystem e limites de recursos isolados, mas utiliza o mesmo kernel Linux do nó físico. Namespaces separam processos e recursos visíveis, enquanto mecanismos de controle limitam CPU, memória e entrada e saída. O modelo se aproxima de containers de sistema, não de uma máquina virtual completa.

O compartilhamento reduz duplicações. Dez containers não precisam manter dez kernels simultaneamente na memória, o que ajuda o provedor a alcançar maior densidade. Em contrapartida, o cliente não pode substituir livremente o kernel. Uma aplicação PHP, um servidor Nginx ou um pequeno banco MariaDB podem funcionar sem perceber essa diferença. Já um laboratório que precisa alterar módulos, testar eBPF específico ou instalar um firewall dependente de recursos não liberados pelo host pode encontrar bloqueios.

Antes de avaliar apenas KVM vs OpenVZ, também faz sentido entender a diferença entre VPS e Cloud Server. A tecnologia de virtualização descreve parte da arquitetura. Ela não informa, sozinha, se a instância possui armazenamento distribuído, recuperação automática em outro host ou capacidade de escalar recursos por API.

Desempenho de CPU, memória, disco e rede

O overhead raramente conta a história inteira

OpenVZ pode apresentar overhead baixo porque os processos usam diretamente o kernel compartilhado. KVM adiciona uma camada de virtualização, mas extensões de hardware como Intel VT-x, AMD-V e drivers VirtIO reduziram bastante esse custo. Em aplicações comuns, a diferença teórica pode ser menos relevante que a frequência do processador, o número de vizinhos no host e a política de limitação aplicada pelo provedor. Sem benchmark controlado e metodologia pública, não é correto afirmar que uma das tecnologias será sempre mais rápida.

Considere uma API Node.js com 2 vCPUs e 2 GB de RAM. Se o plano KVM entrega tempo de CPU consistente e o plano OpenVZ sofre contenção frequente, KVM pode responder melhor mesmo carregando uma pilha de virtualização mais completa. O inverso também ocorre. Um container OpenVZ em nó pouco ocupado pode executar um site institucional com excelente tempo de resposta e consumo reduzido.

Memória exige atenção especial. Em KVM, a VPS normalmente recebe uma quantidade definida, embora técnicas como ballooning possam existir. Em OpenVZ, limites, memória utilizável, cache e comportamento de swap dependem da implementação. Um plano anunciado com 4 GB não deve ser comparado apenas pelo número. É preciso perguntar se há memória garantida, burst, swap disponível e política para encerramento de processos quando o limite é atingido.

Limites e contenção importam mais que o nome

Disco costuma revelar problemas antes da CPU. Um WordPress com WooCommerce, 30 plugins e banco de 8 GB faz muitas leituras pequenas e gravações sincronizadas. Nesse cenário, latência, IOPS sustentadas e contenção no storage pesam mais que o rótulo KVM ou OpenVZ. SSD e NVMe também não garantem desempenho constante quando dezenas de instâncias disputam a mesma controladora.

Um teste com fio pode medir leitura aleatória, mas deve ser executado por poucos segundos e dentro das regras do fornecedor. Na rede, iperf3 para um endpoint autorizado ajuda a verificar vazão, enquanto ping e mtr mostram latência e perda de pacotes. Para dimensionar o plano, consulte também os critérios de escolha de CPU, RAM e NVMe. Uma aplicação com banco local pode precisar de 4 vCPUs, 8 GB de RAM e disco consistente, enquanto um proxy reverso pode operar bem com 1 vCPU e 1 GB.

Isolamento e segurança em ambientes reais

Fronteiras de isolamento

KVM coloca cada sistema convidado atrás de uma fronteira de máquina virtual. Os processos da VPS usam seu próprio kernel e interagem com dispositivos virtualizados. Se uma aplicação comprometer o kernel convidado, ainda será necessário atravessar a camada do hipervisor para alcançar o host. Isso amplia a separação entre clientes e torna KVM adequado para ambientes multiusuário, sistemas expostos à internet e cargas que executam código de terceiros.

OpenVZ separa containers por namespaces, permissões, capabilities e controles de recursos, mas todos dependem do kernel do host. Uma vulnerabilidade que permita escapar do isolamento pode ter impacto mais amplo. Isso não significa que qualquer VPS OpenVZ seja vulnerável por definição. Um host atualizado, com capabilities reduzidas, políticas de segurança e configuração cuidadosa pode proteger bem workloads convencionais. A diferença está na fronteira: em KVM, há kernels separados; em OpenVZ, a segurança depende mais diretamente da robustez do kernel compartilhado e das políticas do provedor.

Pense em três aplicações. Um blog de conteúdo administrado por uma única equipe tem uma superfície previsível. Um serviço de integração recebe arquivos de clientes e executa conversões com bibliotecas nativas. Uma plataforma de desenvolvimento permite que usuários rodem código enviado por eles. O primeiro caso pode funcionar em ambas as tecnologias. Os outros dois justificam isolamento mais forte, sandbox adicional e controles que costumam ser mais viáveis em KVM.

Atualizações e superfície de ataque

No OpenVZ, o provedor atualiza o kernel central. Isso reduz uma tarefa para o cliente, mas também limita seu controle sobre versão e cronograma. No KVM, a equipe precisa atualizar o kernel convidado, reiniciar quando necessário e acompanhar boletins da distribuição. Uma VPS esquecida durante meses continuará vulnerável mesmo que o hipervisor esteja atualizado.

A configuração básica deve incluir autenticação SSH por chave, bloqueio de login root direto, firewall, atualizações de segurança e monitoramento de tentativas de acesso. Em Ubuntu, ufw ou regras com nftables podem limitar portas. Um serviço web normalmente precisa expor 80 e 443, enquanto SSH pode ser restrito a IPs administrativos ou a uma VPN. Nunca coloque chaves privadas, tokens ou senhas em imagens públicas, scripts versionados ou comandos compartilhados.

A escolha entre uma operação interna e suporte especializado também afeta o risco. O artigo sobre VPS gerenciada ou não gerenciada ajuda a separar responsabilidade do provedor e responsabilidade do cliente. A virtualização protege fronteiras, mas não corrige WordPress desatualizado, senha fraca ou banco aberto para toda a internet.

Compatibilidade, kernel e operação diária

Recursos que dependem do kernel

KVM costuma oferecer maior liberdade porque o cliente controla o sistema convidado. Docker normalmente funciona nas duas tecnologias modernas quando o provedor habilita os recursos necessários, mas KVM evita várias dependências do kernel compartilhado. Em OpenVZ, overlay filesystems, cgroups, namespaces adicionais, iptables, WireGuard, FUSE e determinadas capabilities podem estar limitados. A resposta correta depende da versão da plataforma e da política aplicada ao container.

Um servidor de automação com Docker Compose, Postgres e Redis ilustra a diferença. Com KVM, uma configuração de 4 vCPUs, 8 GB de RAM e 100 GB de disco pode usar volumes, redes bridge e regras próprias de firewall com poucas surpresas. Em OpenVZ, o mesmo conjunto pode funcionar, mas deve ser validado antes da compra. Se o provedor bloquear nesting ou um módulo necessário, a aplicação exigirá adaptação ou não iniciará.

Outro exemplo é uma VPN WireGuard. KVM permite instalar um kernel compatível ou usar o módulo já fornecido pela distribuição. Em OpenVZ, o módulo pertence ao kernel do host, então sua disponibilidade depende do operador. Um ambiente de observabilidade que coleta eventos com eBPF enfrenta restrição semelhante. Para Nginx, PHP-FPM, Python, Node.js e bancos comuns, a dependência costuma ser menor, desde que os limites de recursos sejam claros.

Backup, snapshot e recuperação

A tecnologia também influencia as ferramentas de operação, mas não determina sozinha o produto comercial. KVM facilita snapshots de discos virtuais e imagens completas da máquina. OpenVZ pode gerar backups eficientes de containers e filesystems. Ainda assim, snapshot não é sinônimo de backup. Se a cópia permanecer no mesmo storage ou na mesma conta, uma falha de hardware, exclusão acidental ou comprometimento administrativo pode atingir original e snapshot.

Para uma aplicação com banco PostgreSQL, combine backup lógico diário, cópia externa e teste de restauração. Um exemplo simples é manter sete cópias diárias, quatro semanais e três mensais em armazenamento separado. O tempo de recuperação também deve ser medido. Restaurar 200 GB por uma conexão de 200 Mbps pode levar mais de duas horas em condições ideais, sem contar validação e reinicialização.

Pergunte ao provedor se snapshots são consistentes com a aplicação, quanto tempo a restauração leva e se existe exportação para outra plataforma. Recursos, limites e cobrança variam por plano. Nenhuma oferta deve ser presumida apenas porque a VPS usa KVM ou OpenVZ.

Custo, densidade e comparação prática

Por que OpenVZ pode custar menos

O compartilhamento do kernel reduz consumo duplicado e permite maior densidade por nó. Isso ajuda a explicar por que ofertas OpenVZ podem aparecer em faixas econômicas. O custo menor, porém, não informa quanta CPU estará disponível durante picos, qual é a latência do disco ou quantos containers dividem o servidor. Da mesma forma, pagar mais por KVM não garante recursos físicos exclusivos. vCPUs ainda podem ser compartilhadas, e o provedor pode aplicar oversubscription.

Uma VPS de entrada para DNS secundário, proxy pequeno ou ambiente de homologação pode aproveitar bem OpenVZ. Esses serviços consomem pouca memória, fazem poucas gravações e toleram alguma variação. Já um banco transacional, uma loja em horário de campanha ou uma fila que processa milhares de tarefas por hora precisa de previsibilidade. Nesses casos, KVM é geralmente a base mais segura, mas a decisão ainda depende de métricas do plano e do fornecedor.

Critério ou perfil	KVM	OpenVZ	Verificação necessária
Kernel e sistema operacional	Kernel próprio, com ampla escolha de imagens	Kernel Linux compartilhado com o host	Versões, imagens e política de atualização
Isolamento entre clientes	Fronteira de máquina virtual	Fronteira de container e namespaces	Hardening, versão da plataforma e histórico operacional
Docker e recursos avançados	Compatibilidade normalmente mais ampla	Pode depender de nesting e capabilities liberadas	OverlayFS, cgroups, TUN/TAP, FUSE e módulos
Memória e swap	Alocação da VM, sujeita à política do hipervisor	Limites definidos pelo host e implementação	RAM garantida, burst, swap e ação em caso de excesso
Workload típico	Banco, SaaS, VPN, CI, containers e produção	Site Linux simples, proxy, homologação e serviço leve	Teste do software real antes da migração
Estrutura de custo	Pode exigir mais memória e capacidade no host	Maior densidade pode reduzir o custo	Renovação, tráfego, backup e licenças

O que confirmar antes da contratação

Peça respostas objetivas: qual tecnologia e versão são usadas, se a CPU é compartilhada ou dedicada, como o disco é limitado, qual o volume de tráfego incluído e o que acontece ao exceder RAM. Confirme também localização do datacenter, política de uso aceitável, janela de manutenção e processo de recuperação. Preço, bandwidth, storage e regiões são dados voláteis e precisam de revisão na página oficial na data da compra.

Provedores diferentes podem usar KVM com políticas completamente distintas. Outros podem comercializar containers sem exibir OpenVZ no nome do plano. Não compare apenas logotipos ou uma tabela de RAM. Compare a arquitetura que será entregue, os limites documentados e a qualidade operacional observada durante um teste de curta duração.

Como testar a virtualização antes da migração

Identificação e inventário

Comece identificando o ambiente. O comando systemd-detect-virt costuma retornar valores como kvm, openvz, qemu ou none. hostnamectl também pode exibir a virtualização detectada. Essas ferramentas não são infalíveis quando o provedor mascara informações, então compare o resultado com a documentação e abra um chamado se houver divergência. Não execute scripts desconhecidos como root apenas para descobrir o hipervisor.

Depois, faça um inventário das dependências. Registre distribuição, versão do kernel, serviços ativos, portas, módulos, regras de firewall, jobs agendados e volume dos dados. Em um servidor Docker, anote a versão do engine, driver de storage e volumes persistentes. Em um banco, meça o tamanho, a taxa de crescimento e o pico de conexões. Uma migração de 40 GB é muito diferente de mover 800 GB com janela de indisponibilidade de vinte minutos.

Três verificações rápidas evitam surpresas. Use uname -r para conferir o kernel, free -h para observar memória e swap, e df -hT para identificar espaço e filesystem. Para CPU, lscpu mostra quantidade de vCPUs e recursos expostos. Esses comandos não comprovam desempenho garantido, mas revelam incompatibilidades e diferenças entre a oferta e o sistema entregue.

Teste controlado do workload

Crie uma instância temporária com tamanho semelhante ao pretendido e instale uma cópia sanitizada da aplicação. Não use dados pessoais reais sem proteção. Reproduza operações representativas: importação de mil produtos no WooCommerce, processamento de dez mil jobs, compilação de uma imagem Docker ou execução de consultas sobre uma base restaurada.

Colete latência p95, uso de CPU, memória máxima, espera de disco e erros por pelo menos 24 horas. vmstat 1, iostat -xz 1 e métricas da aplicação ajudam a separar gargalos. Se a CPU aparece ociosa enquanto o tempo de espera de entrada e saída cresce, aumentar vCPUs provavelmente não resolverá. Se processos são encerrados quando o uso se aproxima do limite, investigue política de memória e logs do sistema.

Faça também um ensaio de falha. Reinicie a VPS, restaure um backup em uma instância vazia e valide DNS, certificados e permissões. Para uma API, rode testes com 20, 50 e 100 conexões simultâneas, sempre dentro dos limites do provedor. O objetivo não é publicar um ranking universal. É descobrir se aquela combinação de tecnologia, plano, região e operação atende ao seu workload.

Recomendações por perfil

A escolha final deve combinar compatibilidade, risco operacional e orçamento. KVM tende a ser a recomendação padrão quando existem dúvidas sobre recursos do kernel. OpenVZ continua válido quando a aplicação é compatível, os limites são transparentes e a economia compensa as restrições.

Desenvolvedor solo e projetos pequenos

Para um desenvolvedor que mantém portfólio, blog, bot ou API de baixo tráfego, OpenVZ pode atender com 1 ou 2 vCPUs, 1 a 2 GB de RAM e 20 a 40 GB de SSD. O projeto deve usar uma distribuição Linux suportada e evitar dependências incomuns de kernel. Confirme Docker, swap, TUN/TAP e firewall antes de contratar. Se a diferença de custo for pequena, KVM oferece espaço para experimentar ferramentas e mudar a arquitetura depois. Reserve parte do orçamento para backup externo. Um servidor barato sem restauração testada pode sair caro após uma exclusão ou atualização malsucedida.

Times de desenvolvimento e agências

Times que hospedam vários clientes, ambientes de staging ou pipelines de integração se beneficiam da flexibilidade de KVM. Uma base razoável é 4 vCPUs, 8 GB de RAM e 100 GB de armazenamento, ajustada após medir os projetos. Docker, runners de CI e bancos concorrendo pela mesma memória criam picos difíceis de acomodar em limites pouco claros. Separe clientes críticos, aplique quotas e monitore CPU steal, espera de disco e uso de memória. OpenVZ ainda pode servir para homologações leves ou sites padronizados, desde que a equipe conheça as restrições e consiga migrar rapidamente se uma dependência mudar.

Produção crítica e workloads complexos

Para SaaS, e-commerce, banco transacional, VPN, processamento de filas ou execução de código de terceiros, KVM é normalmente a opção mais prudente. Procure recursos consistentes, políticas documentadas, backup externo e recuperação testada. Um ponto inicial para uma aplicação média pode ser 4 a 8 vCPUs, 8 a 16 GB de RAM e 160 GB de SSD ou NVMe, mas esses números não substituem métricas. Separe banco e aplicação quando contenção ou manutenção justificarem. Se disponibilidade for crítica, uma única VPS continua sendo ponto único de falha, independentemente do hipervisor. Nesse caso, avalie replicação, balanceamento, observabilidade e uma arquitetura capaz de sobreviver à perda completa da instância.