VM Azure Não Inicializa? Troubleshooting com Boot Diagnostics

Uma VM Azure não inicializa, o SSH dá timeout, o portal mostra a máquina como running — e você não tem a menor ideia do que está acontecendo lá dentro. Esse é um dos incidentes mais comuns (e mais estressantes) da operação em nuvem, porque o caminho normal de acesso à máquina simplesmente não existe mais.

Neste tutorial você vai ver, na prática, o que fazer quando a VM Azure não inicializa: diagnosticar e corrigir, de ponta a ponta, a vm-bootdiag-03 do mesmo laboratório do artigo Ativar Boot Diagnostics em Todas as VMs do Azure com Python. Vamos usar os três recursos que o Boot Diagnostics destrava — a screenshot do console, o log serial e o Serial Console — para descobrir a causa (um fstab quebrado), corrigir e validar o boot, tudo com outputs reais.

Sumário

• O cenário: a VM que parou de responder
• Passo 1 — Screenshot do console
• Passo 2 — Ler o log serial pela CLI
• Passo 3 — Acessar a VM pelo Serial Console
• Passo 4 — Corrigir o fstab e reiniciar
• Passo 5 — Validar o boot
• VM Azure não inicializa: casos comuns
• Troubleshooting das próprias ferramentas
• Limpeza dos recursos
• Conclusão
• Referências oficiais

O cenário: a VM que parou de responder

O laboratório é o mesmo do artigo anterior: resource group rg-bootdiag-lab-eus (East US) com 5 VMs Ubuntu 22.04 Standard_B1s, todas com Boot Diagnostics habilitado no modo gerenciado. Durante uma manutenção, um disco de dados foi desanexado da vm-bootdiag-03 — mas a entrada correspondente ficou para trás no /etc/fstab. No reboot seguinte, o SSH parou de responder:

$ ssh azureuser@10.0.0.6
ssh: connect to host 10.0.0.6 port 22: Connection timed out

$ az vm get-instance-view -g rg-bootdiag-lab-eus -n vm-bootdiag-03 \
    --query "instanceView.statuses[].displayStatus" -o tsv
Provisioning succeeded
VM running

Repare no detalhe que confunde muita gente: para a plataforma, está tudo bem — o hypervisor reporta VM running porque a máquina de fato está ligada. Quando a VM Azure não inicializa por um problema dentro do sistema operacional, nenhuma métrica de infraestrutura vai acusar o erro. É exatamente aqui que o Boot Diagnostics entra.

Passo 1 — Screenshot do console

No portal, abra a VM e navegue até Ajuda → Boot diagnostics. A screenshot capturada (reproduzida abaixo, direto do laboratório) mostra imediatamente que a máquina não travou — ela caiu no emergency mode do systemd, aguardando intervenção:

Em 30 segundos você já sabe que não é um problema de rede, de NSG nem de agente: o boot foi interrompido pelo próprio sistema. Sem essa captura, quando a VM Azure não inicializa a investigação começaria no escuro — provavelmente por um redeploy desnecessário. Mas a screenshot ainda não diz por que o sistema caiu em emergência; para isso, o log serial é mais completo.

Passo 2 — Ler o log serial pela CLI

O log serial registra tudo que o kernel e o systemd escreveram durante o boot — é a fonte mais rica de pistas quando a VM Azure não inicializa. Dá para baixá-lo sem sair do terminal:

$ az vm boot-diagnostics get-boot-log \
    -g rg-bootdiag-lab-eus -n vm-bootdiag-03

[  OK  ] Mounted /boot/efi.
[ TIME ] Timed out waiting for device /dev/disk/by-uuid/8f3ab1c2-77d4-4be1-9a30-51fa2c9e7d10.
[DEPEND] Dependency failed for /dados.
[DEPEND] Dependency failed for Local File Systems.
[  OK  ] Reached target Timer Units.
[  OK  ] Started Emergency Shell.
[  OK  ] Reached target Emergency Mode.
[  OK  ] Reached target Network is Online.
[  OK  ] Reached target Cloud-init target.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

Diagnóstico fechado: o systemd esperou 90 segundos pelo disco de UUID 8f3ab1c2-... (o disco de dados removido na manutenção), a montagem de /dados falhou e, como a entrada no fstab não tinha a opção nofail, a falha derrubou o alvo Local File Systems — que é dependência do boot normal. Repare num detalhe curioso do log real: alvos de rede como Network is Online ainda são alcançados — mas o multi-user.target (onde vivem o SSH e o agente da VM) nunca sobe. É por isso que a máquina “tem rede” e mesmo assim ninguém entra nela. A saída é o Serial Console.

Passo 3 — Acessar a VM pelo Serial Console

O Serial Console conecta você direto à porta serial da VM, sem depender de rede nem de SSH — e o único pré-requisito dele é justamente o Boot Diagnostics estar ativo. Use o portal (Ajuda → Serial console) ou a CLI:

$ az serial-console connect -g rg-bootdiag-lab-eus -n vm-bootdiag-03

+-----------------------------------------------+
Connected to the serial port of the VM.
If no login prompt is displayed, press ENTER.
+-----------------------------------------------+

