오늘은 HPE 장비에 연관된 이슈 하나를 보려고 합니다. 어쨌든 하드웨어에 종속되지 않고 구성하는 Nutanix가 항상 하드웨어에 발목을 잡혀 문제가 생기는게 정말 아이러니 합니다.
평소처럼 Nutanix LCM을 통해 AHV를 10.3.1.4 버전으로 올리던 중이었어요. 그런데 갑자기 특정 노드에서 업그레이드가 중단되더니 'At least X MB more space needed on the / filesystem'이라는 에러가 뜨더라고요. 분명 사전에 루트 파티션 용량을 체크했을 때는 여유가 있었는데, 업그레이드 패키지를 풀면서 용량이 부족해지는 기현상이 벌어진 거죠.
원인 분석: 왜 하필 HPE 장비에서만 터질까?
이번 문제는 AHV 10.3.x 계열로 올라갈 때 리눅스 펌웨어 패키지들이 대거
업데이트되면서 발생해요. 특히 HPE 장비의 경우 관리용 툴인 iLO와 통신하는
과정에서 /root/iLORest.log라는 파일이 생기는데, 이 녀석이 시간이
지나면서 무시무시하게 덩치를 키우는 게 화근이었던것 같습니다.
# 에러 메시지 예시
Upgrade failed: Unable to run upgrade plugin dnf_update: exit status 1
dnf.exceptions.Error: Transaction test error:
installing package linux-firmware-20260110-10.3.1.4s1c1r1.el8.noarch needs 117MB on the filesystem
위 로그를 보면 dnf_update 플러그인이 실행되다가 멈춘 걸 알 수
있어요. Nutanix AHV는 내부적으로 RedHat 계열의 패키지 매니저인
dnf를 사용하는데, 실제 설치를 진행하기 전에 'Transaction
test'라는 과정을 먼저 거치거든요. 이 과정은 "내가 이 패키지를 설치할 건데, 네
디스크에 진짜 자리가 있니?"라고 미리 물어보는 단계입니다.
여기서 117MB라는 숫자가 나온 건 우연이 아니에요. AHV 10.3 버전부터 포함된 새로운 펌웨어 데이터들이 차지하는 최소한의 연속된 공간을 의미하거든요. 루트(/) 파티션은 보통 OS가 구동되기 위한 최소한의 영역으로 잡히기 때문에, 예상치 못한 로그 파일 하나가 이 테스트를 실패하게 만드는 주범이 됩니다.
범인 검거: 460MB짜리 거대 로그의 정체
문제가 발생한 노드에 SSH로 접속해서 실제로 어떤 녀석이 용량을 잡아먹고 있는지
뒤져봤어요. du 명령어를 써서 /root 디렉토리를
훑어보니 아니나 다를까 범인이 바로 나오더라고요.
보통 /root 폴더는 사용자의 개인 설정이나 가벼운 스크립트만
들어있어야 하는데, HPE 전용 관리 도구들이 이 경로를 기본 로그 저장소로
활용하면서 문제가 커진 셈이죠.
nutanix@cvm$ hostssh "du -aSxh /root | sort -h | tail -n 10"
위 명령어는 CVM에서 모든 호스트(Host)로 접속해 /root 아래의 파일
크기를 조사하고, 가장 큰 용량 순으로 10개를 뽑아내는 강력한 한 줄이에요.
여기서 -x 옵션이 정말 중요한데, 이건 'One File System'의 약자로
다른 마운트 포인트(예: 스토리지 풀이나 ISO 영역)로 넘어가지 않고 순수하게 현재
파일 시스템의 용량만 체크하라는 뜻이에요.
-S는 하위 디렉토리를 합산하지 않고 개별 파일의 크기를 보는
옵션이라 범인을 특정하기에 딱이죠. 실행 결과는 아래 표와 같습니다.
| 파일/경로 명칭 | 점유 용량 | 비고 |
|---|---|---|
| /root/iLORest.log | 460M | 삭제 대상 (주범) |
| /root/rest.debug.log | 200K | 일반적인 로그 수준 |
| /root/acropolis_modules | 1.2M | 시스템 모듈 |
세상에, 로그 파일 하나가 460MB나 차지하고 있네요? 보통 AHV의 루트 파티션 여유 공간이 1GB 내외인 걸 감안하면, 이 정도 크기는 업그레이드 프로세스 자체를 마비시키기에 충분한 양이에요. iLO와 통신할 때 발생하는 디버깅 정보가 순환(Rotation)되지 않고 계속 쌓이면서 발생한 전형적인 관리 툴의 설계 미스라고 볼 수 있어요.
실무에서만 아는 꿀팁: 업그레이드 전 '사전 청소'
공식 문서(KB-21177)에는 단순히 파일을 지우라고만 되어 있지만, 실무에서는 업그레이드를 누르기 전에 전체 클러스터 노드를 한꺼번에 체크하는 게 정신 건강에 이로워요. 한 대가 터졌다면 나머지 노드들도 시한폭탄을 안고 있을 확률이 99%거든요. 업그레이드 도중 노드 하나가 멈추면 전체 작업 시간이 기하급수적으로 늘어나니까 미리 손을 써야 합니다.
💡 엔지니어 전용 Tip: 노드 전체 일괄 삭제
케이스 오픈하고 엔지니어 기다릴 것 없이, 아래 명령어로 모든 노드의 해당 로그를 미리 날려버리세요.
hostssh "rm -f /root/iLORest.log"
이 명령어는hostssh를 통해 클러스터 내 모든 AHV 노드에 동시 접속하여 해당 로그 파일을 강제 삭제해요.-f옵션을 붙였기 때문에 파일이 없더라도 에러를 뱉지 않고 조용히 넘어가죠. 이 파일은 iLO REST API 통신 기록이라 지워도 시스템 운영에 아무런 지장이 없어요. 오히려 안 지우고 방치했다가 나중에 덤프(Dump)라도 뜨려고 하면 용량 없어서 고생만 하니까 미리 비워두는 게 상책이에요.
해결 방법: 단순하지만 확실한 조치
해결책은 의외로 간단해요. 문제가 된 로그 파일을 삭제하고 업그레이드를 다시 시도하는 거죠. 사실 로그 로테이션 설정을 건드리는 게 정석이겠지만, 업그레이드라는 긴박한 현장 상황에서는 일단 공간 확보가 최우선입니다.
root@ahv# rm /root/iLORest.log
rm 명령어로 파일을 삭제하고 나면 즉시 용량이 확보돼요.
df -h / 명령어로 여유 공간을 다시 확인해 보면, 아까는 보이지 않던
수백 메가바이트의 빈 자리가 생겼을 거예요. 이제 Prism Central이나 Prism
Element에서 실패했던 AHV 업그레이드 'Retry' 버튼을 누르세요.
아까는 공간이 없어서 투덜대던 dnf가 이제는 아주 부드럽게 패키지를
설치하기 시작할 거예요. 펌웨어 데이터가 /boot나
/ 파티션에 안전하게 자리 잡으면서 업그레이드 진행률 바가 쑥쑥
올라가는 걸 보면 마음이 편안해지죠.
이번 장애 처리를 통해 느낀 건, 아무리 소프트웨어가 좋아도 결국 하드웨어
제조사에서 제공하는 번들 툴들이 OS 영역에 남기는 흔적을 무시하면 안 된다는
점이었어요. 특히 HPE 서버를 쓴다면 이 iLORest.log는 주기적으로
감시해야 할 1순위 대상입니다. 인프라 엔지니어라면 자동화 스크립트에 이 로그를
삭제하는 구문을 넣어두는 것도 좋은 방법이겠네요.
항상 모든 엔지니어분들에게 도움이 되는 글을 작성하고자 하는데, 얼마나 도움이 되는지는 모르겠습니다. 그래도 많은분들에게 긍정적인 피드백을 드렸으면 좋겠습니다.
0 댓글