Você instalou o Proxmox, criou algumas VMs, fez um backup. Bom começo. Mas tem uma porção de features que ficam escondidas atrás de menus secundários ou que ninguém menciona nos tutoriais de introdução. Esse post é sobre essas features.

Se você ainda não passou pelo Proxmox: O ESXi que não te manda boleto, começa por lá para ter o contexto de instalação e primeiros passos.

LXC: o container que não é Docker

O Proxmox suporta dois tipos de carga de trabalho: VMs (KVM) e containers (LXC). A maioria das pessoas ignora o LXC e usa só VMs. Isso é razoável em alguns contextos, mas perder o LXC significa deixar na mesa um dos melhores recursos da plataforma.

VM vs LXC: quando usar cada um

VM quando:

• O workload precisa de kernel próprio (aplicações que mexem em parâmetros de kernel)
• Windows ou outro SO não-Linux
• Isolamento forte entre tenants diferentes
• Você não tem certeza sobre compatibilidade do LXC com o workload

LXC quando:

• Linux puro, workload previsível (nginx, postgres, redis, gitea, etc.)
• Quer densidade maior no host (menos overhead de memória e disco)
• Precisa de startup rápido (containers LXC sobem em menos de 1 segundo)
• Vai criar muitas instâncias do mesmo serviço

A diferença de recursos é real. Um container LXC com nginx ocupa ~30MB de RAM. Uma VM com o mesmo serviço, com o overhead do kernel e do processo de boot, dificilmente fica abaixo de 200MB — e geralmente passa de 512MB numa configuração prática.

Criando um container LXC

Primeiro passo: baixar um template de container. O Proxmox tem um repositório oficial:

# Listar templates disponíveis
pveam available | grep debian

# Baixar
pveam download local debian-12-standard_12.7-1_amd64.tar.zst

Via UI: Node → local → CT Templates → Templates (botão no topo).

Criando o container:

# Via CLI
pct create 200 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname nginx-ct \
  --memory 256 \
  --swap 0 \
  --cores 1 \
  --net0 name=eth0,bridge=vmbr0,ip=dhcp \
  --rootfs local-lvm:8 \
  --password senha-root \
  --start 1

# Acessar o console
pct enter 200

# Comandos básicos
pct start 200
pct stop 200
pct status 200
pct exec 200 -- apt update

💡 Containers LXC no Proxmox são "system containers", não application containers como Docker. Você instala um sistema Debian/Ubuntu/Alpine completo dentro deles, com init, systemd, pacotes — tudo. É mais próximo de uma VM leve do que de um container Docker.

Containers privilegiados vs não-privilegiados

Por padrão, o Proxmox cria containers não-privilegiados: o root dentro do container é mapeado para um UID alto no host (por exemplo, UID 100000), então mesmo que alguém escape do container, não tem acesso root no host.

Containers privilegiados rodam com UID 0 direto no host. São necessários para alguns casos específicos (montagem de NFS dentro do container, uso de cgroups aninhados, Docker dentro de LXC). Use com consciência.

# Verificar se é privilegiado
pct config 200 | grep unprivileged

# Criar privilegiado (não recomendado sem necessidade)
pct create 201 ... --unprivileged 0

Snapshots e backups de LXC

LXC com armazenamento ZFS ou LVM-thin suporta snapshots instantâneos, iguais às VMs:

# Snapshot
pct snapshot 200 snap-pre-atualizacao

# Listar
pct listsnapshot 200

# Restaurar
pct rollback 200 snap-pre-atualizacao

# Backup via vzdump (mesmo comando das VMs)
vzdump 200 --storage backup-pool --mode snapshot --compress zstd

SDN: rede definida por software no Proxmox

O SDN do Proxmox (disponível desde a versão 7.x, mais maduro na 8.x) permite criar topologias de rede virtuais independentes da rede física. É uma feature poderosa que poucos homelabs exploram.

Habilitando o SDN

# Instalar o plugin SDN (se não estiver instalado)
apt install libpve-network-perl

# Aplicar mudanças de SDN após cada configuração
pvesh set /cluster/sdn

Via UI: Datacenter → SDN.

Conceitos básicos

O SDN do Proxmox tem três camadas:

Zones — definem o tipo de rede virtual. Os tipos principais:

• Simple — bridge simples, sem isolamento extra
• VLAN — mapeia para VLANs físicas existentes
• VXLAN — overlay de rede sobre UDP (para clusters multi-site)
• EVPN — protocolo de roteamento dinâmico entre zones (mais avançado)

