O Proxmox é agradável de operar, e isso tem um efeito colateral: dá para montar um ambiente funcional rapidamente, sem tomar decisões que só cobram a conta meses depois. Quando a conta chega, ela vem como incidente.
Esta lista sai dos ambientes que atendemos. São os mesmos erros, na mesma ordem de frequência, praticamente sempre — e todos são corrigíveis, alguns em uma tarde.
1. Rede plana, com tudo na mesma bridge
O erro: uma única bridge ligando VMs, hosts, storage e gestão. É o desenho padrão de quem está começando, e é o que mais expõe o ambiente.
Por que dói: uma VM comprometida enxerga a interface de gestão do hipervisor e a rede de storage. É a rota mais curta e mais explorada para comprometer tudo. Além disso, tráfego de storage e de VM competem pela mesma banda, produzindo lentidão errática.
A correção: separar em camadas — gestão, cluster, storage e VMs —, em VLANs ou interfaces distintas. A rede de gestão nunca deve ser alcançável a partir de VM.
O teste: de dentro de uma VM comum, tente alcançar a porta 8006 de um nó. Se responder, este é o seu item mais urgente.
2. Cluster operando sem folga
O erro: encher os nós até quase o limite, porque "ainda cabe".
Por que dói: cluster existe para sobreviver à perda de um nó. Se não há capacidade nos demais para receber as VMs do que caiu, o HA não consegue realocá-las e você tem indisponibilidade — exatamente no cenário que o cluster deveria resolver.
A correção: a capacidade utilizável é a total menos um nó. Em três nós, cerca de 66% por nó; em cinco, 80%. Defina o limiar e o gatilho de compra antes de chegar perto.
3. Tratar snapshot como backup
O erro: confiar em snapshots diários como estratégia de proteção.
Por que dói: snapshot mora no mesmo storage do dado. Não sobrevive a falha de storage, exclusão da VM, ransomware ou perda do datacenter. E snapshot esquecido enche o pool e degrada o desempenho.
A correção: snapshot é rede de proteção de curtíssimo prazo — cria antes da mudança, valida, apaga. Backup é Proxmox Backup Server, com retenção escalonada, verificação de integridade, cópia externa e restauração testada.
4. Tipo de CPU errado, descoberto na urgência
O erro: deixar o tipo de CPU no padrão conservador, ou usar host em cluster com processadores de gerações diferentes.
Por que dói: o padrão conservador esconde instruções modernas e deixa desempenho na mesa, incluindo aceleração de criptografia. O host em cluster heterogêneo impede a migração — e você descobre isso no dia em que precisa esvaziar um nó com urgência.
A correção: cluster homogêneo usa host; heterogêneo usa um modelo comum compatível com o nó mais antigo. E atenção: mudar isso exige desligar e ligar a VM, então é melhor acertar antes.
5. Sem agente de convidado
O erro: não instalar o agente nas VMs, especialmente nas Windows.
Por que dói: sem ele, o Proxmox não sabe o endereço da VM, não desliga graciosamente e — o mais grave — não congela o sistema de arquivos durante o backup. O backup captura o disco em estado bruto, o equivalente a puxar o cabo. Restaura na maioria das vezes; "na maioria das vezes" não é proteção.
A correção: agente instalado em todos os templates, e a opção habilitada na configuração da VM. São dois passos, e o segundo é frequentemente esquecido.
6. Todo mundo usando root
O erro: a equipe inteira compartilhando root@pam.
Por que dói: sem rastreabilidade — o log diz root@pam e a pergunta "quem apagou aquela VM?" fica sem resposta. Sem privilégio mínimo: o atendimento de primeiro nível, que só precisa reiniciar VM, pode apagar qualquer coisa. E o desligamento de alguém não revoga acesso nenhum.
A correção: usuários nominais, grupos por função, pools por cliente ou por time, papéis com privilégio mínimo, 2FA nas contas administrativas e tokens de API com escopo mínimo para automação. Root com senha em cofre, de uso excepcional.
7. Ceph em dois nós, ou dois nós esperando failover
O erro: montar dois nós e esperar que um assuma quando o outro cair. Ou forçar Ceph em dois nós.
Por que dói: com dois nós não há maioria possível para decidir quem está vivo — o comportamento seguro do Proxmox é degradar, não assumir. E Ceph precisa de três nós para manter réplicas com segurança; forçar dois é um desenho que devolve corrupção sob falha.
A correção: três nós, sempre que o orçamento alcançar — e a diferença costuma ser menor do que a complexidade evitada. Se forem dois, é obrigatório um QDevice como terceiro votante, fora dos dois nós, com replicação ZFS e o RPO dela escrito no acordo de serviço.
8. Backup no mesmo lugar do dado
O erro: backup gravado no mesmo storage, ou no mesmo equipamento, da produção.
Por que dói: a falha que leva o dado leva o backup junto. É o cenário para o qual o backup existia.
A correção: backup em equipamento distinto, com cópia externa cifrada, verificação de integridade agendada e — o item que decide tudo — restauração testada e cronometrada. Backup nunca restaurado é uma hipótese.
9. Atualizar tudo de uma vez, ou nunca atualizar
O erro: os dois extremos. Aplicar atualização em todos os nós simultaneamente, ou não atualizar "porque não pode parar".
Por que dói: no primeiro caso, uma regressão derruba o ambiente inteiro ao mesmo tempo. No segundo, vulnerabilidades conhecidas ficam abertas e a distância até a versão atual cresce até a atualização virar projeto.
A correção: ciclo definido, nó a nó, com VMs migradas antes, backup válido, notas da versão lidas e validação de cada nó antes de seguir. E um laboratório que recebe a atualização dias antes da produção.
10. Nenhum monitoramento próprio do cluster
O erro: confiar no painel do Proxmox para saber como o ambiente está.
Por que dói: o painel mostra o agora. Ele não guarda histórico, não projeta tendência e não avisa ninguém. Você descobre o disco cheio quando a VM para, e a capacidade esgotada quando a próxima não sobe.
A correção: coleta com histórico, painéis e alertas com destino definido — estado de quórum, saúde do storage, espaço com projeção de tendência, atraso de replicação, resultado de backup e, principalmente, ausência de backup que deveria ter rodado.
O erro número onze: nenhuma documentação
Não entra na lista porque não é técnico, e é o mais caro no médio prazo.
Ambiente que só uma pessoa sabe operar é um ponto único de falha que nenhum cluster resolve. O mínimo: desenho da rede, dos storages e do cluster; procedimento de manutenção de nó; procedimento de restauração; lista de VMs que não migram e por quê; quem tem acesso a quê.
O diagnóstico rápido
Se você migrou recentemente, seis perguntas resolvem:
- De uma VM comum, a interface de gestão de um nó responde?
- Se o nó mais cheio cair agora, as VMs dele cabem nos outros?
- Quando foi a última restauração de backup testada, e quanto tempo levou?
- Você consegue migrar qualquer VM para qualquer nó?
- O log de tarefas diz nomes de pessoas ou diz
root@pam? - Alguém é avisado quando o backup não roda?
Cada "não sei" é um item desta lista esperando virar incidente.
Onde a Solvefy/Cloud entra
Como parceiros oficiais Proxmox, fazemos exatamente essa revisão em ambientes recém-migrados — com teste prático, não questionário: verificamos o que é alcançável de dentro de uma VM, medimos a capacidade real de absorver a queda de um nó, cronometramos uma restauração de verdade e testamos o esvaziamento de um nó. Entregamos os achados priorizados por risco e implantamos as correções, da rede ao monitoramento, deixando a documentação que permite mais de uma pessoa operar.
Migrou para Proxmox e quer saber o que ficou para trás? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.