Rightsizing de máquinas virtuais: guia técnico para VMware, Hyper-V e Proxmox

Operar um cluster de virtualização exige equilíbrio constante entre densidade e desempenho. Por outro lado, é comum que VMs nasçam superdimensionadas no checklist do projeto e nunca sejam revisitadas. Como resultado, o cluster fica cheio antes do tempo e a fatura de licenças cresce sem retorno operacional.

O rightsizing de máquinas virtuais é o processo de ajustar vCPU, memória, storage e rede ao consumo real de cada workload, com base em métricas observadas em produção. Em síntese, é o oposto da decisão de capacidade feita “no chute” durante o provisionamento inicial. Vale destacar que esse ajuste vale tanto para reduzir VMs gigantes quanto para corrigir VMs subdimensionadas que sofrem com contenção.

Este guia consolida o passo a passo do rightsizing em ambientes on-prem e híbridos baseados em VMware vSphere, Microsoft Hyper-V e Proxmox VE. Em seguida, abordamos as métricas que disparam a revisão, o workflow técnico, as diferenças entre cada hypervisor e os cenários em que rightsizing é uma péssima ideia.

O que é rightsizing de máquinas virtuais

Rightsizing de máquinas virtuais é a prática de ajustar recursos alocados: vCPU, memória, storage e rede, ao consumo efetivamente observado em produção. Em outras palavras, é alinhar o que a VM tem ao que a VM usa. O alvo não é apenas reduzir custos. Em vez disso, o ajuste aproxima o provisionamento da realidade operacional.

Vale dizer que três conceitos relacionados são frequentemente confundidos. O rightsizing redimensiona a VM existente. A reclamação (reclamation) devolve capacidade ociosa de VMs zumbis ao cluster. O capacity planning projeta a capacidade futura do host ou do cluster. Os três fazem parte do mesmo ciclo de governança, mas atuam em camadas diferentes da pilha.

A diferença prática aparece na ação. Por exemplo, uma VM com 16 vCPUs e CPU médio de 6% por 45 dias é candidata clara a rightsizing: reduzir para 8 vCPUs e medir o impacto. Em contrapartida, uma VM desligada há 90 dias com 200 GB de disco é candidata a reclamation. Ainda assim, o cluster com utilização média de 78% por 30 dias precisa de capacity planning, não de rightsizing tático.

Esse trabalho parte do conhecimento básico sobre como máquinas virtuais convivem em um hypervisor, da forma como o agendador distribui ciclos de CPU e do impacto do oversubscription. Portanto, antes de mexer no tamanho de uma VM, é essencial entender o modelo do hypervisor por baixo dela.

Por que rightsizing on-prem é diferente de rightsizing cloud

A diferença mais relevante está no modelo de capacidade. Na nuvem pública, você paga por instância e troca de tipo com um reboot. No on-prem, a capacidade do host é fixa e o ganho aparece como liberação de recursos para outras VMs no mesmo cluster, atraso na compra do próximo blade ou redução do número de cores licenciados.

O rightsizing aplicado a cloud público trabalha com famílias de instância pré-definidas, autoscaling e tarifas por hora. O rightsizing on-prem trabalha com vCPU per core, memory reservation, NUMA boundary e padrões de oversubscription definidos pelo time de infraestrutura. Da mesma forma, a unidade de economia muda: aqui ela aparece em CAPEX evitado e em licenças por core do hypervisor.

Esse último ponto ganhou peso depois das mudanças no licenciamento VMware sob a Broadcom, que passou a cobrar pacotes por core mínimo por CPU. Em resumo, cada vCPU não usada vira licença paga. Por isso, rightsizing on-prem hoje é tanto um exercício técnico quanto financeiro: menos vCPU provisionada = menos VMs migrando para licenças mais caras na próxima renovação.

Sinais de VMs superdimensionadas e subdimensionadas

Identificar candidatas ao rightsizing é menos arte e mais leitura disciplinada de métricas. Existem sinais clássicos de superdimensionamento (VM com mais recurso que precisa) e de subdimensionamento (VM com menos recurso que precisa). Em ambos os casos, a regra é cruzar pelo menos duas métricas antes de tomar a decisão.

A leitura cruzada dos sinais define a ação. Por exemplo, uma VM com vCPU médio baixo e ready time alto está duplamente errada: sobra vCPU configurada e ainda assim falta tempo no agendador. Nesse cenário, reduzir vCPUs resolve os dois problemas ao mesmo tempo. Para aprofundar quais métricas observar em hosts e VMs, consulte o pillar de métricas de virtualização.

Métricas e janela de coleta antes do redimensionamento

A maior fonte de erro em rightsizing é decidir com pouca amostra. Uma janela de 7 dias é insuficiente, principalmente para workloads que sofrem variação semanal ou mensal. A boa prática recomenda mínimo de 14 dias para workloads estáveis e 30 a 90 dias para aplicações com sazonalidade (folha, ERP, fechamento contábil, e-commerce em datas comemorativas).

Use percentis, não média. A média esconde picos. Já o pico é justamente o que dimensiona o recurso. Em síntese, a regra prática é olhar o P95 e o P99 de CPU e de memória. Se o P95 ainda está confortavelmente abaixo do alocado, a VM pode encolher. Se o P99 já está colado no teto, encolher é arriscado.

Exclua janelas atípicas. Backup full, batch noturno, treinamento de modelo, simulação de DR e fechamento contábil distorcem a baseline. Por isso, marque esses períodos como excluded windows no seu sistema de observabilidade. Da mesma forma, exclua os 7 primeiros dias após qualquer mudança em produção: o sistema ainda está se acomodando.

Quando o time consegue manter uma visão consolidada de monitoramento de servidores físicos e VMs, fica simples diferenciar o que é gargalo de host do que é gargalo de VM. Essa separação evita o erro clássico de redimensionar a VM quando, na verdade, o problema é o host saturado.

Workflow passo a passo de rightsizing de VMs

O workflow tático segue cinco passos. Em primeiro lugar, estabelecer baseline. Em seguida, identificar candidatas. Posteriormente, priorizar pelo retorno e pelo risco. Antes da execução, simular o impacto. Por fim, validar pós-mudança.

1. Baseline

Colete pelo menos 30 dias de métricas do hypervisor (cpu.usage, cpu.ready, mem.consumed, mem.balloon, mem.swapped, disk.latency) e do guest OS (via agente). Registre janelas atípicas para exclusão. O resultado é uma planilha ou dashboard com utilização P50, P95 e P99 por VM.

2. Identificação

Aplique os critérios da tabela anterior. Marque cada VM como “candidata a reduzir”, “candidata a aumentar” ou “ok”. Ainda assim, não confie cegamente em recomendações automatizadas; valide com o time da aplicação antes de prosseguir.

3. Priorização

Use Pareto. Concentre energia nas 20% das VMs que respondem por 80% do desperdício ou da contenção. Adicionalmente, evite começar pelas aplicações mais críticas: comece pelas VMs de teste, desenvolvimento e homologação para calibrar o processo.

4. Simulação

Quando o hypervisor oferece o recurso, rode “what-if” antes da mudança. O vRealize Operations (Aria Operations) projeta o impacto. Em ambientes sem ferramenta nativa, simule no papel: se a VM hoje tem P95 de 70% em 8 vCPUs, reduzir para 4 vCPUs não resulta em P95 de 140%: a utilização de CPU não escala linearmente nem passa de 100%. O que ocorre é que os cores saturam em ~100%, gerando enfileiramento, maior latência e aumento de CPU Ready. O número de 140% é inválido como projeção; use as ferramentas de simulação para estimar o impacto real.

5. Execução e validação

Mude um lote por janela controlada (5 a 10 VMs por noite). Em seguida, monitore as 72 horas seguintes. Vale destacar que a métrica de sucesso não é “reduzimos N vCPUs”: é “VM mantém SLA com novo dimensionamento”. Sem validação pós-mudança, rightsizing vira aposta. Para o time de FinOps, vale conectar esse trabalho ao ciclo maior de FinOps de virtualização, que dá a visão estratégica de custo do cluster inteiro.

