현장의 불청객: 왜 잘 돌던 Ubuntu가 마이그레이션을 거부할까?
고객사 인프라 마이그레이션 프로젝트. 평화롭던 오후에 꼭 이런 일이 터진다. Nutanix Move를 이용해 Ubuntu VM을 AHV로 넘기는 작업 중이었다. 평소처럼 자동화 스크립트가 쫙 돌고 끝나야 할 타이밍에 붉은색 에러가 콘솔을 덮었다.
[Error] Drivers Installation Failed. Driver(s) virtio_scsi could not be installed for kernel 6.8.0-71-generic [/Error]
현재 운영 중인 메인 커널에서는 VirtIO가 멀쩡하게 작동하고 있는데 설치를 실패했다니. 직감적으로 무언가 단단히 꼬였다는 걸 알아챘다. 부랴부랴 벤더사 Case Open을 진행하고 공식 문서(KB-21325)와 씨름하며 삽질한 경험을 공유한다. 현장에서 이 텍스트를 보고 멘탈이 흔들릴 동료 엔지니어들을 위해 그날의 기록을 가감 없이 남긴다.
원인 분석: Move의 집착이 낳은 대참사 (initrd-img)
에러 로그를 자세히 뜯어보자. 멀쩡하게 쓰고 있는 최신 액티브 커널 대신, 이미 오래전에 잊혀진 6.8.0-71-generic 같은 구형 커널을 콕 집어 드라이버 설치가 안 된다고 뻗어버렸다. 주된 원인은 Nutanix Move의 강박적인 준비성에 있다. 후..
왜 이렇게까지 과도하게 설계되었을까? 과거 온프레미스(On-Premise) 환경의 관행을 생각해보면 Move 개발진의 의도도 어느 정도 납득은 간다. 보통 서버 관리자들은 OS 업데이트 후 애플리케이션에 장애가 터지면 황급히 이전 커널로 롤백(Roll-back)하는 습관이 있다. Move는 마이그레이션 이후 고객이 AHV 환경에서 부트 메뉴를 열어 옛날 커널로 부팅할 만일의 사태까지 모두 대비하고 싶었던 거다. 그래서 소스 VM에 깔려 있는 '모든' 커널을 싹 다 뒤져서 initrd-img를 리빌드하고 VirtIO 모듈을 욱여 넣으려 든다.
하지만 이 꼼꼼한 방어 로직의 치명적인 약점은 소스 시스템에 구형 커널이 어설프게 남아있을 때 폭발한다. 패키지 업데이트 과정에서 껍데기만 남고 /boot 디렉토리에 config-[kernel-version] 파일이 유실된 반쪽짜리 커널 말이다. Move는 이 깨진 유령 커널마저 완벽하게 AHV용으로 빌드하려다가 장렬하게 전체 준비 스크립트를 중단시켜 버린다.
| 발생 단계 | 주요 원인 | 영향을 받는 버전 |
|---|---|---|
| VM 마이그레이션 준비 스크립트 실행 중 | 불완전하게 삭제된 Legacy 커널의 initrd 리빌드 시도 | Nutanix Move 5.x, 6.0.x |
트러블슈팅: 유령 커널의 숨통을 끊어보자
해결책은 두 갈래로 나뉜다. 꼬여있는 옛날 커널 패키지를 완벽하게 재설치해서 복구하거나, 시스템에서 영원히 지워버리는 것이다. 굳이 안 쓰는 구형 커널을 살릴 이유는 한 개도 없으니 싹 밀어버리는 쪽을 택했다. 먼저 문제가 되는 커널이 시스템에 어떤 흉측한 몰골로 남아있는지 진단해야 한다.
 |
