beautifulsoups.dev
Published on

Azure VM 부팅 실패? Boot Diagnostics로 복구

Authors

운영 중인 Azure VM이 어느 날 갑자기 부팅에 실패하면, 가장 답답한 점은 서버 안으로 들어갈 수 없어서(SSH·RDP 불가) 로그를 볼 수 없다는 것입니다. 이때 Azure가 제공하는 Boot Diagnostics는 VM 내부 에이전트 없이도 스크린샷과 시리얼 로그를 수집해, “어디에서 멈췄는지”를 바깥에서 확인하게 해줍니다.

이 글에서는 Boot Diagnostics를 중심으로, Serial Console, 복구용 VM(디스크 스왑/마운트), 그리고 자주 터지는 부팅 실패 원인별 복구 루트를 하나의 플레이북처럼 정리합니다.

장애 대응 관점에서 로그 기반 추적이 중요하다는 점은 리눅스 접속 장애 분석과도 유사합니다. SSH가 느리거나 끊길 때 auth.log로 원인을 좁히는 방식은 아래 글도 참고하세요.

Boot Diagnostics가 해주는 일과 한계

Boot Diagnostics로 얻을 수 있는 것

  • 부팅 스크린샷: 커널 패닉, initramfs 쉘, Windows 부팅 복구 화면 등 “멈춘 화면”을 즉시 확인
  • 시리얼 로그(Serial log): 콘솔 출력 기반의 초기 부팅 메시지(커널·부트로더·초기 서비스 단계)
  • VM에 로그인 불가해도 동작: 네트워크/SSH/RDP가 죽어도 확인 가능

한계(오해하기 쉬운 부분)

  • 애플리케이션 레벨 로그까지 자동으로 주지 않습니다. Boot Diagnostics는 “부팅 단계”에 강합니다.
  • 시리얼 로그가 항상 충분하진 않습니다. 특히 커널 이후 사용자 공간에서 멈추는 경우, 추가로 Serial Console 접속 또는 디스크 오프라인 마운트가 필요합니다.

1단계: Boot Diagnostics 활성화와 확인 절차

포털에서 확인

  1. Azure Portal에서 VM 선택
  2. Boot diagnostics 메뉴 진입
  3. Enable이 꺼져 있다면 활성화
  4. Screenshot과 Serial log를 확인

Boot Diagnostics는 내부적으로 스토리지에 로그를 저장합니다. 관리형(Managed) 방식으로 켜면 저장소 구성 부담이 줄어듭니다.

Azure CLI로 활성화

아래 예시는 Boot Diagnostics를 켜는 전형적인 형태입니다. 환경에 따라 옵션이 다를 수 있으니, 현재 사용 중인 Azure CLI 버전에 맞춰 az vm boot-diagnostics --help를 확인하세요.

# Boot Diagnostics 활성화(관리형 스토리지 사용)
az vm boot-diagnostics enable \
  --resource-group my-rg \
  --name my-vm

# 상태 확인
a z vm boot-diagnostics get-boot-log \
  --resource-group my-rg \
  --name my-vm

명령 출력에서 부팅 로그 URL 또는 로그 텍스트를 얻을 수 있습니다.

2단계: 스크린샷/시리얼 로그로 “멈춘 지점” 분류하기

Boot Diagnostics에서 가장 중요한 건 “정확한 원인”을 바로 맞히는 게 아니라, 복구 루트를 결정할 만큼만 분류하는 것입니다.

A. 부트로더/커널 단계에서 멈춤

징후:

  • GRUB 프롬프트로 떨어짐
  • Kernel panic 메시지
  • VFS: Unable to mount root fs류의 루트 파일시스템 마운트 실패

가능 원인:

  • /etc/fstab 오타로 인해 루트 또는 필수 마운트 실패
  • initramfs 손상
  • 커널/드라이버 업데이트 후 부팅 불가

B. 사용자 공간(systemd)에서 멈춤

징후:

  • systemd 타임아웃, 특정 서비스에서 무한 대기
  • A start job is running for ...가 길게 지속

가능 원인:

  • 잘못된 네트워크 설정으로 부팅 과정에서 의존 서비스가 타임아웃
  • 디스크 풀(예: LVM/RAID) 조립 실패
  • 마운트 대상(예: NFS)이 부팅에 강하게 묶여 있음

C. Windows 부팅 복구 화면/블루스크린

징후:

  • Automatic Repair 루프
  • 특정 드라이버 관련 오류

가능 원인:

  • 업데이트 이후 부팅 구성 깨짐
  • 시스템 파일 손상

3단계: Serial Console로 추가 진단(로그인 없이도)

Boot Diagnostics로 “어디에서 멈췄는지”를 봤다면, 다음은 Serial Console로 실제 콘솔에 붙어 더 많은 정보를 확인합니다.

Serial Console 활용 포인트

  • 네트워크가 죽어도 콘솔 접속이 가능
  • 리눅스라면 GRUB 편집, 단일 사용자 모드 진입, 긴급 쉘 접근에 유용
  • Windows라면 SAC(Serial Administration Console)로 제한적이지만 복구 커맨드 실행 가능

리눅스에서 흔한 응급 조치 예시

  1. /etc/fstab 문제 의심 시
  • 부팅 중 initramfs 또는 emergency mode로 떨어진다면, 우선 /etc/fstab의 문제 마운트를 nofail로 완화하거나, 임시로 주석 처리 후 재부팅을 시도합니다.
  1. systemd 타임아웃
  • 멈춘 서비스 이름이 보이면, 해당 유닛을 마스킹/비활성화하고 부팅 성공 후 정상화합니다.
# 예: 특정 서비스가 부팅을 막는 경우
sudo systemctl disable my-blocking.service
sudo systemctl mask my-blocking.service

# 부팅 후 원인 분석을 위해 로그 확인
sudo journalctl -xb

4단계: “VM 안으로 못 들어가는” 경우의 정석 — 복구용 VM에 디스크 마운트

Serial Console로도 해결이 안 되거나, 루트 파일시스템 자체가 깨졌다면 가장 확실한 방법은 OS 디스크를 분리해서 다른 VM에 붙여 오프라인으로 수정하는 방식입니다.

복구 절차 개요(리눅스/윈도 공통)

  1. 장애 VM을 정지(Stop)
  2. OS 디스크를 분리(Detach)
  3. 별도의 복구 VM(같은 리전 권장)에 데이터 디스크로 Attach
  4. 복구 VM에서 마운트 후 설정/파일 수정
  5. 원래 VM에 디스크를 다시 Attach
  6. 부팅 테스트

리눅스에서 디스크 마운트 예시

복구 VM에서 디스크가 /dev/sdc로 붙었다고 가정합니다.

# 파티션 확인
lsblk

# 예: 루트 파티션이 /dev/sdc2 라면
sudo mkdir -p /mnt/rescue
sudo mount /dev/sdc2 /mnt/rescue

# 부트 관련 수정 시 chroot가 유용
sudo mount --bind /dev /mnt/rescue/dev
sudo mount --bind /proc /mnt/rescue/proc
sudo mount --bind /sys /mnt/rescue/sys
sudo chroot /mnt/rescue /bin/bash

# 예: fstab 확인
cat /etc/fstab

# 예: GRUB 재생성(배포판에 따라 다름)
update-grub || grub2-mkconfig -o /boot/grub2/grub.cfg
exit

# 마운트 해제
sudo umount -R /mnt/rescue

chroot로 들어가면 “원래 VM 안에서 작업하는 것처럼” 패키지/부트 설정을 정리할 수 있습니다.

5단계: 원인별 복구 시나리오(실전에서 많이 터짐)

시나리오 1) /etc/fstab 오타로 부팅 실패

특징:

  • 시리얼 로그에 마운트 실패와 함께 emergency mode 진입
  • 화면에 You are in emergency mode 류 메시지

복구:

  • 오프라인 마운트 후 /etc/fstab에서 문제 라인을 주석 처리
  • 네트워크/NFS 마운트는 nofail, x-systemd.automount, x-systemd.device-timeout 등을 고려
