Troubleshooting Hyper-v Real: A VM Travada em "Mesclando" Depois de um Checkpoint Mal Resolvido

VM em Hyper-V travada durante o processo de mesclagem devido a espaço em disco insuficiente, destacando a importância de diagnósticos e ações preventivas para evitar futuros incidentes.

Depois de fechar a série de fundamentos do Hyper-V, começo agora uma linha mais prática: incidentes reais, do jeito que eles realmente acontecem — com pressão, informação incompleta, e a necessidade de diagnosticar rápido sem piorar a situação.

O cenário de hoje é um clássico que, se você administra Hyper-V há tempo suficiente, provavelmente já viveu (ou vai viver): uma VM trava em "Mesclando" (Merging) depois da exclusão de um checkpoint, e simplesmente não sai desse estado — nem a VM responde, nem o processo avança.

O Cenário

Uma sexta-feira à tarde, típica: um administrador exclui um checkpoint antigo de uma VM de produção, criado antes de um patch aplicado há duas semanas. Rotina de limpeza, nada incomum.

Minutos depois, a VM aparece no Hyper-V Manager com o status "Mesclando" (Merging) — e fica assim. Sem avançar. A VM continua rodando (ainda bem), mas qualquer tentativa de desligá-la, pausá-la ou até mesmo abrir o console trava a interface.

Isso é exatamente o tipo de situação onde entender como o merge funciona por dentro (vimos isso no artigo de gerenciamento de VMs) faz toda a diferença entre resolver em 10 minutos ou em 3 horas.

Passo 1: Entender o Que Está Realmente Acontecendo

Antes de qualquer ação, relembrando o mecanismo: quando você exclui um checkpoint, o Hyper-V precisa mesclar as alterações armazenadas naquele disco diferencial (.avhdx) de volta ao disco pai. Isso é uma operação de I/O intensa — o Hyper-V literalmente copia bloco por bloco as diferenças acumuladas para o disco original.

O merge pode travar ou ficar extremamente lento por alguns motivos bem específicos:

1. Falta de espaço em disco — o motivo mais comum, de longe. O merge precisa de espaço temporário equivalente ao tamanho das alterações a serem mescladas; se o storage está quase cheio, a operação trava no meio.

2. I/O do storage sobrecarregado — se o array físico já está no limite de IOPS (outras VMs competindo pelo mesmo storage), o merge, sendo uma operação pesada, pode demorar horas em vez de minutos.

3. Corrupção na cadeia de checkpoints — se um dos discos diferenciais na cadeia está corrompido, o merge pode travar indefinidamente tentando processar um bloco inválido.

4. Cluster com CSV em estado inconsistente — em ambientes de cluster, se o CSV não está completamente saudável em todos os nós, operações de merge podem ficar "penduradas" esperando coordenação que nunca completa.

   
   

Passo 2: Diagnóstico — Onde Olhar Primeiro

Verificar Espaço em Disco (Sempre o Primeiro Passo)

powershell

Get-PSDrive -PSProvider FileSystem | Select-Object Name, @{N="FreeGB";E={[math]::Round($_.Free/1GB,2)}}, @{N="UsedGB";E={[math]::Round($_.Used/1GB,2)}}

No nosso cenário: storage com apenas 2 GB livres, numa VM cujo disco diferencial acumulado passava de 40 GB (o checkpoint excluído tinha quase duas semanas de alterações acumuladas de um servidor de aplicação bastante ativo). Causa raiz identificada já no primeiro comando.

Confirmar o Estado Real do Merge

powershell

Get-VM -Name "SRV-APP03" | Select-Object Name, Status, State
Get-VMHardDiskDrive -VMName "SRV-APP03" | Select-Object Path

O segundo comando é importante: ele mostra se o Hyper-V ainda está referenciando o disco diferencial (.avhdx) ou já voltou a apontar para o disco pai (.vhdx) — isso indica em que ponto exato o merge parou.

Verificar o Log de Eventos do Hyper-V-VMMS

Visualizador de Eventos > Aplicativos e Serviços > Microsoft > Windows > Hyper-V-VMMS > Admin

Procure por eventos relacionados a "Merge" ou "Background Disk Merge" — eles costumam indicar exatamente em qual arquivo e em que porcentagem o processo travou, além de erros específicos (como 0x80070070 — exatamente o código de "espaço em disco insuficiente").

Dica de especialista: 0x80070070 nesse contexto é tão comum que, depois de um tempo administrando Hyper-V, você reconhece o código de cabeça. Vale ter ele anotado em algum runbook pessoal — economiza buscas desesperadas no Google às 2h da manhã.

Passo 3: Resolvendo — Liberando Espaço Com Segurança