VNets — a rede virtual em si, dentro de uma zone. Cada VNet vira uma interface bridge no host.

Subnets — faixas de IP com DHCP e DNS integrados (usando dnsmasq).

Exemplo prático: isolamento de ambiente

# Criar uma zone VLAN
pvesh create /cluster/sdn/zones \
  --zone prod \
  --type vlan \
  --bridge vmbr0

# Criar uma VNet (VLAN 100 para produção)
pvesh create /cluster/sdn/vnets \
  --vnet vnet-prod \
  --zone prod \
  --tag 100

# Aplicar
pvesh set /cluster/sdn

# Criar subnet com DHCP
pvesh create /cluster/sdn/vnets/vnet-prod/subnets \
  --subnet 10.10.100.0/24 \
  --gateway 10.10.100.1 \
  --dhcp-range start-address=10.10.100.100,end-address=10.10.100.200 \
  --dns-zone prod.local

Agora VMs e containers podem usar vnet-prod como interface de rede e recebem IP automaticamente via DHCP, com DNS local resolvendo hostname.prod.local.

⚠️ SDN com subnets e DHCP requer dnsmasq instalado e o serviço pvedaemon reiniciado após configuração. Em cluster, as mudanças precisam ser propagadas para todos os nós com pvesh set /cluster/sdn.

VLANs sem SDN (o jeito mais simples)

Para quem só quer tagged VLANs sem a complexidade do SDN:

# Criar uma bridge com VLAN awareness
# Em /etc/network/interfaces:
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

# Nos containers/VMs, adicionar a tag da VLAN na interface
# pct set 200 --net0 name=eth0,bridge=vmbr0,tag=100
# qm set 100 --net0 virtio,bridge=vmbr0,tag=100

Ceph: storage distribuído integrado

O Proxmox tem integração nativa com Ceph — você instala e configura o cluster Ceph diretamente da interface web. Para homelab com três ou mais nós, Ceph é o caminho mais elegante para storage compartilhado sem precisar de NFS externo.

💡 Ceph precisa de pelo menos 3 nós para funcionar com redundância real. Com 2 nós você consegue configurar, mas perde a capacidade de recuperação automática em caso de falha. Para cluster e HA, veja Quando um nó não é suficiente.

Requisitos práticos

• Mínimo 3 nós Proxmox no mesmo cluster
• Pelo menos 1 disco dedicado por nó para Ceph (não misture com o disco do SO)
• Rede dedicada para replicação Ceph (recomendado: 10GbE ou pelo menos 1GbE isolado)

Instalando Ceph via UI

Node → Ceph → Install — o Proxmox baixa e configura tudo automaticamente.

Via CLI em cada nó:

# Instalar Ceph no nó
pveceph install --version reef

# Inicializar o cluster Ceph (só no primeiro nó)
pveceph init --network 10.10.20.0/24  # rede dedicada para Ceph

# Criar monitor (necessário em pelo menos 3 nós)
pveceph mon create

# Criar OSD (um por disco dedicado)
pveceph osd create /dev/sdb

# Criar pool para VMs
pveceph pool create vm-pool --pg_num 128 --size 3

# Adicionar o pool como storage no Proxmox
pvesm add rbd ceph-vms \
  --pool vm-pool \
  --username admin \
  --content images

Com Ceph funcionando, VMs armazenadas no pool ceph-vms são automaticamente replicadas em todos os nós. Live migration de VMs entre nós funciona instantaneamente porque o storage está disponível em qualquer lugar do cluster.

Ceph Dashboard

O Ceph tem uma dashboard própria acessível em https://IP-do-nó:8443. Para ativar:

ceph mgr module enable dashboard
ceph dashboard create-self-signed-cert
ceph dashboard set-login-credentials admin

Para monitoramento do status do cluster:

ceph status          # visão geral
ceph osd tree        # topologia dos OSDs
ceph df              # uso de disco
ceph health detail   # detalhes de problemas

Templates e cloning strategy

O Proxmox tem uma abordagem própria para templates que vale documentar. A ideia é: você cria uma VM "golden image", converte em template, e clona a partir dela.

Criando um template

# Criar VM normalmente, instalar SO, configurar o básico