Rightsizing em VMware vSphere

Em VMware vSphere, três aspectos exigem atenção especial. Primeiro, sockets versus cores per socket. A regra de ouro pragmática é manter cores per socket alinhados com o NUMA node físico do host. Um host com dois sockets de 16 cores cada deve hospedar VMs configuradas como 1 socket × 16 cores ou 2 sockets × 16 cores; nunca 16 sockets × 1 core, configuração que destrói o NUMA scheduling.

Segundo ponto: vNUMA. A partir do vSphere 6.5, o vNUMA respeita a topologia configurada na VM. Por isso, VMs com mais de 8 vCPUs devem ter sockets/cores ajustados para refletir o hardware. Caso contrário, o guest OS enxerga uma topologia falsa e o agendador interno toma decisões ruins. Veja o detalhamento na documentação oficial do produto.

Terceiro: o motor de recomendação. O vRealize Operations / Aria Operations entrega recomendações de rightsizing com limites embutidos: redução máxima de 50% e aumento máximo de 100% por ciclo. Acima desses limites, divida em duas operações com 14 dias de observação entre elas.

Hot add e reboot

VMs com Hot Add CPU/Memory habilitado podem crescer sem reboot, mas reduzir sempre exige reboot. Portanto, considere a janela de manutenção no momento da priorização. Para acelerar diagnóstico de impacto, integrar com uma plataforma de monitoramento de VMware consolida métricas pré e pós mudança no mesmo dashboard.

Rightsizing em Microsoft Hyper-V

Em Hyper-V, dois mecanismos mudam a abordagem em relação ao vSphere. O primeiro é o Dynamic Memory: a VM declara mínimo, inicial, máximo e buffer; o hypervisor entrega memória sob demanda. Isso reduz a importância de “acertar a memória exata” e desloca o foco para acertar o teto e o buffer.

O segundo é o agendamento de vCPU. O Hyper-V usa Root Scheduler por padrão em Windows Server 2019+, com isolamento por VM. Em outras palavras, oversubscription excessivo causa menos dano que no vSphere, mas ainda assim mantenha a regra prática de não passar de 4:1 vCPU:pCPU para workloads de produção.

Para identificar candidatas, use o System Center Virtual Machine Manager (SCVMM) com Operations Manager (SCOM) ou Windows Admin Center. Os contadores de Performance Monitor mais relevantes ficam abaixo:

# Contadores essenciais para rightsizing em Hyper-V
Get-Counter -Counter "\Hyper-V Hypervisor Virtual Processor(*)\% Guest Run Time"
Get-Counter -Counter "\Hyper-V Dynamic Memory VM(*)\Average Pressure"
Get-Counter -Counter "\Hyper-V Virtual IDE Controller(*)\Read Bytes/sec"

Pressure médio acima de 80% indica VM operando perto do teto de memória dinâmica. Da mesma forma, Um % Guest Run Time persistentemente abaixo de 15% indica VM superdimensionada (métrica por VM), diferente de oversubscription, que é condição de host/cluster (soma de vCPUs acima dos cores físicos). Em Failover Clustering, valide a capacidade reservada antes de aumentar vCPU em qualquer VM; o nó de destino do failover precisa caber a configuração nova.

Rightsizing em Proxmox VE e KVM

No Proxmox VE, três detalhes pesam mais que em VMware ou Hyper-V. O primeiro é a escolha do CPU type. Configurações como host expõem todos os flags do processador físico (melhor performance, pior portabilidade entre hosts heterogêneos). Já o kvm64 é portável, mas perde features de aceleração. Para rightsizing, fixe o tipo antes de avaliar a baseline.

O segundo é o ballooning. Habilitado por padrão em VMs Linux, ele permite recuperar memória ociosa para o host. Em ambientes onde o ballooning está desligado (workloads de banco que rejeitam a recuperação), o gargalo de memória aparece mais cedo no rightsizing.