Aqui está o ponto crítico: não tente forçar o cancelamento do merge ou desligar a VM bruscamente. Isso pode deixar a cadeia de discos diferenciais em estado inconsistente, transformando um problema de espaço em disco (resolvível) em corrupção de dados (muito pior).

Primeiro: Identificar Espaço Liberável Rapidamente

powershell

# Verificar se há outros checkpoints "esquecidos" na mesma VM ou em VMs vizinhas no mesmo volume
Get-VM | Get-VMCheckpoint | Select-Object VMName, Name, CreationTime, Path

No nosso cenário, encontramos três checkpoints antigos esquecidos em outras VMs do mesmo volume de storage — exatamente o tipo de acúmulo que alertei lá no artigo de gerenciamento de VMs. Removê-los (de VMs que não estavam no meio de nenhuma operação) liberou espaço suficiente.

Se Não Houver Espaço Liberável Rapidamente

Quando não há gordura óbvia para cortar, as opções seguintes, em ordem de preferência:

1. Mover outros arquivos não essenciais do mesmo volume temporariamente (logs antigos, ISOs não utilizadas) para outro storage

2. Adicionar espaço ao volume, se for um array expansível (muitos ambientes modernos com storage virtualizado permitem expansão a quente)

3. Em último caso, mover outras VMs menos críticas do mesmo volume para outro storage via Storage Live Migration — mas isso só é viável se o storage ainda tiver I/O suficiente disponível para suportar mais uma operação pesada simultânea, o que nem sempre é o caso quando você já está travado por falta de espaço.

   
   

Confirmando que o Merge Retomou

Depois de liberar espaço, o merge geralmente retoma automaticamente — o Hyper-V não abandona a operação, apenas fica bloqueado esperando recursos. Monitore:

powershell

# Repita periodicamente para acompanhar o progresso
Get-VMHardDiskDrive -VMName "SRV-APP03" | Select-Object Path

Quando o Path voltar a apontar para o .vhdx principal (sem mais referência ao .avhdx), o merge foi concluído com sucesso.

Passo 4: E Se o Merge Realmente Não Retomar Sozinho?

Em casos mais raros, mesmo depois de liberar espaço, o merge pode não retomar automaticamente — geralmente sinal de que o processo em si travou (não só esperando recursos). Nesse caso:

powershell

# Reiniciar o serviço de gerenciamento de VMs do host (NÃO desliga as VMs em execução)
Restart-Service -Name vmms -Force

Importante: reiniciar o serviço VMMS (Virtual Machine Management Service) não interrompe VMs já em execução — ele gerencia a camada de orquestração, não o processo de execução das VMs em si. É uma ação relativamente segura mesmo em produção, mas ainda assim vale fazer em janela de menor impacto quando possível, já que pode haver uma breve interrupção de responsividade do Hyper-V Manager durante o restart.

Depois do restart do serviço, o Hyper-V geralmente detecta a operação de merge pendente e a retoma do ponto onde parou.

O Que Aprendemos (E Como Evitar da Próxima Vez)

Esse incidente específico tem uma causa raiz simples — falta de espaço — mas o verdadeiro problema não era técnico, era de processo: ninguém estava monitorando o crescimento dos checkpoints acumulados naquele volume.

Monitoramento Proativo que Evita Esse Cenário

powershell

# Script simples para rodar periodicamente (via Scheduled Task) e alertar sobre checkpoints antigos
$checkpointsAntigos = Get-VM | Get-VMCheckpoint | Where-Object {$_.CreationTime -lt (Get-Date).AddDays(-7)}

if ($checkpointsAntigos) {
    $checkpointsAntigos | Select-Object VMName, Name, CreationTime | 
        Export-Csv -Path "C:\Scripts\checkpoints_antigos.csv" -NoTypeInformation
    # Aqui você integraria com seu sistema de alerta (e-mail, Teams, etc.)
}

Monitoramento de Espaço em Disco com Margem de Segurança Real

Não espere o storage chegar a 2 GB livres para agir. Um threshold de alerta em 20-25% de espaço livre (não 5-10%, que é tarde demais para operações de merge de VMs grandes) dá tempo real de reação antes que vire incidente.

Conclusão

Esse tipo de incidente — simples na causa, mas angustiante no momento, especialmente numa sexta à tarde — reforça algo que já apareceu antes na série: a diferença entre um ambiente que "funciona até dar problema" e um que é administrado de verdade está no monitoramento proativo de coisas chatas, como espaço em disco e checkpoints acumulados. Ninguém gosta de configurar alerta de "20% de espaço livre" até precisar dele numa sexta às 17h.

Se você já passou por um incidente parecido (ou diferente) em Hyper-V que valeria virar um artigo da série, me conta — essa coluna de troubleshooting vai continuar sendo alimentada por situações reais.