Posted inVirtualization

VirtualBox仮想マシンをKVM/Proxmox VEへ移行：VDIからQCOW2への変換とVirtIOブートエラーの解決手順

Virtualization tutorial - IT technology blog
Virtualization tutorial - IT technology blog

VirtualBoxからKVM/Proxmoxへの仮想マシン移行アプローチ比較

深夜2時、PagerDutyのアラートがけたたましく鳴り響きます。開発用ワークステーションのVirtualBox上で一時稼働していたデータベースが、ホストマシンの電源障害により突然ダウンしました。課されたミッションは、この80GBの仮想マシンを本番環境のProxmox VEクラスタへ緊急移行することです。技術的な選択肢は主に以下の3つがあります。

  • 選択肢1：OVA/OVF形式でエクスポートして再インポート。 VirtualBox側で仮想マシン全体を.ovaアーカイブとしてエクスポートし、Proxmox上で解凍してディスクイメージを抽出します。
  • 選択肢2：ClonezillaやVeeam Agentを用いたネットワーク経由のディスククローン。 送信元・送信先の双方でレスキューISOを起動し、ネットワークポート経由でブロック単位のデータストリーミングを行います。
  • 選択肢3：qemu-imgを用いたディスクファイルの直接変換。 対象の.vdiファイルのみを転送し、コマンドでQCOW2またはRAW形式へ変換した上で新規VMにアタッチします。

各手法の実践的な比較検証

システム障害の発生時、ダウンタイムは1分1秒が大きな損失につながります。各アプローチの実践的なメリット・デメリットは以下の通りです。

1. OVA/OVFのエクスポート

  • メリット： GUI上で直感的に操作可能。メモリ容量やvCPUコア数などの構成情報をそのまま保持してエクスポートできます。
  • デメリット： 処理速度が非常に遅い点です。VirtualBoxで80GBのディスクをOVAファイルに圧縮・パッケージングするだけで約25分を要します。さらにネットワーク経由のrsync転送とtar解凍に15分かかり、データの中継処理だけで45分近く消費してしまいます。

2. Clonezillaやエージェント経由のネットワーククローン

  • メリット： OracleとQEMU間における仮想化ディスクのフォーマット差異を気にする必要がありません。
  • デメリット： セットアップが煩雑です。Live ISO環境下で双方に静的IPアドレス等を設定する必要があります。また、LANの輻輳やソースマシンの予期せぬ切断が発生した場合、全体の処理を最初からやり直さなければなりません。

3. qemu-imgによるダイレクト変換

  • メリット： 最も高速です。実データ容量30GB（割り当て80GB）のVDIファイルをQCOW2へ変換する処理は、NVMeストレージ上であればわずか3〜5分程度で完了します。QCOW2フォーマットは高速なスナップショット機能やシンプロビジョニング（動的容量割り当て）にも対応しています。
  • デメリット： 保持されるのはディスクイメージのみです。ネットワークインターフェース、UEFI/SeaBIOSのブート規格、ストレージコントローラなどの設定はProxmox側で手動構成する必要があります。

手法の選定：なぜqemu-imgを最優先すべきなのか？

緊急のマイグレーション対応において、ディスクファイルの直接変換は常に最短のルートです。旧来のVirtualBox仮想化レイヤーを完全に切り離すことができ、Oracle Guest Additions等の不要なドライバが原因で発生する移行先ホストでのトラブルを未然に排除できます。

筆者のCephストレージを組み込んだ3ノードProxmoxホームラボ環境でも、VMwareやVirtualBoxからのインポートワークフローはすべてqemu-imgとqm importdiskに標準化しています。この手法はBashスクリプトによる自動化が容易であり、ハードウェアパラメータを厳密に制御できる利点があります。

移行手順のステップ・バイ・ステップ

ステップ1：仮想マシンのシャットダウンとVDIファイルのサーバー転送

VirtualBox上の仮想マシンをACPIシャットダウンまたは電源オフで完全に停止させます。メモリ状態を保存する状態の保存（Save State）はファイルシステムの整合性を損なう恐れがあるため、絶対に使用しないでください。

rsyncコマンドを使用してVDIファイルをProxmoxホストへ転送します。空ブロックをスキップしてネットワーク帯域を節約するため、--sparseオプションの指定が極めて重要です。

rsync -avP --sparse /home/dev/VirtualBox\ VMs/app-db/app-db.vdi [email protected]:/var/lib/vz/dump/

1GbpsのLAN環境であれば、実データ30GBを含むVDIファイルの転送は約4〜5分で完了します。

ステップ2：VDIからQCOW2へのフォーマット変換

ProxmoxノードにSSHログインします。まず、ソースファイルの構造を確認します。

qemu-img info /var/lib/vz/dump/app-db.vdi

続いてQCOW2形式へ変換します。注意点として、本番環境ディスクでは-c（圧縮）オプションを使用しないでください。圧縮されたディスクはランダムI/O性能（ランダムIOPS）が大幅に低下します。

qemu-img convert -p -f vdi -O qcow2 /var/lib/vz/dump/app-db.vdi /var/lib/vz/images/app-db.qcow2

-pオプションを指定するとプログレスバーが表示され、完了までの進捗状況をリアルタイムで把握できます。

ステップ3：VMの作成とProxmoxへのディスク登録

Web UIまたはCLIから新規仮想マシン（例：VM ID 105）を作成します。移行元と同等のスペック（4 vCPU、8GB RAM）を構成し、ウィザードによって作成されたデフォルトのハードディスクは削除します。

ストレージプール（例：local-lvm）にディスクをインポートするコマンドを実行します。

# VM 105にディスクをインポート
qm importdisk 105 /var/lib/vz/images/app-db.qcow2 local-lvm

# 初期ブート時のエラーを防ぐため、VirtIOではなくSATAバスにディスクを接続
qm set 105 --sata0 local-lvm:vm-105-disk-0
qm set 105 --boot order=sata0

ステップ4：VirtIOドライバの構成（ブルースクリーンとKernel Panicの回避）

これは移行時にエンジニアの90%が遭遇する落とし穴です。VirtualBox上で稼働していた仮想マシンは標準的なSATA/IDEドライバのみを読み込むよう構成されています。そのため、最初からディスクをVirtIO SCSIコントローラに接続してしまうと、OSが即座にクラッシュします。

Windowsの場合はINACCESSIBLE_BOOT_DEVICEのブルースクリーン（BSOD）が発生します。一方Linuxの場合は、initramfsに必要なVirtIOモジュールが含まれていないため、dracut Emergency Shellで停止するか、kernel panic: Unable to mount root fsでハングアップします。

アプローチ1：Windows Server / Windows 10/11での対処法

  1. ブートドライブをSATA（またはIDE）バスのまま維持します。Windows標準の汎用ドライバが読み込まれるため、正常にログイン画面まで起動します。
  2. Fedora/Red Hatの公式VirtIO ISO（virtio-win.iso）をダウンロードし、VMの仮想CD-ROMドライブにマウントします。
  3. 容量1GBのダミー追加ディスクを作成し、バスタイプにVirtIO SCSIを選択します。
  4. Windowsを起動してデバイスマネージャーを開くと、「SCSI コントローラー」に黄色の警告マークが表示されています。右クリックして［ドライバーの更新］を選択し、VirtIOのCDドライブを指定してドライバをインストールします。
  5. あわせてISOイメージ内にあるqemu-guest-agentをインストールし、Proxmox側でのIPアドレス認識や正常なシャットダウン制御を有効化します。
  6. VMをシャットダウンし、1GBのダミーディスクを削除します。メインディスクをsata0からscsi0（VirtIO SCSI Single、DiscardおよびSSD Emulationを有効化）に変更します。再度起動すれば、ネイティブな高スループットI/O性能をフルに発揮できます。

アプローチ2：Linux（Debian、Ubuntu、RHEL、Rocky Linux）での対処法

SATAバス経由でLinuxを起動します。rootユーザーでログインし、ストレージコントローラを切り替える前にinitramfsへVirtIOモジュールを追加します。

Ubuntu / Debianの場合、設定ファイルにモジュールを追記します。

# 初期ロードリストにVirtIOドライバを追加
cat <<EOF >> /etc/initramfs-tools/modules
virtio
virtio_ring
virtio_pci
virtio_scsi
virtio_blk
EOF

# すべてのカーネル向けにinitramfsを再構築
update-initramfs -u -k all

RHEL / CentOS / Rocky Linuxの場合、dracutを使用してドライバを強制的に組み込みます。

dracut --force --add-drivers "virtio virtio_pci virtio_ring virtio_scsi virtio_blk" /boot/initramfs-$(uname -r).img $(uname -r)

再構築が完了したらVMをシャットダウンします。Proxmoxの［ハードウェア］画面からsata0ディスクをデタッチ（Detach）し、VirtIO SCSI Singleコントローラのscsi0として再アタッチします。これでOSはわずか数秒で直接ブートし、ディスクスループットも従来のSATAコントローラと比較して3〜4倍向上します。

Share:
Tags: