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を1基のみ使用し、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接続、OSバージョン、管理用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の電源を切ることはしなかった。シリアルログの進行時刻、インストールプロセスの状態、ディスクI/Oを確認し、処理が進行中のインストールとブート停止を区別した。
電源を強制切断したケースは、新規の空ディスク対象マシンがインストール開始前のカーネルブート時に停止した条件の再試験であった。パッケージのインストールやファイルシステム更新中のVMを同様の方法で中断することはしなかった。
5. VMクローン後に必ず確認すべき値
| 確認項目 | 理由 |
|---|---|
| hostname/FQDN | 環境とアセット名の整合性 |
| MACアドレスと管理IP | DHCP予約・環境ネットワーク・Bastionの許可対象の一致 |
| machine-id | クローンされたOSの識別子の重複防止 |
| SSHホストキー | クローンされたキーの再利用防止、信頼パスの確認 |
| 仮想NICの接続 | ターゲットにNAT/ブリッジNICが混ざっていないか確認 |
| 起動順序・ディスク署名 | 再起動時に既存のOSを優先し、再インストールによるデータ上書きを防止 |
| メモリ・CPU profile | インストール条件と運用条件を区別して記録 |
シリアルコンソールには、インストールによって生成された公開SSHホストキーとフィンガープリントを残した。管理自動化はこの値を確認して known_hosts に登録し、認証失敗を解決するために StrictHostKeyChecking を無効化することはしなかった。
6. この記録をサービス構築の記事と分けた理由
仮想CPU・ファームウェア・インストール用RAMは、VMベースの環境における問題である。一方、NetBox health check、Redis接続 timeout、AWX権限伝播、APIトークン・ストレージパスは、サービスの構築と運用の問題である。両者を分けることで、次の実習において「VMを先に修正すべきか」と「サービス設定を点検すべきか」を素早く判断できる。
公式のブートファイルと動作方式については、iPXEダウンロード、iPXEブートファイル、iPXE chainloadingを参照した。本稿の成功・失敗条件は、このPCの実践的な実習記録に基づく。
関連資料および構成資料
ポートフォリオ原文 · オンライン網・閉域網構築ガイド · 障害シナリオ・検証記録 · VirtualBox構成問題解決記録
公開されているZIPには、構成テンプレートと自動化ソースが含まれています。OS、RPM、コンテナイメージ、および資格情報は含まれていません。自身のIPアドレス、公開CA、承認済みSSHキー、シークレットストレージで構成した上で適用してください。