# 예: 부팅을 막는 NFS 마운트를 완화
# (실제 파일에서는 주석이 아니라 옵션을 조정)
# server:/share /mnt/share nfs defaults,nofail,x-systemd.automount,x-systemd.device-timeout=10 0 0

시나리오 2) 커널 업데이트 후 부팅 불가

특징:

  • 커널 패닉
  • 특정 커널 버전에서만 실패

복구:

  • GRUB에서 이전 커널로 부팅
  • 부팅 성공 후 문제 커널 제거 또는 initramfs 재생성
# Debian/Ubuntu 계열 예시
uname -r
sudo apt-get remove --purge linux-image-문제버전
sudo update-initramfs -u
sudo update-grub

시나리오 3) 디스크 용량 100%로 인한 부팅/로그인 실패

특징:

  • 부팅은 되지만 서비스가 제대로 안 뜨거나, SSH가 거부
  • systemd 서비스가 파일 생성 실패로 연쇄 장애

복구:

  • 오프라인 마운트 후 불필요 로그/캐시 정리
  • 재부팅 후 용량 모니터링/로그 로테이션 강화
# 오프라인 마운트 상태에서 예시
sudo du -sh /mnt/rescue/var/log/* | sort -h | tail
sudo rm -f /mnt/rescue/var/log/큰파일.log

시나리오 4) 네트워크 설정 꼬임으로 SSH·RDP 불가

특징:

  • 부팅 자체는 완료됐는데 접속만 안 됨
  • Boot Diagnostics 스크린샷은 정상 로그인 프롬프트까지 도달

복구 방향:

  • NSG, UDR, NIC, 공인 IP, 방화벽부터 점검
  • 게스트 OS 네트워크 설정 파일이 깨졌다면 오프라인 수정

이 케이스는 “부팅 실패”라기보다 “접속 실패”에 가깝지만, 현장에서는 동일한 증상으로 들어오는 경우가 많습니다.

6단계: 재발 방지 체크리스트

1) 부팅 관측성 확보

  • Boot Diagnostics는 기본적으로 켜두기
  • Serial Console 사용 가능하도록 정책/권한 정리

2) 변경 전 스냅샷/백업

  • 커널 업데이트, 디스크 파티션 변경, 네트워크 대수술 전에는 스냅샷 또는 백업

3) 장애 대응 런북 자동화

  • “디스크 분리 후 복구 VM에 부착” 같은 반복 작업은 문서화가 곧 자동화의 시작입니다.

  • CI/CD나 운영 자동화에서 캐시/상태 때문에 예기치 않은 실패가 반복되듯, 인프라 복구도 체크리스트가 없으면 같은 실수를 반복합니다. 운영 자동화 관련 관점은 아래 글도 도움이 됩니다.

  • GitHub Actions 캐시 미스 원인 7가지와 해결

부록: 장애 시 바로 쓰는 최소 명령 모음

VM 상태/부팅 로그 확인

# VM 상태 보기
az vm get-instance-view -g my-rg -n my-vm \
  --query "instanceView.statuses" -o table

# Boot Diagnostics 로그(가능한 경우)
az vm boot-diagnostics get-boot-log -g my-rg -n my-vm

디스크 분리/부착(개념 예시)

실제 운영에서는 디스크 리소스 이름과 LUN, 캐싱 설정을 정확히 확인해야 합니다.

# OS 디스크 이름 확인
az vm show -g my-rg -n my-vm --query "storageProfile.osDisk.managedDisk.id" -o tsv

# (개념) 데이터 디스크로 복구 VM에 부착
az vm disk attach -g my-rg --vm-name rescue-vm --name my-os-disk --lun 10

마무리

Azure VM 부팅 실패는 원인이 다양하지만, 대응 흐름은 의외로 단순합니다.

  1. Boot Diagnostics로 멈춘 지점을 확인하고
  2. Serial Console로 즉시 조치 가능한지 판단한 뒤
  3. 안 되면 디스크를 떼어 복구 VM에서 오프라인으로 고친다

이 3단계가 몸에 익으면, SSH·RDP가 끊긴 상태에서도 “감”이 아니라 “증거(스크린샷/로그)”로 복구를 진행할 수 있습니다.

Discuss on Twitter • View on GitHub