Give root password for maintenance
(or press Control-D to continue): ********
root@vm-bootdiag-03:~#

Um Enter na tela de manutenção e você tem um shell de root na máquina que “não respondia”. Se a sua VM Azure não inicializa e o Serial Console aparecer desabilitado, quase sempre é porque o Boot Diagnostics não foi ativado — o script Python do artigo anterior resolve isso para todas as VMs de uma vez.

Passo 4 — Corrigir o fstab e reiniciar

Dentro do shell de emergência, confirme por que a VM Azure não inicializa e aplique a correção. Aqui vamos comentar a linha órfã; se o disco ainda existisse, a alternativa correta seria adicionar a opção nofail:

root@vm-bootdiag-03:~# grep dados /etc/fstab
UUID=8f3ab1c2-77d4-4be1-9a30-51fa2c9e7d10  /dados  ext4  defaults  0  2

# Comenta a entrada do disco que não existe mais
root@vm-bootdiag-03:~# sed -i 's|^UUID=8f3ab1c2|# &|' /etc/fstab

# Valida que o fstab restante monta sem erros
root@vm-bootdiag-03:~# mount -a && echo FSTAB_OK
FSTAB_OK

root@vm-bootdiag-03:~# systemctl reboot
# (se o prompt continuar vivo após alguns segundos, force:)
root@vm-bootdiag-03:~# sync && reboot -f

O mount -a antes do reboot é a rede de segurança: ele processa o fstab inteiro e devolve erro na hora se ainda houver algo quebrado — muito melhor descobrir agora, com o shell aberto, do que no próximo boot. E um detalhe que só aparece na prática: no shell de emergência o systemd está em estado degradado, e o systemctl reboot pode simplesmente não responder — foi o que aconteceu no nosso laboratório. Se o prompt continuar vivo, o reboot -f resolve na hora.

Passo 5 — Validar o boot

Dois minutos depois, o mesmo comando que revelou o problema confirma a solução — o log serial agora termina no prompt de login, e o SSH voltou:

$ az vm boot-diagnostics get-boot-log \
    -g rg-bootdiag-lab-eus -n vm-bootdiag-03

Welcome to Ubuntu 22.04.5 LTS!
[  OK  ] Reached target Preparation for Local File Systems.
[  OK  ] Reached target Local File Systems.
vm-bootdiag-03 login:

$ az vm run-command invoke -g rg-bootdiag-lab-eus -n vm-bootdiag-03 \
    --command-id RunShellScript \
    --scripts "uptime; systemctl is-system-running" \
    --query "value[0].message" -o tsv

 17:57:03 up 1 min,  0 users,  load average: 0.80, 0.34, 0.12
running

O Local File Systems — exatamente o alvo que falhava — agora passa, o log termina no prompt de login e o systemctl is-system-running responde running. Do timeout de SSH à causa raiz corrigida, foram cinco comandos — nenhum redeploy, nenhum snapshot de disco de resgate, nenhum ticket de suporte. Esse é o retorno prático de ter o recurso habilitado antes do incidente.

VM Azure não inicializa: casos comuns

O fstab quebrado é só um exemplo. Quando uma VM Azure não inicializa, estes são os padrões que a screenshot e o log serial mais denunciam:

A última linha da tabela merece destaque: a screenshot também é valiosa quando está normal, porque elimina metade das hipóteses — se o sistema subiu até o login, pare de investigar boot e vá direto para rede e serviços.

Troubleshooting das próprias ferramentas

Nem sempre o obstáculo é só a VM: quando a VM Azure não inicializa e as próprias ferramentas de diagnóstico emperram, estes são os ajustes mais comuns:

Limpeza dos recursos

Se você montou o laboratório apenas para este teste, apague tudo com um comando. Mas, se pretende acompanhar o próximo artigo da série — onde uma Azure Policy passa a ativar o Boot Diagnostics automaticamente em toda VM nova —, vale manter o resource group de pé:

az group delete --name rg-bootdiag-lab-eus --yes --no-wait

Conclusão

Quando uma VM Azure não inicializa, o roteiro vencedor é sempre o mesmo: screenshot para classificar o problema, log serial para achar a causa raiz e Serial Console para corrigir — nesta ordem, do mais barato ao mais invasivo. No nosso caso, um fstab órfão que derrubava o boot foi identificado e corrigido em minutos, sem redeploy e sem perda de dados. Nada disso, porém, funciona se o Boot Diagnostics não estiver ativo antes do incidente: é por isso que a ativação em massa que fizemos no artigo anterior é o passo zero deste guia. E para garantir que nenhuma VM nova nasça sem o recurso, o próximo artigo fecha o ciclo com uma Azure Policy de remediação automática.

Referências oficiais

• Boot diagnostics para VMs do Azure (Microsoft Learn)
• Azure Serial Console (Microsoft Learn)
• Serial Console, GRUB e single user mode no Linux (Microsoft Learn)
• az vm boot-diagnostics — referência da CLI (Microsoft Learn)

Interessado em saber mais sobre artigos relacionados ao Microsoft Azure CLIQUE AQUI

Este guia técnico é exclusivo do Blog do Castilho. Explore mais conteúdos sobre Cloud e DevOps.