beautifulsoups.dev
Published on

Azure VM 부팅불가, Serial Console로 복구하기

Authors

운영 중인 Azure VM이 갑자기 부팅 단계에서 멈추거나, 네트워크는 살아있는 것처럼 보이는데 SSH나 RDP가 전혀 붙지 않는 상황은 생각보다 자주 발생합니다. 커널 업데이트 후 부팅 실패, fstab 오타로 인한 마운트 실패, 디스크 용량 100%로 인한 서비스 장애, 방화벽 규칙 변경으로 인한 원격 접속 불가 등 원인은 다양하지만 공통점이 하나 있습니다.

바로 “네트워크로 접속해서 고치기 어렵다”는 점입니다. 이때 가장 먼저 떠올려야 하는 도구가 Azure Serial Console입니다. 콘솔 레벨에서 로그인해 부팅 로그를 확인하고, 파일을 수정하고, 서비스 상태를 점검하며, 필요하면 안전 모드에 준하는 조치까지 할 수 있습니다.

이 글에서는 Azure VM 부팅불가 상황에서 Serial Console을 이용해 진단하고 복구하는 실전 절차를 단계별로 정리합니다. Boot Diagnostics 기반 복구 흐름도 함께 알고 있으면 더 빠르게 판단할 수 있으니, 필요하면 Azure VM 부팅 불가? Boot Diagnostics로 복구도 같이 참고하세요.

Serial Console이 필요한 대표 증상

다음 중 하나라도 해당하면 Serial Console이 유효한 선택지입니다.

  • VM이 running 상태인데 SSH 또는 RDP가 타임아웃
  • 부팅 중 커널 패닉, initramfs 드롭, systemd emergency 모드로 떨어짐
  • 네트워크 설정 오류로 IP가 안 잡히거나 방화벽이 막힘
  • fstab 오류로 루트 또는 데이터 디스크 마운트 실패
  • 디스크 용량 100%로 SSH 로그인 자체가 실패하거나 서비스가 연쇄적으로 다운

Serial Console은 네트워크 경로가 아니라 Azure 호스트 측 콘솔 채널을 통해 접근하므로, VM 내부 네트워크가 망가져도 접근 가능한 경우가 많습니다.

사전 조건과 주의사항

Serial Console을 쓰기 전에 다음을 확인해야 합니다.

1) Azure Serial Console 사용 조건

  • VM에서 Boot diagnostics가 활성화되어 있어야 하는 경우가 많습니다(환경에 따라 정책으로 강제되기도 함).
  • VM이 Azure Resource Manager 기반이어야 하며, 권한은 최소 VM Contributor 수준 이상이 필요합니다.
  • 게스트 OS에서 콘솔 로그인이 가능해야 합니다.

2) 계정 접근 전략

Serial Console에서 로그인하려면 로컬 계정 또는 OS 사용자 계정이 필요합니다.

  • Linux: 일반적으로 로컬 사용자로 로그인 가능
  • Windows: SAC 채널(특수 콘솔)로 들어가 명령을 실행하는 방식이며, 설정에 따라 접근성이 달라짐

운영 표준으로 “콘솔용 break-glass 계정”을 준비하고, 비밀번호 정책 및 감사 로그 정책을 갖추는 것을 권장합니다.

Azure Portal에서 Serial Console 접속

  1. Azure Portal에서 대상 VM 리소스로 이동
  2. 왼쪽 메뉴에서 Serial console 선택
  3. 콘솔이 열리면 로그인 프롬프트를 확인

Linux의 경우 보통 TTY 로그인 화면이 보입니다. 부팅이 완전히 안 된 상태라면 커널 메시지나 systemd 로그가 그대로 출력될 수 있습니다.

1단계: 부팅 로그와 현재 모드 확인

부팅이 멈춘 지점부터 확인합니다.

Linux에서 자주 보는 단서

  • You are in emergency mode 또는 Dependency failed for /...
  • Failed to mount /...
  • fsck 관련 메시지
  • No space left on device

로그 확인은 상황에 따라 아래를 활용합니다.

# 최근 부팅 로그 확인
journalctl -b -0 -xe

# 이전 부팅(업데이트 직후 실패했을 때 유용)
journalctl -b -1 -xe

# 커널 메시지
dmesg -T | tail -n 200

부팅이 아예 완료되지 않았는데 쉘이 떨어진다면(예: emergency mode), 그 자체가 이미 강력한 힌트입니다. 대개 fstab, 파일시스템, 디스크 문제로 이어집니다.

2단계: fstab 오타로 인한 부팅 실패 복구

가장 흔한 케이스 중 하나가 fstab 잘못 편집입니다. 특히 UUID를 잘못 넣거나, 존재하지 않는 디바이스를 필수 마운트로 지정하면 systemd가 부팅을 중단시키기도 합니다.

현재 마운트/블록 디바이스 확인

lsblk -f
blkid
mount | head

fstab 점검 및 임시 완화

sudo nano /etc/fstab

수정 포인트:

  • 존재하지 않는 UUID 또는 디바이스 경로를 올바르게 변경
  • 부팅 필수 마운트가 아니라면 nofail 옵션을 추가해 부팅을 진행시키기
  • 네트워크 파일시스템(NFS 등)이라면 _netdev 및 타임아웃 옵션 검토

예시:

# 실패해도 부팅을 막지 않도록 처리
UUID=xxxx-xxxx  /data  ext4  defaults,nofail,x-systemd.device-timeout=10  0  2

수정 후에는 마운트 검증을 먼저 합니다.

sudo mount -a
echo $?

오류가 0이면 일단 부팅을 막는 큰 장애물은 제거된 것입니다. 이후 재부팅합니다.

sudo reboot

3단계: 디스크 용량 100%로 인한 장애 복구

디스크가 꽉 차면 SSH 로그인부터 실패하거나, systemd가 서비스 시작을 못 하면서 부팅이 지연될 수 있습니다.

용량 확인

df -h
sudo du -xhd1 /var | sort -h | tail -n 30

빠르게 공간 확보하기

  • journald 로그 정리
sudo journalctl --disk-usage
sudo journalctl --vacuum-time=7d
  • 패키지 캐시 정리(Ubuntu 예시)
sudo apt-get clean
sudo apt-get autoremove -y
  • 큰 로그 파일 트렁케이트
sudo ls -lh /var/log | tail
sudo truncate -s 0 /var/log/syslog
sudo truncate -s 0 /var/log/auth.log

공간이 확보되면 서비스가 정상화되고, 네트워크 로그인도 회복되는 경우가 많습니다.

4단계: 네트워크 설정 오류로 SSH 불가 복구

Serial Console이 빛을 발하는 또 다른 케이스가 네트워크 설정을 망가뜨린 경우입니다. 예를 들어 netplan YAML 오타, NIC 설정 변경, 방화벽 정책 변경 등입니다.

IP 및 라우팅 확인

ip addr
ip route
cat /etc/resolv.conf

netplan 검증 및 롤백(Ubuntu)

sudo netplan try
# 문제가 있으면 자동 롤백되도록 시간을 두고 확인

sudo netplan apply

netplan try는 일정 시간 내 확인을 못 하면 자동으로 되돌리는 방식이라, 원격 환경에서 특히 안전합니다.

방화벽 확인

sudo ufw status verbose
sudo iptables -S | head

SSH 포트가 막혔다면 임시로 허용한 뒤 규칙을 재정리합니다.

sudo ufw allow 22/tcp

5단계: 부팅 로더/커널 업데이트 후 부팅 실패 대응

커널 업데이트 후 부팅이 안 되면, GRUB에서 이전 커널로 부팅하거나 initramfs 문제를 해결해야 합니다. Serial Console에서 GRUB 메뉴 조작이 가능할 때도 있지만, 콘솔 입력 타이밍이 까다로운 편입니다.

부팅이 어느 정도 진행되어 쉘을 얻었다면 다음을 점검합니다.

uname -a
ls -1 /boot | tail -n 50
sudo update-initramfs -u
sudo update-grub

커널 패키지 자체가 깨졌다면, 마지막으로 정상 동작했던 커널을 기본값으로 설정하는 접근도 고려합니다. 다만 이 단계는 배포판/부트로더 구성에 따라 리스크가 커질 수 있으므로, 변경 전 스냅샷 또는 디스크 백업을 권장합니다.

Windows VM에서의 접근 포인트(요약)

Windows는 Linux처럼 TTY 로그인 후 파일을 바로 고치는 흐름이 아니라, SAC(Special Administration Console) 또는 CMD 채널을 통해 복구 명령을 실행하는 형태가 일반적입니다.

실무에서 자주 하는 작업은 다음입니다.

  • 네트워크 스택/방화벽 정책 점검
  • 드라이버 또는 업데이트 롤백
  • 부팅 구성 데이터 점검

다만 Windows 복구는 케이스별 분기(도메인 조인, BitLocker, 정책 등)가 커서, Serial Console만으로 해결이 어려우면 Azure의 복구 VM(디스크 분리 후 다른 VM에 연결) 패턴도 함께 준비하는 것이 안전합니다.

복구 후 반드시 해야 할 재발 방지 체크리스트

장애를 고쳤다고 끝이 아닙니다. 같은 유형의 부팅불가가 다시 나지 않도록 “원인 제거”까지 마무리해야 합니다.

  • 변경 작업 전후로 cloud-init, netplan, fstab 등 핵심 파일에 대한 형상 관리 또는 백업
  • 커널/에이전트 업데이트는 점진 배포 및 재부팅 윈도우 확보
  • 디스크 사용량 알람(예: 80%, 90%, 95%)과 로그 로테이션 정책 점검
  • break-glass 계정과 접근 통제(권한 최소화, 감사 로그)
  • Boot Diagnostics 스크린샷/로그 수집 자동화

운영 자동화 관점에서 “경합 조건 때문에 상태가 꼬이는 문제”도 종종 장애를 키웁니다. 배포나 런북을 GitHub Actions로 돌리고 있다면 동시 실행 제어도 함께 점검하세요. 관련해서는 GitHub Actions 동시 실행 경합으로 캐시 깨질 때 글이 참고가 됩니다.

마무리: Serial Console은 최후가 아니라 ‘표준 복구 경로’

Azure VM 부팅불가 상황에서 Serial Console은 마지막 수단이 아니라, 네트워크 경로가 끊겼을 때 가장 빠르고 안전하게 “내부 상태를 직접 확인”할 수 있는 표준 복구 경로에 가깝습니다.

정리하면,

  • 부팅 실패 원인의 상당수는 fstab, 디스크 용량, 네트워크 설정, 커널 업데이트로 수렴합니다.
  • Serial Console로 로그인해 로그를 확인하고, 최소 변경으로 부팅을 통과시키는 것이 1차 목표입니다.
  • 이후 근본 원인 제거(정책, 자동화, 알람, 롤백 전략)까지 포함해야 재발을 줄일 수 있습니다.

다음 장애 때 “포털에서 콘솔 열기”가 바로 손에 익도록, 평상시에 테스트 VM에서 Serial Console 접속과 기본 점검 커맨드를 한 번 런북으로 만들어 두는 것을 권장합니다.

Discuss on Twitter • View on GitHub