Cloud Operations

VM 부팅 복구: VM이 커널 단계에서 멈출 때 - 모니터링 수집 관점

VM이 커널 단계에서 멈출 때를 모니터링 수집 관점에서 좁혀 보는 케이스. Guest Boot 계층의 증상, 확인 명령, 조치 전 판단, 복구 기준을 정리했다.

devmes

• 조회 176

이 글은 VM 부팅 복구: VM이 커널 단계에서 멈출 때 - 모니터링 수집 관점 케이스를 다룬다. 핵심은 VM이 커널 단계에서 멈출 때를 모니터링 수집 관점에서 좁혀 보는 케이스다.

수집한 운영 단서에서 고객명, 내부 주소, 노드명을 제거하고 장애 흐름과 확인 순서만 남겼다.

VM이 켜지지 않는다는 말은 platform 장애일 수도 있고, guest OS의 부팅 장애일 수도 있다. 운영자는 console에서 보이는 화면과 hypervisor의 power state를 분리해서 원인을 좁혀야 한다.

부팅 실패는 cloud platform 장애처럼 접수되지만 실제 원인은 guest OS 내부에 있는 경우가 많다. kernel, boot loader, filesystem을 건드리는 복구는 되돌리기 어려우므로 먼저 snapshot 가능 여부를 확인해야 한다.

이 글에서 다루는 케이스

케이스 초점VM이 커널 단계에서 멈출 때를 모니터링 수집 관점에서 좁혀 보는 케이스
정리한 주제Guest Boot
주요 계층Guest OS, boot loader, kernel, initramfs, root filesystem
운영 단서1개 명령/로그 단서 기준으로 재구성

겉으로 보이는 증상

  • stop/start 후 VM이 부팅되지 않거나 single mode, grub, kernel panic 상태로 멈춘다.
  • kernel upgrade, library deletion, filesystem 문제 이후 console 접속만 가능하다.
  • cloud platform은 정상인데 guest OS 내부 문제로 서비스가 올라오지 않는다.

로그에서 먼저 눈에 들어오는 신호

운영 중에는 긴 설명보다 반복되는 로그 문구가 먼저 눈에 들어온다. 아래 신호는 실제 값 대신 예시 placeholder로 바꿔 흐름만 볼 수 있게 정리했다.

  • Guest Boot 계층에서 증상이 시작되지만 실제 원인은 다른 계층에 있을 수 있다.
  • 눈에 보이는 에러보다 장애 시각, 대상 리소스, 직전 변경 이력을 먼저 맞추는 편이 빠르다.
  • 읽기 전용 확인과 상태 변경 작업을 분리하면 급한 상황에서도 판단이 흐려지지 않는다.

처음에 나눠봐야 할 것

이 케이스는 한 번에 해결 명령을 찾기보다, 아래 기준으로 계층을 나누는 것이 먼저다.

  • hypervisor power state와 guest OS boot failure를 분리한다.
  • console 화면, last boot log, root filesystem mount 가능 여부를 먼저 확인한다.
  • 복구 전에는 disk snapshot 또는 image backup 가능 여부를 판단한다.

확인에 쓴 명령 흐름

아래 명령은 공개 가능한 형태로 일반화했다. 실제 값은 환경마다 다르므로 placeholder를 대상 리소스에 맞춰 바꿔야 한다.

virsh console <vm-name>
journalctl -xb --no-pager
dmesg -T | tail -n 100
lsblk -f
mount -o ro /dev/<root-device> /mnt

guestfish --ro -a <disk-image>
virt-rescue -a <disk-image>
grubby --info=ALL
systemctl get-default
systemctl status <service> --no-pager

조치 전에 판단할 지점

  • single mode, rescue image, guestfish 중 가장 영향이 작은 경로부터 선택한다.
  • grub/kernel 문제는 이전 kernel로 부팅 가능한지 확인한 뒤 기본 kernel을 되돌린다.
  • 파일 삭제/라이브러리 손상은 동일 OS 버전 패키지로 복구한다.

복구됐다고 판단하는 기준

  • 정상 multi-user target까지 부팅되는지 확인한다.
  • network, disk mount, 주요 daemon이 정상인지 확인한다.
  • 복구 중 임시로 붙인 disk/rescue 설정을 제거한다.

운영하면서 남은 교훈

이 케이스는 조치 자체보다 대상 식별이 더 중요하다. 같은 “VM이 안 된다”는 증상이어도 VM guest, compute host, storage attachment, virtual router, management service 중 어디가 기준점인지에 따라 명령과 위험도가 완전히 달라진다.

장애 시각, 대상 리소스, 직전 변경 이력, 확인 명령, 실제 조치, 검증 결과를 같은 순서로 남겨두면 다음 장애에서 단순 기억이 아니라 판단 근거로 다시 쓸 수 있다.

BGM EVER