VirtualBox 실습이 부팅에서 멈췄을 때 — Rocky 10.2와 PXE 구축 기록
AI_Manager
NetBox·Zabbix·AWX를 설치하기 전에 해결해야 할 문제가 있었다. 새 VM이 커널 부팅에서 멈추고, UEFI의 네트워크 부팅 경로가 열리지 않았으며, PXE 설치 이미지가 메모리에 들어가지 않았다. 이 글은 서비스 자체의 오류가 아니라 VirtualBox 실습 기반에서 겪은 문제를 정리한다.
환경은 Windows 11 Pro, Intel Core Ultra 9 185H, 사용 가능 메모리 약 31.4GiB, VirtualBox 7.2.18, Rocky Linux 10.2다. 아래 해결 조건은 이 PC에서 관측한 결과이며 모든 VirtualBox·UEFI 환경에 일반화하지 않는다.
1. 다중 vCPU에서 커널 부팅이 멈춤
증상과 관측
일부 VM은 CPU 수를 늘린 뒤 부팅 중 진행이 멈췄다. 직렬 콘솔의 마지막 화면에는 EVM extended attributes 초기화 메시지가 남았다. 그러나 마지막 출력이 EVM이라는 사실만으로 EVM·SELinux가 원인이라고 판단할 수는 없다.
paravirtualization provider와 가상 CPU 조건을 바꾸어 비교했다. 중앙 VM은 Intel Core i7-6700K CPU profile에서 gateway 2 vCPU와 ops01 4 vCPU 부팅·재부팅을 확인했다. 반면 새 BIOS PXE 대상은 같은 프로파일에서도 2 vCPU 설치 커널이 정지해 1 vCPU로 진행했다.
적용한 조치
# VM이 정상 종료된 상태에서 적용한다.
$VBox = 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe'
& $VBox modifyvm fml-ops-01 --cpu-profile 'Intel Core i7-6700K' --cpus 4
& $VBox modifyvm fml-dev-app-01 --cpus 1
이 프로파일은 가상 CPU의 호환 조건이다. 실제 호스트 CPU가 i7-6700K로 바뀌는 것이 아니다. 게스트 자산 수집 결과에는 가상 CPU 모델이 나타나므로 포트폴리오의 물리 PC 사양과 구분했다.
Hyper-V, VBS, Windows 메모리 무결성을 비활성화하지 않았다. 이 기능들을 끄면 해결된다고 단정하지 않고, 실제로 통과한 VM별 조건을 기록했다. 최종 vCPU 수는 부팅 성공뿐 아니라 서비스 작업에 필요한 자원도 고려했다.
2. UEFI 펌웨어 예외와 네트워크 부팅 경로
증상과 관측
새 EFI VM의 일부 그래픽·펌웨어 조합에서는 CpuDxe 예외가 발생했다. EFI64와 VMSVGA, VRAM 16MiB 조합에서는 그 예외를 피했지만 기대한 네이티브 PXE 부팅 메뉴가 나타나지 않았다.
추가로 기존 Extension Pack은 7.1.10이었고 VirtualBox 본체는 7.2.18이었다. 버전 불일치 오류 VERR_VERSION_MISMATCH를 확인했다. Extension Pack을 설치하거나 라이선스에 동의하는 작업은 하지 않았다.
공식 iPXE의 EFI와 legacy EFI 부트 경로도 시험했지만 이 PC에서는 초기화 이후 설치까지 이어지지 않았다. 이를 ‘UEFI PXE가 원래 안 된다’는 결론으로 확대하지 않았다.
실제 설치에 사용한 경로
BIOS + 공식 ipxe-legacy.iso에서는 DHCP → 내부 HTTP의 kernel/initrd → Rocky Kickstart 설치가 진행됐다. 대상은 내부망 NIC 한 개만 사용했고 OS 패키지는 Provision 서버에서 받았다.
& $VBox modifyvm fml-prod-app-01 --firmware bios --cpus 1 --memory 4096
& $VBox modifyvm fml-prod-app-01 --boot1 disk --boot2 dvd --boot3 net --boot4 none
실습의 PXE 설치 증거는 이 BIOS 경로다. 물리 서버의 UEFI·Secure Boot·NIC Option ROM·RAID 구성까지 검증했다는 의미가 아니다. 물리 장비 적용 시에는 해당 장비의 지원 경로를 별도로 시험해야 한다.
3. 2GiB 메모리에서 설치 이미지 다운로드 실패
증상과 원인
PXE kernel/initrd를 받은 뒤 약 750MiB의 install.img를 내려받는 단계에서 No space left on device가 발생했다. 설치할 가상 디스크에 공간이 없는 문제가 아니라 초기 설치 환경의 tmpfs 공간이 부족한 상황이었다.
조치와 확인
설치 대상 RAM을 2GiB에서 4GiB로 올렸다. 같은 내부 저장소에서 설치 이미지와 309개 RPM을 내려받고 Rocky 설치를 완료했다. 설치 후 SSH 접속, 운영체제 버전, 관리 IP, SELinux Enforcing, 설치 완료 표식을 확인하고 정상 종료한 다음 RAM을 1GiB로 줄였다.
& $VBox showvminfo fml-prod-app-01 --machinereadable
# 게스트에서 정상 종료한 후
& $VBox modifyvm fml-prod-app-01 --memory 1024
& $VBox startvm fml-prod-app-01 --type headless
설치할 때 필요한 메모리와 설치 후 서비스 운영에 필요한 메모리는 다르다. 여러 대상에 설치용 4GiB를 동시에 할당하면 Windows와 중앙 서비스의 여유가 줄어들어, 대상 설치는 순차 실행했다.
4. 설치 화면이 오래 멈춘 것처럼 보임
1 vCPU 실습에서는 kernel-core 설정, initramfs 생성, SELinux 정책 적용 구간이 오래 걸렸다. 마지막 화면이 바뀌지 않는다고 즉시 VM 전원을 끄지 않았다. 직렬 로그의 진행 시각과 설치 프로세스 상태, 디스크 작업을 확인해 진행 중인 설치와 부팅 정지를 구분했다.
전원을 강제로 끈 경우는 새 빈 디스크 대상이 설치 시작 전 커널 부팅에서 정지한 조건의 재시험이었다. 패키지 설치·파일시스템 갱신 중인 VM을 같은 방식으로 중단하지 않았다.
5. VM 복제 뒤 반드시 확인한 값
| 확인 항목 | 이유 |
|---|---|
| hostname/FQDN | 환경과 자산 이름의 일관성 |
| MAC과 관리 IP | DHCP 예약·환경망·Bastion 허용 대상 일치 |
| machine-id | 복제된 OS의 식별자 중복 방지 |
| SSH host key | 복제된 키 재사용 방지, 신뢰 경로 확인 |
| 가상 NIC 연결 | 대상에 NAT/브리지 NIC가 섞이지 않았는지 확인 |
| 부팅 순서·디스크 서명 | 재부팅 시 기존 OS 우선, 재설치로 데이터 덮어쓰기 방지 |
| 메모리·CPU profile | 설치 조건과 운영 조건을 구분해 기록 |
직렬 콘솔에는 설치가 생성한 공개 SSH host key와 fingerprint를 남겼다. 관리 자동화는 이 값을 확인해 known_hosts에 등록하며, 인증 실패를 해결하려고 StrictHostKeyChecking을 끄지 않았다.
6. 이 기록을 서비스 구축 글과 나눈 이유
가상 CPU·펌웨어·설치 RAM은 VM 기반 환경의 문제다. 반면 NetBox health check, Redis 연결 timeout, AWX 권한 전파, API 토큰·저장소 경로는 서비스 구축과 운영의 문제다. 두 종류를 나누면 다음 실습에서 ‘VM을 먼저 고쳐야 하는지’와 ‘서비스 설정을 점검해야 하는지’를 빠르게 판단할 수 있다.
공식 부트 파일과 동작 방식은 iPXE 다운로드, iPXE 부트 파일, iPXE chainloading을 참조했다. 본문의 성공·실패 조건은 이 PC의 실제 실습 기록이다.
함께 읽기와 구성 자료
포트폴리오 원문 · 온라인망·폐쇄망 구축 가이드 · 장애 시나리오·검증 기록 · VirtualBox 구성 문제 해결 기록
실습 설정·자동화 소스 ZIP · ZIP SHA-256
공개 ZIP에는 구성 템플릿과 자동화 소스를 담았습니다. OS·RPM·컨테이너 이미지와 자격 증명은 포함하지 않습니다. 자신의 주소·공개 CA·승인 SSH 키·비밀 저장소로 구성한 뒤 적용합니다.