| 터미널에서 dpkg 명령어로 깨진 커널 패키지를 확인 |
dpkg -l | grep linux-image이 명령어는 현재 시스템의 패키지 관리자에 등록된 모든 리눅스 커널 이미지의 목록을 샅샅이 필터링하여 출력한다. dpkg -l 파라미터는 시스템 내부에 설치된 전체 패키지의 상태코드와 이름, 그리고 버전을 리스트업하는 뼈대 역할을 한다. 뒤이어 붙는 파이프라인(|)과 grep 지시어가 그 방대한 텍스트 더미 속에서 오직 리눅스 커널 이미지와 관련된 패키지만 쏙 골라내는 정밀한 타겟팅을 수행한다. 이 명령어를 콘솔에 때려 넣으면 ii(정상 설치됨) 상태와 rc(설정 파일만 남음) 혹은 iU(압축만 풀림) 상태의 커널들이 주르륵 쏟아져 나온다. 여기서 앞서 에러 로그에 등장했던 그 문제의 6.8.0-71-generic 버전이 어떤 지저분한 상태로 방치되어 있는지 두 눈으로 명확히 확인해야 한다. 타겟이 확인되었다면 지체 없이 타격 명령을 날린다.
sudo apt-get purge linux-image-6.8.0-71-generic시스템의 쓰레기를 치울 때 일반적인 remove 대신 반드시 purge 파라미터를 강제하여 패키지를 날려야 한다. 사실 실무 현장에서 주니어 엔지니어들에게 커널을 지우라고 하면 열에 아홉은 손을 번쩍 든다. "이거 지우다가 혹시 DB 멈추면 어떡하나요?" 혹은 "재부팅할 때 GRUB 부트로더 날아가는 거 아닙니까?" 같은 공포심 때문이다. 하지만 냉정하게 생각하자. 지금 시스템을 돌리고 있는 액티브 메인 커널만 건드리지 않는다면, 과거의 찌꺼기를 지우는 작업은 시스템 가동에 1밀리초의 다운타임도 유발하지 않는다.
오히려 /boot 파티션 용량이 100% 차올라 서버 전체가 뻗어버리는 대형 장애를 막기 위해서라도 안 쓰는 커널은 주기적으로 날려버리는 게 인프라 운영의 정석이다. purge 옵션은 패키지의 단순 실행 바이너리 파일뿐만 아니라, 시스템 깊숙한 곳에 숨어 두고두고 골치를 썩일 수 있는 환경 설정 파일들까지 뼛속까지 긁어내서 영구 삭제하라는 가장 강력한 리눅스 지시어다. 뒤이어 붙는 커널 버전은 앞서 확인한 에러 로그의 정확한 문자열을 단 하나의 오타도 없이 입력해야 한다. 엔터를 치는 순간 패키지 매니저가 시스템의 전체 의존성을 재평가하며 해당 커널과 관련된 /boot 내부의 찌꺼기 파일들과 램디스크 이미지들을 흔적도 없이 소각한다. 삭제가 완료된 후 Move UI에서 마이그레이션을 쿨하게 재시도하거나 매뉴얼 준비 스크립트를 다시 돌려보자. 지긋지긋하게 발목을 잡던 유령 커널이 사라졌으니 진행 게이지 바가 막힘없이 100%를 향해 올라가는 쾌감을 맛볼 수 있다.
실무진을 위한 현장 꿀팁: 공식 문서가 말해주지 않는 잔여물 처리법
벤더사의 공식 문서에는 단순히 '사용하지 않는 커널을 지우라'고 점잖게 적혀 있다. 하지만 현장 인프라 환경은 그렇게 호락호락하게 굴러가지 않는다. 정상적인 절차로 패키지를 지웠는데도 /lib/modules/ 하위 경로나 /boot 디렉토리에 빈 껍데기 폴더가 비정상적으로 남아있어 Move 스크립트가 또다시 오작동을 일으키는 끔찍한 경우가 간혹 터진다.
- 디렉토리 교차 검증: 패키지 삭제 직후
ls -al /boot및ls -al /lib/modules명령을 통해 관련 버전의 폴더나 파일이 완전히 증발했는지 더블 체크할 것. - 부팅 불안감 해소: 삭제 후 구형 커널이 없어 부팅이 안 될까 걱정할 필요는 전혀 없다.
삭제 작업 후에는 반드시 해당 시스템 디렉토리들에 알 수 없는 찌꺼기가 남지 않았는지 직접 눈으로 확인하는 편집증적인 검증 습관을 들여야 한다. 혹시라도 마이그레이션이 성공적으로 끝난 뒤에 구형 커널로 부팅해야 할 치명적인 상황이 생기지 않을까 덜덜 떨 필요는 없다. AHV 클러스터에 무사히 안착한 VM은 파워온(Power-On) 시 자연스럽게 가장 최신에 설치된 온전한 커널을 자동으로 물고 올라오도록 셋팅된다. 깡통이 된 과거의 망령에 얽매이지 않고 과감하게 쳐내는 결단력이 인프라 엔지니어의 퇴근 시간을 앞당긴다.
항상 최고의 결단력과 최선의 노력이 집에 갈 수 있는 결과를 만들어 낸다는 사실을 잊지 말자 ! ㅋ
0 댓글