Casos de uso

Cenários Reais de Aplicação

O Proxmox VE é uma plataforma versátil, adotada desde por entusiastas de tecnologia em seus laboratórios domésticos (Homelabs) até por grandes corporações para consolidar centenas de servidores em datacenters hiperconvergentes.

Para extrair o máximo de valor da plataforma, o administrador precisa entender as demandas de cada carga de trabalho (workload) e mapeá-las para a tecnologia correta (VM ou Container).

💡

Decisão de Arquitetura

A regra de ouro do Proxmox VE é focar na natureza do serviço: se ele é altamente acoplado ao kernel do sistema ou exige sistemas operacionais não-Linux, use VM. Se o serviço é um microsserviço Linux comum ou consome muito processamento e disco em formato stateless, use LXC.

Mapeamento de Cargas de Trabalho Comuns

1. Servidores Web e Reverse Proxies

Aplicações baseadas em Nginx, HAProxy, Apache ou Node.js são candidatos perfeitos para Containers LXC.

Por quê? Eles são tipicamente stateless, exigem pouca memória RAM base e se beneficiam do tempo de boot quase instantâneo do LXC em caso de escalonamento ou reinicialização rápida.

2. Bancos de Dados (PostgreSQL, MySQL, Redis)

O gerenciamento de bancos de dados depende do escopo do projeto:

LXC: Excelente para bancos de dados de desenvolvimento, homologação ou serviços internos leves. A performance de I/O de disco é máxima (quase idêntica ao host físico) e o consumo de RAM é otimizado.
VM (KVM): Recomendado para bancos de dados corporativos de grande porte em produção. A VM garante isolamento rígido de memória (garantindo que o banco tenha toda a RAM alocada reservada por hardware) e permite snapshots consistentes em nível de bloco, além de suportar clusters complexos que dependem de configurações de kernel customizadas.

3. Serviços de Diretório (Active Directory / Samba AD DC)

VM (KVM): Sempre utilize máquinas virtuais completas para hospedar o Microsoft Active Directory (Windows Server) ou implementações Samba AD DC.
Por quê? O Active Directory exige total conformidade com protocolos de rede de baixo nível, relógios de alta precisão do sistema e isolamento completo contra interferências do kernel do host físico.

4. Homelabs e Automação Residencial

No cenário de Homelab, o Proxmox VE brilha por permitir consolidar dezenas de serviços em um hardware modesto (ex: um Mini PC Intel N100 ou similar).

Home Assistant: Geralmente executado em uma VM KVM dedicada para que o administrador possa fazer o USB Passthrough estável de dongles Zigbee, Z-Wave ou Bluetooth diretamente para a VM.
Plex / Jellyfin / Emby: Frequentemente executado em LXC para facilitar o compartilhamento da GPU integrada do host (Intel QuickSync ou placa dedicada NVIDIA) para transcodificação de vídeo por hardware sem o overhead de emulação PCIe (GPU Passthrough) complexo exigido nas VMs.

Tabela de Mapeamento de Workloads

Workload / Aplicação	Tecnologia Recomendada	Justificativa Técnica
Active Directory	VM (KVM)	Exige kernel próprio (Windows) e controle rígido de sincronia temporal.
Plex Media Server	Container (LXC)	Permite acesso direto à GPU física do host para aceleração gráfica (transcodificação).
Reverse Proxy (Nginx)	Container (LXC)	Baixíssimo consumo de recursos, inicialização imediata e fácil manutenção.
Banco de Dados Principal	VM (KVM)	Snapshots de bloco limpos, RAM 100% dedicada e isolamento de segurança forte.
Home Assistant (OS)	VM (KVM)	Facilidade de USB Passthrough para antenas físicas e independência de sistema.

Exemplo Prático: Dimensionando um Host de 64GB de RAM

Imagine que você foi contratado para projetar a infraestrutura de uma pequena empresa usando um único host físico Proxmox VE com 64GB de RAM e 16 vCPUs.

A topologia planejada para otimizar os recursos do host é a seguinte:

VM 100 (Windows Server AD): 8GB de RAM / 4 vCPUs (Crítico - VM Isolada).
VM 101 (Banco PostgreSQL Principal): 16GB de RAM / 4 vCPUs (Crítico - RAM Dedicada).
LXC 200 (Zabbix Monitoramento): 4GB de RAM / 2 vCPUs (Leve - LXC para eficiência).
LXC 201 (Nginx Reverse Proxy): 1GB de RAM / 1 vCPU (Leve - LXC para agilidade).
LXC 202 (Servidor de Arquivos Samba): 4GB de RAM / 2 vCPUs (I/O Rápido - LXC com bind mounts).

Total alocado teoricamente: 33GB de RAM e 13 vCPUs. Isso deixa uma margem segura de mais de 30GB de RAM física livre para o cache do sistema de arquivos ZFS do host e para o crescimento futuro da infraestrutura.

Procedimento de Reconhecimento de Hardware

Antes de criar VMs que exijam virtualização por hardware, certifique-se de que o host físico possui suporte a KVM ativo.

checar-suporte.sh bash

1. Verificar se as extensões Intel VT-x ou AMD-V estão ativas no processador (deve retornar um número maior que 0)
egrep -c ‘(vmx|svm)’ /proc/cpuinfo
2. Listar os dispositivos USB conectados ao host (essencial para planejar USB passthrough)
lsusb

Validação

Você entendeu a aula se consegue responder:

Por que o compartilhamento de GPU para transcodificação de vídeo é mais simples em containers LXC do que em VMs KVM?
Em quais casos é altamente recomendado usar Máquinas Virtuais em vez de LXC para bancos de dados?
Qual o risco de dimensionar uma infraestrutura alocando 100% da RAM física do host exclusivamente para VMs KVM?
O que é USB Passthrough e em qual workload ele é comumente empregado?

Boas Práticas

Monitore a alocação de RAM: Lembre-se que o Proxmox VE e o sistema operacional Debian subjacente precisam de cerca de 2GB a 4GB de RAM livre para funcionar de maneira estável. Se você utilizar ZFS como sistema de arquivos de storage, ele utilizará por padrão até 50% da RAM livre do host para cache (ARC), portanto planeje a memória livre com cuidado.
Limite recursos no LXC: Sempre defina limites de CPU e memória nos containers para evitar que um loop de aplicação em um container secundário consuma todos os recursos do host físico, afetando as VMs críticas.
Use VLANs para isolamento: Ao consolidar diversos workloads de clientes ou setores diferentes no mesmo host, utilize tags de VLAN nas pontes de rede (Linux Bridges) para isolar o tráfego de rede das aplicações.