O terceiro é a observabilidade. O Proxmox expõe métricas via pvesh e via export para Prometheus/Grafana. Em síntese, a baseline de 30 dias se monta com Node Exporter + Proxmox VE Exporter. Para entender a arquitetura de cluster e datastore que sustenta esse trabalho, vale conferir o guia de Proxmox VE antes de mexer em VMs em produção. A documentação de boas práticas do Proxmox traz também ajustes específicos de IO e CPU.

Quando NÃO fazer rightsizing

Rightsizing não é bala de prata. Em alguns cenários, mexer no dimensionamento causa mais problema do que resolve. Vale destacar os principais:

– Aplicações com perfil burst extremo. Sistemas que ficam horas em 10% e disparam para 95% em 2 minutos (calls inbound, integração batch, web checkout em Black Friday) precisam de headroom. Encolher essas VMs leva a indisponibilidade no exato momento que importa.
– VMs de DR e replicação síncrona. Reduzir vCPU ou RAM pode atrasar a replicação e violar RPO contratual. Ainda assim, valide com o time de DR antes.
– Compliance regulatório. Cargas PCI-DSS, HIPAA ou LGPD podem ter requisitos contratuais de capacidade reservada. Em outras palavras, dimensionamento mínimo está escrito no contrato.
– Licenciamento que exige N vCPUs. Alguns ISVs (Oracle Database, SAP, certos produtos Microsoft) usam vCPU/socket como base de cobrança. Por isso, reduzir vCPU pode quebrar o contrato sem economia real.
– Cluster recém-implantado. Workloads ainda em ramp-up não têm baseline confiável. Espere pelo menos 30 dias antes da primeira rodada de rightsizing.

Em todos esses casos, documente a decisão. Uma exceção sem documentação vira dúvida na próxima rodada de revisão.

Como o monitoramento contínuo acelera o ciclo de rightsizing

O rightsizing manual sustentado é caro. Cada ciclo manual de 30 dias demanda extração de métricas, planilha, reunião com app owners e janela de manutenção. Da mesma forma, sem monitoramento contínuo, o ganho do rightsizing dura apenas até a próxima onda de mudança de workload.

A OpServices opera plataformas que consolidam VMware, Hyper-V e Proxmox em um único dashboard de capacidade. Em outras palavras, a baseline de cada hypervisor sobe sem retrabalho do time interno. O OpMon coleta vCPU usage, ready time, memory balloon, swap, IOPS e latência por VM. Em seguida, dispara alertas automatizados para candidatas a rightsizing quando os thresholds da tabela mais cedo no artigo são atingidos.

Adicionalmente, a baseline contínua permite que rightsizing deixe de ser uma campanha anual e vire um ritual mensal: 10 a 20 VMs ajustadas por mês, sem reuniões de comitê e sem janela de risco. Como resultado, o cluster opera permanentemente próximo do ponto ótimo de densidade. Isso libera espaço para crescimento orgânico do negócio sem novas compras de hardware.

Conclusão

O rightsizing de máquinas virtuais é uma das alavancas mais subutilizadas em ambientes de virtualização. Em síntese, ele transforma a planilha do cluster: VMs deixam de carregar gordura herdada do projeto inicial, hosts ganham capacidade para novos workloads e licenças de hypervisor passam a refletir o consumo real. O resultado prático aparece em CAPEX adiado, OPEX reduzido e desempenho operacional mais previsível.

Vale destacar que rightsizing não é evento, é processo. Sem monitoramento contínuo, sem critérios claros de candidatura e sem ciclos curtos de validação, o ganho desaparece em poucas semanas. Por isso, o caminho mais sustentável combina baseline automatizada, workflow padronizado de execução e validação rigorosa pós-mudança, com calibração específica para VMware, Hyper-V e Proxmox.

Quer estruturar o ciclo de rightsizing do seu cluster com baseline real, sem planilhas manuais? Fale com um especialista OpServices para um diagnóstico do seu ambiente de virtualização.