Containers LXC ou VMs no Proxmox: quando usar cada um

No Proxmox você cria dois tipos de instância: containers LXC e máquinas virtuais. Escolher o tipo certo economiza recursos e dor de cabeça — e a diferença não é sutil: o mesmo servidor pode rodar cerca de três vezes mais containers do que VMs.

Máquinas virtuais (KVM)

Uma VM simula um computador completo: BIOS, disco, placa de rede e, principalmente, seu próprio kernel. O sistema convidado não sabe que está virtualizado e se comporta exatamente como em hardware físico.

• Use quando precisar rodar Windows, um kernel específico, um appliance fechado de fornecedor ou qualquer sistema que não seja Linux;
• Use também quando o isolamento precisa ser rígido — ambientes de clientes diferentes, ou sistemas com exigência de conformidade;
• Custo: mais memória, mais disco e um pouco de sobrecarga de processamento.

Containers LXC

Containers compartilham o kernel do hospedeiro. Eles não são um computador virtual, e sim um conjunto de processos isolados — com sua própria árvore de arquivos, rede e usuários, mas rodando sobre o mesmo kernel.

• Use quando for um serviço Linux comum: servidor web, banco de dados, aplicação interna, DNS, proxy;
• Ganho: iniciam em segundos, consomem uma fração da memória e o disco cresce só conforme o uso real.

A diferença em números

A linha da migração ao vivo costuma ser decisiva e é pouco lembrada. Containers precisam ser desligados para mudar de nó; VMs migram em funcionamento. Em um cluster onde você quer fazer manutenção de hardware em horário comercial, isso pesa bastante.

Onde o container tropeça

Alguns casos concretos em que o container dá mais trabalho do que economiza:

• Docker dentro de container LXC. Funciona, mas exige container privilegiado ou ajustes finos. É mais previsível rodar Docker dentro de uma VM;
• Software que carrega módulo de kernel — alguns antivírus, VPNs e sistemas de arquivos. O container não tem kernel próprio, então não há onde carregar;
• Ajustes de kernel específicos por aplicação, já que todos compartilham os parâmetros do hospedeiro;
• Passagem de hardware, como GPU ou controladora dedicada, que funciona melhor em VM;
• Suporte do fornecedor. Muitos softwares comerciais só homologam instalação em sistema completo, e "está rodando em container" pode virar motivo para recusar atendimento.

Backup e snapshot: comportamentos diferentes

Detalhe que aparece só na hora do incidente. Snapshot de VM pode incluir o estado da memória — ao reverter, a máquina volta exatamente como estava, com processos em execução. Snapshot de container captura só o sistema de arquivos; ao reverter, ele reinicia.

Para backup, containers levam vantagem: são menores e mais rápidos de copiar e restaurar. Já para VMs, o agente convidado permite backup consistente com o sistema em funcionamento — recurso importante quando há banco de dados envolvido.

Como isso fica na prática

Um ambiente típico de empresa média, bem distribuído:

VMs
  ├── Windows Server (sistema de gestão)
  ├── Firewall / appliance de rede
  ├── Servidor de banco de dados (memória reservada)
  └── Hospedeiro Docker, se houver

Containers
  ├── Servidor web e proxy reverso
  ├── Nextcloud
  ├── Zabbix
  ├── DNS interno
  ├── Servidor de arquivos Samba
  └── Ambientes de homologação

A maioria das infraestruturas mistura os dois: containers para os muitos serviços Linux do dia a dia, VMs para os casos que exigem isolamento, Windows ou suporte de fornecedor. O Proxmox gerencia ambos na mesma tela, com o mesmo backup e o mesmo controle de acesso.

Uma dúvida comum: dá para converter?

Não existe conversão automática entre container e VM — são formatos diferentes. Migrar significa criar a nova instância e mover os dados e a configuração da aplicação.

Por isso vale decidir com atenção no início. Na dúvida entre os dois para um serviço importante, a escolha conservadora é a VM: ela sempre funciona, ao custo de mais recursos. Container é otimização, e otimização prematura em produção costuma custar mais caro do que a memória que economiza.