O Proxmox é uma das poucas plataformas que entrega, no mesmo painel, duas tecnologias de virtualização diferentes: máquinas virtuais completas com KVM e containers de sistema com LXC. Isso é uma vantagem real, e também uma armadilha — porque a escolha errada não dá erro na criação. Ela cobra depois, na forma de um vizinho ruidoso, de uma migração que não pode ser feita ao vivo ou, no pior caso, de um isolamento que você achava que tinha e não tem.

A diferença técnica que explica todo o resto

Uma VM tem kernel próprio. O KVM entrega a ela CPU, memória e dispositivos virtualizados, e dentro dela roda um sistema operacional completo, que não sabe nem precisa saber que é virtual.

Um container LXC compartilha o kernel do host. Ele tem o próprio sistema de arquivos, os próprios processos, a própria rede e os próprios limites de recurso — mas as chamadas de sistema vão para o mesmo kernel que atende o nó e todos os outros containers.

Todo o resto é consequência disso. Container não precisa inicializar um kernel, então sobe em um ou dois segundos. Não emula hardware, então o overhead é quase nulo. E não pode rodar um kernel diferente do host — nem uma versão diferente, nem outro sistema operacional.

Onde o LXC ganha com folga

• Densidade. Sem kernel duplicado e sem hardware emulado, cabe muito mais carga no mesmo hardware. Para dezenas de serviços pequenos, a diferença é grande.
• Velocidade de partida. Segundos, não minutos. Muda o jeito de trabalhar: criar e descartar ambientes deixa de ser custoso.
• Memória sob demanda. O container usa o que precisa dentro do limite. VM tende a reservar o que foi alocado, usado ou não.
• Custo por serviço. Para um provedor que vende hospedagem de aplicação pequena, a densidade do LXC é margem direta.
• Backup enxuto. Sem imagem de disco cheia de sistema operacional replicado, o backup é menor e mais rápido.

O caso ideal é o serviço interno, sob sua administração: um proxy reverso, um coletor de métricas, um runner de CI, um ambiente de homologação, um serviço auxiliar que você mesmo mantém.

Onde a VM é a única resposta certa

E aqui está o ponto que decide a maioria das arquiteturas de provedor: se a carga é de terceiro, é VM. Não por preferência, por superfície de ataque. O kernel compartilhado significa que uma vulnerabilidade de escalonamento no kernel é um caminho do container para o host — e do host para todos os outros containers.

Enquanto você administra tudo o que roda dentro dos containers, o risco é gerenciável. No momento em que existe root de cliente lá dentro, o modelo de isolamento não é adequado. Cliente final recebe VM.

Além disso, VM é obrigatória quando:

1. É preciso outro kernel ou outro sistema. Windows, BSD, uma distribuição com kernel específico, um módulo que precisa ser carregado. Container não faz.
2. A carga exige módulo de kernel ou acesso direto a dispositivo. Alguns casos de VPN, storage e hardware específico.
3. Você depende de migração ao vivo. O KVM move VM entre nós sem desligar. Container migra com reinício — rápido, mas é parada.
4. A conformidade exige isolamento forte, com auditoria que não aceita kernel compartilhado.
5. A aplicação faz suposições sobre o sistema, e adaptar sai mais caro do que a VM economiza.

O comparativo direto

Privilegiado e não privilegiado: escolha o segundo

O LXC no Proxmox tem dois modos. No não privilegiado — o padrão, e o correto — o root de dentro do container é mapeado para um usuário sem privilégio no host. Se alguém escapa do container, cai como usuário comum, não como root do nó.

No privilegiado, esse mapeamento não existe, e o root de dentro é efetivamente root do host. Existem motivos legítimos para usá-lo, quase todos ligados a acesso a dispositivo, mas cada um deles é uma exceção que precisa de justificativa. Se você não sabe dizer por que um container seu é privilegiado, ele não deveria ser.

Docker dentro de LXC: funciona, mas não é o caminho

É possível rodar Docker dentro de um container LXC habilitando aninhamento. Funciona. Também empilha duas camadas de container, complica o armazenamento e produz problemas difíceis de diagnosticar quando algo dá errado.

Para rodar containers de aplicação em produção, o desenho limpo é uma VM dedicada a isso — com Docker ou Kubernetes dentro dela. Você ganha isolamento de verdade, pode migrar ao vivo, atualiza o kernel do host sem tocar na aplicação e depura uma camada em vez de duas. A pequena economia de recurso do LXC não paga a complexidade.

Backup pede atenção diferente

Nos dois casos o Proxmox Backup Server resolve, mas há uma diferença que importa. Para VM com agente de convidado instalado, é possível coordenar um backup consistente com a aplicação — o sistema de dentro é avisado para congelar os arquivos no momento da cópia.

Em container, esse mecanismo não existe da mesma forma. O modo padrão usa snapshot do storage, o que é rápido e consistente no nível do sistema de arquivos, mas não avisa a aplicação. Para um banco de dados dentro de um LXC, o backup do storage pode capturar um estado que exige recuperação na restauração. Se há banco em container, mantenha um dump lógico do banco além do backup do container.

O vizinho ruidoso

Container compartilha kernel, e isso inclui recursos que não aparecem nos limites óbvios de CPU e memória. Entradas de tabela de conexão, descritores de arquivo, limites de processos, cache do sistema de arquivos: um container que abusa desses recursos afeta os vizinhos, mesmo respeitando a cota de CPU.

Duas defesas práticas: configure limites explícitos de CPU, memória e I/O em todos os containers, sem deixar nenhum ilimitado; e não misture, no mesmo nó, containers de perfis muito diferentes — um container de banco de dados junto de containers de build é conflito à espera de acontecer.

Uma regra simples para decidir

Se você respondeu "não" para todas as perguntas abaixo, use LXC. Um "sim" já indica VM:

• A carga é de um cliente ou de alguém fora da sua administração?
• Precisa de sistema operacional diferente, ou de módulo de kernel?
• Depende de migração ao vivo, sem janela de parada?
• Há exigência de conformidade sobre isolamento?
• Vai rodar Docker ou Kubernetes dentro?

Erros comuns

• Entregar LXC para cliente final, achando que o isolamento equivale ao de uma VM.
• Container privilegiado por padrão, sem motivo identificado.
• Contar com migração ao vivo em LXC e descobrir na janela de manutenção.
• Docker dentro de LXC em produção, por economia de recurso.
• Banco de dados em container sem dump lógico complementar.
• Container sem limite de recurso, degradando os vizinhos do nó.
• Escolher LXC pela densidade e depois precisar de Windows.

Onde a Solvefy/Cloud entra

Em projeto de plataforma, definimos essa fronteira com você: o que roda em container porque é serviço interno e o que roda em VM porque é carga de cliente ou exige isolamento forte. Para provedores que vendem cloud com a própria marca, essa linha é especialmente importante — ela separa a densidade que aumenta a margem do risco que não vale correr. Revisamos também ambientes existentes, identificando cargas que estão no lugar errado antes que o problema apareça.

Quer revisar o que roda em container e o que deveria ser VM? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.