Dois planos de VPS, a mesma página. Quatro vCPU, 8 GB de RAM, 160 GB de armazenamento, preço quase idêntico. Um diz KVM. O outro diz OpenVZ. Nenhuma das páginas explica o que essa palavra muda.
Muda o que você tem permissão para executar. Os tipos de virtualização de VPS não são apenas uma nota de rodapé sobre desempenho. Eles decidem se você controla o kernel, se o Windows é possível e se o Docker funciona sem ajuda do provedor. KVM vs. OpenVZ vs. LXC é uma questão de capacidade antes de ser uma questão de velocidade.
Este guia cobre os três rótulos mais relevantes para esta decisão de compra. Xen, VMware, Hyper-V e outras plataformas de virtualização existem, mas estão fora desta comparação de três vias.
TL;DR
- KVM dá a cada VPS o seu próprio kernel convidado. O Docker funciona normalmente, o Windows é tecnicamente possível e geralmente você pode carregar módulos do kernel ou iniciar um kernel personalizado. No entanto, o KVM por si só não garante CPU ou RAM dedicadas; os compromissos de recursos continuam dependendo do provedor e do plano.
- OpenVZ os planos de VPS são normalmente contêineres Linux que compartilham o kernel do host. O Docker só pode rodar no OpenVZ 7 quando o provedor usa um kernel e uma configuração de template compatíveis. Você não pode substituir o kernel do host, e a memória além da RAM é tratada por VSwap controlado pelo provedor, e não pelo swap de disco comum gerenciado pelo convidado.
- LXC também compartilha o kernel do host, mas é construído em torno dos recursos de contenção do Linux mainline. O Docker pode rodar quando o host habilita os recursos necessários, embora o Proxmox recomende aninhar contêineres dentro de uma máquina virtual QEMU para cargas que exigem isolamento máximo e migração ao vivo.
- Contêineres costumam ser mais fáceis de redimensionar em execução. O KVM também pode oferecer hot-plug de CPU e memória, então "KVM sempre exige reinicialização" não é uma regra de compra segura. Pergunte ao provedor o que a plataforma dele realmente suporta.
- Para um site estático ou uma pequena stack LAMP que nunca precisa de Docker, Windows ou personalização em nível de kernel, a diferença prática pode ser pequena. Isolamento, ciclo de vida e política de recursos ainda podem variar.
A única diferença que causa todas as outras
O KVM dá a cada VPS do host o seu próprio kernel convidado. Os contêineres OpenVZ e LXC usam o kernel iniciado pelo host.
O KVM é uma solução de virtualização completa para hardware x86 com extensões de virtualização. Ele foi integrado ao kernel Linux mainline a partir da versão 2.6.20. Cada convidado enxerga hardware virtual e inicia o próprio sistema operacional e o próprio kernel.
Os tipos de contêiner funcionam de outra forma. O LXC é uma interface de espaço de usuário para os recursos de contenção do kernel Linux, incluindo namespaces, cgroups, capabilities, seccomp e perfis de segurança. O objetivo é oferecer um ambiente próximo de uma instalação Linux normal sem iniciar um kernel separado.
Um contêiner OpenVZ segue o mesmo modelo geral de kernel compartilhado, embora o OpenVZ use a própria plataforma e a própria pilha de kernel. O OpenVZ 7 pode gerenciar tanto contêineres quanto máquinas virtuais KVM, mas quando um plano de VPS de varejo é rotulado como "OpenVZ", o produto normalmente vendido é o tipo contêiner.
Todas as diferenças de capacidade abaixo decorrem disso. Um módulo do kernel precisa ser carregado em um kernel que você controla. Um sistema operacional diferente precisa de um kernel diferente. O Docker precisa de namespaces em nível de kernel, que devem estar disponíveis onde o próprio kernel reside. Do lado do KVM dessa fronteira, a camada do hipervisor segue uma arquitetura comumente dividida em hipervisores de Tipo 1 e de Tipo 2.
O LXC aparece com frequência em ambientes Proxmox, incluindo servidores autogerenciados e algumas plataformas de hospedagem. Se você pode habilitar recursos avançados do LXC depende de quem controla esse host.
O que cada tipo permite executar
Os eixos que definem a compra são o controle do kernel, o suporte ao sistema operacional convidado, a compatibilidade com Docker, o comportamento da memória, o redimensionamento e a política de recursos.
| Capacidade | KVM | OpenVZ | LXC |
|---|---|---|---|
| Docker | Sim, nativamente | Condicional: apenas OpenVZ 7, e o provedor precisa usar um template EZ ou um template personalizado adequado, além dos recursos de kernel exigidos no host | Condicional: o host precisa habilitar o aninhamento e keyctl |
| Kernel personalizado ou módulos carregáveis | Geralmente sim | Não, preso ao kernel do host | Não, compartilha o kernel do host |
| Windows como SO convidado | Sim, quando o provedor oferece suporte à imagem e ao caminho de licenciamento | Não, apenas Linux | Não, apenas Linux |
| Módulos de kernel para VPN (WireGuard, OpenVPN) | Controlado pelo convidado | Depende do provedor: TUN/TAP precisa estar exposto | Depende do provedor: depende dos recursos de kernel habilitados no host |
| Controle do swap | Controlado pelo convidado | VSwap gerenciado pelo host em vez do swap de disco comum | Política do host, cgroup v2 moderno |
| Redimensionar recursos ao vivo, sem reiniciar | Depende da plataforma; o hot-plug de CPU e memória é possível | Frequentemente possível | Frequentemente possível |
| Garantia de recursos dedicados | Não é inerente; a política do provedor decide | Não é inerente, e a densidade de contêineres facilita a supervenda | Não é inerente |
Qual você deve escolher? O KVM é a resposta mais direta quando você precisa de Windows, de um kernel personalizado, de módulos carregados pelo convidado ou de um host Docker previsível. OpenVZ e LXC podem ser ambientes Linux eficientes, mas deixam as decisões em nível de kernel com o provedor.
Isto é um mapa de capacidades, não um benchmark. Ele não diz nada sobre latência de armazenamento, qualidade de rede, geração de CPU, ocupação do host ou política de alocação de recursos do provedor. Dois provedores usando o mesmo tipo de virtualização podem entregar máquinas muito diferentes.
É nas células condicionais que os compradores perdem tempo. Certa vez implantei uma VPN em um VPS em contêiner onde o recurso de rede exigido do lado do host não estava exposto. A interface não subia, e a correção exigiu um chamado ao suporte em vez de uma mudança de configuração dentro do convidado. Com um plano em contêiner, pergunte se o provedor expõe exatamente o dispositivo ou o recurso de kernel de que a sua VPN precisa. Com KVM, você normalmente controla isso dentro do convidado.
Por que o Docker é a pergunta que decide a maioria das compras
VPS em contêiner contra VPS KVM deixa de ser uma comparação abstrata no momento em que o Docker aparece nos seus requisitos. O próprio Docker usa namespaces do kernel, cgroups, rede e drivers de armazenamento. Dentro do KVM, esses recursos pertencem ao kernel convidado que você controla. Dentro do OpenVZ ou LXC, eles dependem, em última instância, do host.
Docker no OpenVZ
O suporte a Docker no OpenVZ é uma decisão de provisionamento tomada acima de você. Um artigo de suporte da SolusVM afirma que o Docker pode rodar dentro do OpenVZ 7 a partir de uma versão específica do kernel 3.10, mas também diz que o Docker não funciona com os templates pré-criados legados padrão. O contêiner precisa usar um template EZ ou um template personalizado adequado. Esse mesmo artigo exclui convidados CentOS 8.
Então, o Docker funciona no OpenVZ? Às vezes. O provedor precisa ter construído o serviço em torno de um kernel OpenVZ 7 compatível e de um caminho de templates adequado. Se a página do plano não deixar isso claro, pergunte ao suporte antes de comprar e guarde a resposta por escrito.
Quando a configuração do host é incompatível, mudar flags do Docker dentro do VPS não resolve o problema de fundo. É preciso que o provedor altere a configuração do contêiner ou mova você para outro tipo de virtualização.
Docker no LXC
O Docker pode rodar dentro do LXC quando o host expõe os recursos necessários. No Proxmox, isso normalmente inclui o aninhamento de contêineres e keyctl para contêineres sem privilégios.
O sinal de compra mais importante é a recomendação de quem mantém a plataforma. A documentação do Proxmox diz que aninhar contêineres dentro de uma VM QEMU do Proxmox continua sendo uma prática recomendada para casos de uso que exigem isolamento máximo e migração ao vivo, em vez de executá-los diretamente em um contêiner de sistema LXC.
Se você controla o host LXC, pode avaliar esse compromisso e testar atualizações no seu próprio ritmo. Se está alugando um VPS LXC, o provedor controla o kernel, o perfil de segurança e os flags de recursos avançados. Confirme a configuração suportada em vez de presumir que acesso root dentro do contêiner é suficiente.
Docker no KVM
O Docker funciona normalmente porque o convidado Linux controla o próprio ambiente de kernel. Não há chave de aninhamento LXC nem exigência de template OpenVZ acima do convidado. Você ainda precisa de uma distribuição Linux compatível, um kernel compatível e RAM e armazenamento suficientes para a carga de trabalho.
Ter o kernel convidado também significa mantê-lo. Em um VPS não gerenciado, atualizações, regras de firewall, segurança do Docker e backups continuam sendo responsabilidade sua.
Ponto-chave: O Docker não torna o OpenVZ ou o LXC impossíveis, mas transforma a configuração do provedor em parte da confiabilidade da sua aplicação. Para um host Docker de produção alugado, o KVM elimina essa dependência extra.
Se "4 vCPU" significa quatro núcleos de CPU dedicados
Um VPS que parece lento enquanto o próprio monitoramento mostra a CPU ociosa é o sintoma que as pessoas mais descrevem. A virtualização por contêineres é o que torna isso possível. A disputa acontece uma camada abaixo do que o convidado consegue enxergar, então as métricas dele não mostram nada de errado.
O mecanismo é o próprio baixo overhead. Um contêiner custa ao host muito menos do que uma máquina virtual completa, então cabem mais contêineres no mesmo hardware. Essa densidade é barata de criar e difícil de detectar de dentro do convidado, o que torna a supervenda estruturalmente mais fácil no OpenVZ do que no KVM. O KVM não impede que um provedor lote um host. Mas ele compromete memória real e fatias reais de CPU por convidado, o que impõe um teto aritmético a quanto dá para lotar. O lado do diagnóstico tem um guia próprio sobre como saber se o seu provedor está fazendo supervenda.
A memória também se comporta de outra forma. No OpenVZ você não pode usar o swap de disco como memória adicional, então o número de RAM na página do plano é uma parede, não uma rampa. Um convidado KVM sob pressão de memória fica mais lento. Um contêiner OpenVZ sob pressão de memória tem processos mortos.
Há também uma consequência de isolamento, e é a que as pessoas mais subestimam. A memória de um contêiner é endereçável a partir do host de um jeito que a de um convidado KVM não é. A criptografia de disco dentro do convidado ainda protege você contra um disco roubado. Ela não protege as chaves de um contêiner em execução da máquina que o está executando. Se o seu modelo de ameaças inclui o operador do host, um kernel compartilhado é o substrato errado. Nenhuma configuração dentro do convidado muda isso.
Ponto-chave: o mesmo número na página de um plano é um tipo de promessa diferente conforme a tecnologia. No KVM é uma alocação. No OpenVZ é um teto que você compartilha.
Onde o OpenVZ ainda faz sentido e para onde ele está indo
Se você roda um site estático ou uma stack LAMP de baixo tráfego, talvez nunca esbarre nas capacidades que o OpenVZ restringe. Nada de Windows, nem kernel personalizado, nem módulos carregados pelo convidado, nem Docker em produção. Para essa carga de trabalho estreita, um contêiner OpenVZ bem operado ainda dá conta.
O ciclo de vida exige mais atenção do que há uma década. O OpenVZ 7 é baseado no ramo de kernel do RHEL 7, versão 3.10. O número da versão sozinho não prova que um kernel corporativo mantido esteja sem correções de segurança, porque os fornecedores fazem backport de patches. Mas significa que você deve verificar a compatibilidade com software que espera interfaces de kernel mais novas.
The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the política oficial de ciclo de vida.
Isso não quebra hoje um site OpenVZ que funciona. Mas torna relevante o plano de migração do provedor antes de você comprometer uma nova carga de trabalho de longa duração. Pergunte qual versão do OpenVZ ou Virtuozzo está rodando, como as correções de segurança são entregues e qual caminho de migração existe.
Quando a página de um plano não nomeia o tipo de virtualização, pergunte ao suporte em vez de deduzir pelo preço. Vale a pena ter a resposta por escrito.
Escolher pela carga de trabalho
Comece pelo requisito, não pela tecnologia.
Escolha KVM quando a carga de trabalho precisar do próprio kernel
O KVM é a escolha direta quando você precisa de qualquer um destes itens:
- Windows como sistema operacional convidado
- Um kernel personalizado
- Módulos de kernel carregados pelo convidado
- Docker em produção sem dependências de contêiner dentro de contêiner
- Virtualização aninhada, quando o provedor a disponibiliza
- Swap e ajuste de kernel controlados pelo convidado
O Windows é decisivo porque tanto os contêineres OpenVZ quanto os LXC usam um kernel de host Linux. Escolher entre Linux e Windows para a aplicação em si é outra questão, que envolve compatibilidade de software, administração e licenciamento. Veja a comparação entre VPS Linux e Windows para essa decisão.
Escolha LXC quando quiser um contêiner de sistema Linux eficiente
O LXC é racional quando a carga de trabalho é só Linux, não precisa de um kernel separado e se beneficia de baixo overhead ou de mudanças rápidas gerenciadas pelo host. É especialmente útil quando você mesmo controla o host Proxmox ou LXC.
Para um VPS LXC alugado, verifique o suporte a Docker, os dispositivos necessários, o modo de segurança, o comportamento dos backups e se recursos avançados podem ser habilitados.
Considere o OpenVZ para uma carga Linux simples e verificada
O OpenVZ ainda pode ser aceitável para um site básico, uma pequena stack LAMP, um serviço de DNS ou uma carga Linux igualmente convencional, quando:
- O provedor documenta a versão da plataforma.
- Seu software é compatível com o ambiente de kernel disponível.
- Você não precisa de Windows nem de personalização do kernel.
- O Docker é dispensável ou explicitamente suportado.
- O provedor tem um plano crível de segurança e migração.
- O preço ou o modelo operacional lhe dá um motivo real para escolhê-lo.
Não o escolha só porque uma comparação antiga diz que o OpenVZ é sempre mais barato. Compare o plano atual, o suporte, a política de recursos e as opções de migração.
Se a sua resposta caiu no KVM, é a restrição que está decidindo, não uma preferência. O VPS KVM da Cloudzy inicia em 60 segundos em AMD EPYC com NVMe puro, e cada instância recebe o próprio kernel convidado. Módulos de kernel carregam, kernels personalizados iniciam, e há suporte a convidados Linux e Windows. O Docker está no marketplace se você preferir não instalá-lo por conta própria.
Perguntas frequentes
Posso rodar Docker em um VPS OpenVZ?
Apenas se o provedor tiver configurado um ambiente OpenVZ 7 compatível. A SolusVM documenta suporte em kernels OpenVZ 7 suficientemente recentes com templates EZ ou personalizados adequados, enquanto os templates legados padrão não funcionam. Trate o Docker como não suportado até o provedor confirmar a configuração exata.
O OpenVZ pode rodar Windows?
Não, não como contêiner OpenVZ. O contêiner compartilha o kernel Linux do host. O KVM consegue rodar um convidado Windows porque a máquina virtual inicia o próprio kernel de sistema operacional, embora o provedor ainda precise dar suporte à imagem, à ISO e ao caminho de licenciamento.
O LXC é a mesma coisa que o Docker?
Não. O LXC é comumente usado para contêineres de sistema que se parecem com máquinas Linux leves, com sistema de init e vários processos. O Docker é uma plataforma de contêineres de aplicação construída em torno de imagens e serviços individuais. Ambos usam recursos do kernel Linux, como namespaces e cgroups, e é por isso que os termos às vezes se confundem.
O que é um VPS LXC?
Um VPS LXC é um contêiner de sistema Linux hospedado via LXC ou uma plataforma baseada em LXC, como o Proxmox. Ele se parece e se comporta muito como um pequeno servidor Linux, mas compartilha o kernel do host em vez de iniciar o próprio. Isso o torna leve e, ao mesmo tempo, limita o controle em nível de kernel.
Como descubro qual tipo de virtualização um provedor usa?
Verifique a página do plano ou pergunte ao suporte. Dentro de uma instância Linux, este comando muitas vezes identifica o ambiente:
systemd-detect-virtEle pode retornar valores como kvm, openvz, ou lxc. A detecção de dentro do convidado é útil, mas a especificação escrita do provedor continua sendo a melhor fonte antes da compra.
O KVM garante CPU e RAM dedicadas?
Não. O KVM suporta overcommit de CPU e memória. Um provedor pode oferecer recursos reservados, compartilhados ou uma mistura dos dois. Procure formulações explícitas como RAM dedicada, CPU fixada, vCPU reservada ou sem overcommit, em vez de presumir que o hipervisor garante isso.
O KVM é sempre a melhor escolha?
Não. O KVM é a única escolha para Docker, kernels personalizados e Windows, mas para uma carga de trabalho que nunca encosta em nada disso a diferença prática é quase invisível.
Discussão
Comentários
Inicie sessão para participar na discussão.