# Dentro da VM: preparar para clonagem
# (equivalente ao virt-sysprep)
apt clean
truncate -s 0 /etc/machine-id
truncate -s 0 /var/lib/dbus/machine-id
rm -f /etc/ssh/ssh_host_*
history -c

# No host Proxmox: converter em template
qm template 101
# Depois disso a VM vira somente leitura e não pode mais ser iniciada

Clonagem

# Clone completo (cópia independente do disco)
qm clone 101 200 --name nova-vm --full

# Clone linkado (usa o template como base, ocupa menos espaço)
# Só funciona com storage que suporta snapshots (ZFS, LVM-thin, RBD)
qm clone 101 201 --name nova-vm-linked
# O clone linkado depende do template existir — deletar o template quebra os clones

⚠️ Clones linkados em produção: cuidado. Se o template for deletado ou corrompido, todos os clones ligados a ele ficam inoperantes. Para ambientes críticos, use clone completo ou certifique-se de que o template está protegido contra deleção (lock via UI ou pvesh set /nodes/pve/qemu/101/config --lock backup).

Combinando com cloud-init

O melhor fluxo para criar VMs em quantidade é template com cloud-init, como descrito no Para de configurar VM na mão. No Proxmox, depois de clonar:

# Ajustar configurações de cloud-init no clone antes de iniciar
qm set 200 \
  --hostname servidor-web-01 \
  --ipconfig0 ip=192.168.1.101/24,gw=192.168.1.1 \
  --sshkey ~/.ssh/id_ed25519.pub

# Iniciar
qm start 200

Resource pools e organização

Com muitas VMs, a organização começa a importar. O Proxmox tem resource pools para agrupar VMs e containers:

# Criar um pool
pvesh create /pools --poolid producao --comment "VMs de produção"

# Adicionar VMs ao pool
pvesh set /pools/producao --vms 100,101,102

# Listar pools
pvesh get /pools

# Permissões por pool: dar acesso a um usuário somente no pool dele
pveum aclmod /pool/producao --user dev@pve --role PVEVMUser

vzdump avançado: automatizando backups

O vzdump é o backend de backup do Proxmox. A interface web configura ele por baixo, mas via CLI você tem mais controle:

# Backup de todas as VMs e containers rodando, comprimido, modo snapshot
vzdump --all --storage backup-pool --mode snapshot --compress zstd

# Backup de VMs específicas com retenção
vzdump 100 101 200 \
  --storage backup-pool \
  --mode snapshot \
  --compress zstd \
  --maxfiles 7    # mantém últimos 7 backups desse ID

# Backup com notificação por email
vzdump --all \
  --storage backup-pool \
  --mode snapshot \
  --mailnotification always \
  --mailto admin@empresa.com

# Ver backups existentes
pvesh get /nodes/pve/storage/backup-pool/content?content=backup

Restore

# Restaurar VM de backup (cria uma nova VM com ID especificado)
qmrestore /mnt/pve/backup-pool/dump/vzdump-qemu-100-2026_03_01-02_00_00.vma.zst 150

# Restaurar container
pct restore 250 \
  /mnt/pve/backup-pool/dump/vzdump-lxc-200-2026_03_01-02_00_00.tar.zst \
  --storage local-lvm

Monitoramento com métricas externas

O Proxmox pode enviar métricas para servidores externos:

# Configurar envio para InfluxDB
# Datacenter → Metric Server → Add → InfluxDB
pvesh create /cluster/metrics/server/influxdb \
  --server 192.168.1.50 \
  --port 8086 \
  --type influxdb \
  --bucket proxmox \
  --token seu-token-influx

# Para Graphite
pvesh create /cluster/metrics/server/graphite \
  --server 192.168.1.51 \
  --port 2003 \
  --type graphite

Com InfluxDB + Grafana você consegue dashboards com histórico de CPU, memória, I/O e rede por VM, por nó, e por período. Vale o setup para ambientes que precisam de observabilidade.

Conclusão

LXC resolve densidade de serviços sem overhead de VM. SDN resolve isolamento de rede sem depender de switches gerenciáveis. Ceph resolve storage compartilhado sem NFS externo. Templates com cloud-init resolvem provisionamento em escala. Não precisa adotar tudo de uma vez — mas vale conhecer cada opção para escolher a ferramenta certa quando o problema aparecer.

Os próximos passos naturais a partir daqui são Quando um nó não é suficiente para cluster e alta disponibilidade, e Proxmox blindado com MFA para segurança do ambiente.