Citrix XenServer VM의 CentOS 커널 업데이트 후 부팅 장애(Kernel Panic) 해결기

과거 당사에서 빅데이터 솔루션인 빅데이터 모니터링 플랫폼 사업을 수행하면서, On-Premise(사내 구축형) 환경을 고집하는 보안이 철저한 금융권이나 대기업 고객사에 방문하는 일이 잦았습니다. 이런 고객사들은 보통 베어메탈(물리 서버)에 솔루션을 설치하기보다는, 사내 프라이빗 클라우드나 가상화 솔루션인 VMware, 혹은 Citrix XenServer 위에 VM을 할당해 주고 그 위에 빅데이터 클러스터를 구성하길 요구했습니다.

당시 한 고객사에서 새롭게 할당받은 CentOS 6 기반의 Xen VM 서버군에 Hadoop 생태계와 빅데이터 모니터링 플랫폼을 설치하기 전, 보안 패치 권고에 따라 전체 서버의 OS 커널(Kernel) 패키지 업데이트(yum update)를 일괄 진행했습니다.

그런데 재부팅 과정에서 끔찍한 현상이 발생했습니다. 모든 Xen VM 서버가 부팅 도중 멈춰버리거나(Kernel Panic), Grub 화면 이후 더 이상 진행되지 않는 상태가 되어버린 것입니다.

1. 문제 증상 및 원인 분석

문제의 핵심은 XenServer의 부트로더 핸들링 방식과 특정 CentOS 6.x(특히 kernel-2.6.32-696.18.7.el6.x86_64 버전) 간의 호환성 버그였습니다.

원인: yum을 통한 커널 업데이트 후, 리눅스의 GRUB 부트로더 설정 파일(menu.lst 또는 grub.conf)이 새 커널 버전을 가리키도록 갱신되어야 합니다. 일반적인 물리 서버나 VMware 환경에서는 문제없이 리디렉션되는데, Citrix XenServer의 PV(Paravirtualization, 반가상화) 환경에서 pygrub를 사용하는 경우 변경된 부트로더를 제대로 인식하지 못하고 부팅 트리를 잃어버리는 치명적인 버그가 있었습니다.
영향을 받은 환경: Citrix XenServer 6.5 환경에서 구동되는 CentOS 6.x x86_64 체제

2. 해결 방안 (XenServer 쉘 접근)

VM 내부로는 아예 접속이 불가능해졌기 때문에, 고객사의 인프라 담당자와 협조하여 XenServer 호스트 물리 머신(Dom0 콘솔)에 직접 연결하여 외부에서 부트로더를 강제로 수정해 주어야 했습니다.

XenServer 콘솔에서 아래 명령어(xe-edit-bootloader)를 이용하면, 멈춰버린 VM의 디스크 이미지를 호스트에 임시 마운트하여 부트로더 엔트리를 편집할 수 있습니다.

shell


# 2. 문제가 발생한 VM의 Label(이름)을 찾아 편집 명령 실행
$ xe-edit-bootloader -n "VM_의_이름(Label)" -p 1

명령어를 실행하면 텍스트 기반 인터페이스 화면이 뜹니다.

화면에 잡혀있는 여러 커널 리스트(메뉴) 중에서 최근 설치되어 오류가 발생한 새 커널을 기본값(default) 대신 이전 정상 커널로 롤백(Rollback)하거나,
혹은 새 커널 엔트리의 경로(path)가 Xen 환경에 맞게 마운트 포인트를 제대로 바라보고 있는지 경로를 수정해 줍니다.

설정을 저장하고 빠져나온 뒤 VM을 다시 시작(Start)하면, pygrub이 수동으로 지정해 준 부트로더 위치를 읽어 정상적으로 OS가 부팅됩니다.

3. 마무리 및 교훈

이 경험은 솔루션 납품 전 “테스트 베드에서의 충분한 검증”과 “파편화된 가상화 환경에 대한 변수 인지”가 얼마나 중요한지 뼈저리게 느끼게 해준 사건이었습니다. 단순히 yum update 한 줄을 치는 것만으로도 수십 대의 클러스터 노드가 한 번에 벽돌이 될 수 있다는 사실은 현장에서만 얻을 수 있는 서늘한 교훈입니다.

그 후로 저는 VDI나 낯선 가상화 인프라 위에 빅데이터 클러스터를 구축할 때는, 반드시 한 대의 노드에서 먼저 모든 패키지 업데이트와 재부팅 절차를 거친 후 안전성이 담보되었을 때만 롤아웃(Rollout)하는 철칙을 세우게 되었습니다.

관련 레퍼런스: