LXC ou VM no Proxmox: por que quase tudo aqui é LXC
Num ThinkCentre de 24 GB, quase tudo roda em container LXC e só uma VM sobrou. Quando usar cada um no Proxmox e os cuidados para não se arrepender.
- Publicado
- Leitura
- 5 min
- Testado em
- Proxmox VE 9.2
Meu homelab roda em um único nó Proxmox: um Lenovo ThinkCentre M720q com 6 núcleos e 24 GB de RAM. Nessa máquina pequena cabe muita coisa porque quase tudo roda em container LXC, e não em máquina virtual. Hoje tenho uma única VM, e até ela poderia ser um container.
Neste post explico por que escolhi LXC para quase tudo, quando uma VM ainda faz sentido e o que muda na prática.
A diferença em uma frase #
Uma VM simula um computador inteiro, com kernel próprio. Um container LXC compartilha o kernel do host e isola só os processos, a rede e o sistema de arquivos.
Essa diferença decide quase tudo:
| Container LXC | Máquina virtual | |
|---|---|---|
| Kernel | o do host Proxmox | próprio, qualquer sistema |
| Memória ociosa | só o que os processos usam | reserva a RAM do sistema convidado inteiro |
| Tempo para ligar | segundos | o boot de um sistema completo |
| Isolamento | bom, mas compartilha o kernel | mais forte |
| Rodar Windows ou outro kernel | não | sim |
Por que quase tudo aqui é LXC #
Num servidor com 24 GB de RAM, cada gigabyte conta. Um container com um serviço web simples consome a memória do serviço e pouco mais. A mesma aplicação numa VM carrega junto um sistema operacional inteiro.
O que eu hospedo é, em sua maioria, serviço Linux leve:
- cofre de senhas;
- DNS interno;
- o conector do Cloudflare Tunnel;
- monitoria da internet;
- minhas próprias aplicações;
- este blog.
Nada disso precisa de kernel próprio. Para esse tipo de carga, LXC é mais leve para tudo, e é essa a razão principal da minha escolha.
Outro ganho é a agilidade. Container liga em segundos, o backup é pequeno e criar um container novo para testar algo é rápido o suficiente para eu não ter preguiça de separar cada serviço no seu próprio container. Separar serviços facilita muito na hora de restaurar só uma coisa.
A minha única VM: o jump server #
A exceção é a porta de entrada do homelab, o meu jump server. É por ele que eu chego por SSH quando estou fora de casa, e é nele que fica a monitoria dos acessos SSH.
Ele começou como um Debian completo, com ambiente gráfico. Com o tempo, enxuguei para modo texto e menos pacotes. Hoje, olhando com calma, ele poderia muito bem ser um container LXC. Mantive como VM, e existe um argumento a favor disso: numa máquina que fica exposta como ponto de entrada, o kernel próprio da VM adiciona uma camada de isolamento a mais entre quem tenta entrar e o host.
Se eu estivesse começando hoje, eu pensaria assim: VM para o que é exposto, precisa de outro kernel ou exige isolamento forte; LXC para o resto.
Quando uma VM é a escolha certa #
Mesmo sendo fã de LXC, eu usaria VM nestes casos:
- Outro sistema operacional: Windows, BSD ou qualquer coisa que não rode no kernel Linux do host.
- Módulos de kernel próprios: alguns softwares de VPN, de armazenamento ou de virtualização exigem carregar módulos, o que um container não pode fazer.
- Isolamento forte: serviços expostos à internet ou softwares em que você confia pouco.
- Appliances prontos: sistemas distribuídos como imagem completa, por exemplo alguns firewalls e sistemas de NAS.
Cuidados com LXC #
Container não é VM pequena. Três detalhes que vale saber:
- Prefira containers não privilegiados. No Proxmox, o padrão ao criar pela interface é o container não privilegiado. Nele, o root do container não é o root do host, o que reduz bastante o estrago de uma invasão.
- Docker dentro de LXC precisa de ajuste. É preciso ligar o recurso de nesting no container:
pct set <vmid> --features nesting=1
- O kernel é do host. Uma atualização do Proxmox atualiza o kernel de todos os containers de uma vez. Isso é bom para manutenção, mas significa que um problema de kernel afeta todos juntos.
Para ver o que está rodando no nó, os dois comandos básicos são:
pct list # containers LXC
qm list # máquinas virtuais
Como isso escala num nó só #
Ter um único nó tem um limite óbvio: se a máquina para, tudo para. Para mim isso é aceitável hoje, porque a energia está coberta por uma bateria (contei no post sobre a EcoFlow como UPS) e os backups estão em dia.
O próximo passo que eu quero dar é uma segunda máquina para montar um cluster, o que traz outros cuidados, como quórum. Mas a lógica de LXC para quase tudo continua valendo: quanto mais leve cada serviço, mais coisa cabe em cada nó.
Resumindo #
- LXC para serviços Linux leves: menos memória, liga em segundos e tem backup pequeno.
- VM para outro sistema operacional, módulos de kernel, appliances e o que fica mais exposto.
- Comece não privilegiado e ligue o nesting só onde precisar de Docker.
- Um serviço por container facilita backup, restauração e limites.
Num ThinkCentre de 24 GB, essa escolha é o que permite rodar todos os meus serviços com folga e ainda sobrar espaço para testar coisas novas.