昨今、VMwareのライセンス体系刷新を契機として、KVMベースの HPE VM Essentials（VME）および HPE SimpliVity HCI 基盤への移行や、異機種ハイパーバイザー間でのディザスタリカバリ（DR）体制を検討する企業が急増しています。

通常、同種ハイパーバイザー間の移行ではネットワーク経由のオンラインレプリケーションが一般的ですが、遠隔拠点や閉域網環境において ネットワーク帯域がわずか10Mbpsに制限されている場合、リアルタイムのネットワーク転送は物理的に不可能です。数十GBに達する仮想マシンイメージを10Mbps回線で転送するには数十時間以上を要するためです。

このような極端な制約条件下において、最も確実で実効性の高いアプローチは、既存のVMware環境で取得したVeeamのバックアップデータファイル（.vbk）とメタデータファイル（.vbm）を外付けストレージ等で物理的に持ち込み、ターゲット環境へ直接インポートしてリストアするオフラインV2V（Virtual-to-Virtual）復旧です。

本稿では、VMware vSphere上でバックアップされたWindows 10仮想マシンファイルを移行先Veeamにインポートし、KVMベースのHPE VMEクラスタへ わずか18分でブートおよびサービス復旧を完遂した実務フローと技術検証の詳細 をまとめます。

実機復旧環境サマリー

項目移行元環境（Source）移行先環境（Target）
ハイパーバイザーVMware vSphere (ESXi)HPE SimpliVity with HPE VME (KVMベース HVM)
バックアップ製品Veeam Backup & Replication v11Veeam Backup & Replication (VME Worker アーキテクチャ)
バックアップ形式フルバックアップデータ（.vbk）+ バックアップメタデータ（.vbm）ローカルリポジトリへ物理配置後 Import Backup
ネットワーク環境拠点間 10Mbps の極小帯域（物理複製が必須）移行先内部の10G/25G高速ファブリック
対象ゲストOSWindows 10 Pro（VMware Tools導入済み）KVM VirtIOドライバによる正常クリーン起動

1. 10Mbps帯域の壁とオフラインバックアップ搬送戦略

回線帯域が10Mbpsに制限された拠点間では、転送遅延の観点から RPO（目標復旧時点、Recovery Point Objective） をオンラインで極小化することには物理的な限界が存在します。

そのため、非常時の切り替えにおいてはネットワークストリーミングを断念し、移行元サイトのリポジトリからフルバックアップデータファイル（*.vbk）と、極めて重要なバックアップメタデータファイル（*.vbm）を大容量ストレージに直接複製し、移行先のローカルリポジトリへ物理搬送する手法を採用しました。

バックアップメタデータファイル（.vbm）が必須である技術的理由

ここで数十GBの .vbk ファイルだけでなく、わずか数KBの .vbm（Veeam Backup Metadata）ファイルをセットで複製・搬送することが最大の現場ノウハウ です。

  • .vbk 単体インポート時: メタデータが存在しない場合、移行先Veeamは大容量な .vbk ファイル内部の全仮想ディスクブロック構造をゼロからフルスキャンしてカタログを再構築する必要があり、リストア開始前のインデックス処理で多大な時間を浪費してしまいます。
  • .vbk ＋ .vbm 同時配置時: .vbm ファイル内には仮想マシンのハードウェア定義、ディスクジオメトリ、リストアポイントチェーン情報が完全に記録されています。そのため、元環境のバックアップサーバーDBと完全に切り離された閉域網であっても、移行先Veeamコンソールで Import Backup を実行した瞬間に1秒でインベントリ登録が完了し、待ち時間なく即座にリストアへ着手できます。

2. Veeamリストアセッション：異機種間復旧の要「VirtIO Driver Injection」

インポートしたバックアップチェーンを登録後、復旧ターゲットをHPE VME（SimpliVity）クラスタに指定してFull VM Restoreを実行しました。以下はリストア実行中に記録されたVeeamセッションの詳細ログです。

Veeam異機種間リストアセッションログ画面 (写真：Veeam Restoreセッションログ - KVM専用ワーカー起動、ディスク復元、VirtIOドライバ自動挿入、完了時間)

復旧所要時間（RTO）の分析

  • セッション開始時刻: 40分27秒 PM
  • セッション完了時刻: 58分32秒 PM
  • 純粋リストア所要時間: 約18分5秒

10Mbps回線によるネットワーク複製を試みていれば半日以上を要した処理が、ローカルメディアからの直接復旧により わずか18分でインスタンス展開まで完了（RTO達成） しました。

異機種V2V復旧の最大の難所：VirtIOドライバ挿入

VMware上の仮想マシンをKVMベースのHPE VMEへ移行する際、最大の障害となるのが ストレージコントローラアーキテクチャの不一致 です。

  • VMware: LSI Logic SAS または VMware Paravirtual (PVSCSI) コントローラ
  • KVM (VME): 高性能 VirtIO SCSI コントローラ

ドライバ変換を行わずに起動を試みると、Windowsのブートローダが起動ディスクを認識できず、ブルースクリーン（BSOD 0x7B: Inaccessible Boot Device） を引き起こして起動不能に陥ります。

Veeamはログに示されている通り、専用KVMワーカー（veeam-worker01）を自動展開し、オフライン状態のWindows OSレジストリおよびドライバストアへ直接ドライバを注入します。

VirtIO driver injection required (0:00:50)
VirtIO driver injection finished (0:06:12)

約6分間の処理によって、オフラインのシステムイメージ内部へ Red Hat KVM VirtIOストレージおよびネットワークドライバが完全インジェクション（Injection） され、初回ブート時に即座にディスクが認識される状態が自動構築されました。

3. HPE VME Manager：HVMインスタンスのプロビジョニングと起動確認

Veeamのリストア処理が完了すると、管理基盤である HPE VM Essentials（VME）Manager のWebコンソール上に新規展開されたインスタンスが反映されます。

HPE VME Manager インスタンスプロビジョニング完了画面 (写真：HPE VMEコンソール上で veeam-custom-service-plan により自動プロビジョニングされ Running 中のHVMインスタンス)

  • インスタンス状態: Running（正常稼働）
  • 仮想化種別: HVM（KVMベースのハードウェア仮想マシン）
  • サービスプラン: veeam-custom-service-plan（Veeam API経由で元VMのサイジングに合致したカスタムプランを自動生成）
  • 履歴（History）タイムライン:
    • Provision: 約17分32秒（Veeamワーカーによるディスク展開および形式変換完了）
    • Startup: 約2分33秒（VMEハイパーバイザー上での初期パワーオン完了）
    • Post-Provision Operations: 即時完了

手動でvCPUやメモリ、ディスクバスを再設計することなく、元の仮想マシンスペックがそのまま正確にVMEクラスタへ反映されました。

4. ゲストOS検証：ドライバ認識とVMware Toolsのクリーンアップ

復旧の真の成否は、ゲストOS（Windows 10）起動後のデバイス認識状態とドライバ競合の有無によって判定されます。VMEコンソールからゲストOSの画面へ接続しました。

Windows 10 ゲストOS デバイスマネージャーおよびインストール済みアプリ確認 (写真：VirtIOネットワーク・SCSIディスクの正常認識、物理CPU透過、VMware Toolsが綺麗に整理されたゲストOS)

デバイスマネージャーおよび設定画面から確認された3つの決定的検証結果は以下の通りです。

  1. Red Hat VirtIOドライバの完全ロード:
    • ネットワークアダプター: Red Hat VirtIO Ethernet Adapter として正常認識。
    • ディスクドライブ: QEMU QEMU HARDDISK SCSI Disk Device として正常認識。
    • デバイスマネージャー上に感嘆符（警告）や不明なデバイスは一切存在しません。
  2. 最新SimpliVity物理CPUの正確な透過:
    • プロセッサ項目において、ターゲットSimpliVityノードの物理CPUである Intel Xeon Gold 6542Y が直接認識され、最新命令セットを十全に活用できています。
  3. VMware Toolsのクリーンな非競合状態:
    • 設定 > アプリ > インストールされているアプリ の検索結果より、既存ESXi環境で稼働していた VMware Toolsサービスが起動プロセスにおいて競合を起こすことなく綺麗に整理 されています。
    • ハイパーバイザー移行時に散見されるバックグラウンドデーモンのエラーや画面のチラつきもなく、極めて軽快なデスクトップ表示を確認しました。

5. 実務における要点と運用提言

  1. 極小帯域（10Mbps）環境では物理バックアップ搬送こそが最短ルート:
    細いWAN回線でのネットワークレプリケーションに固執すると、障害復旧のゴールデンタイムを逃します。変更差分が明確な環境であれば、検証済みのフルバックアップデータ（.vbk）とバックアップメタデータ（.vbm）を物理搬送してダイレクトインポートする方が、遥かに確実で予測可能な復旧時間を提供します。
  2. 異機種（V2V）移行における事前ドライバインジェクションの重要性:
    VMwareからKVM（VME）への移行で最大の難関となる0x7Bブルースクリーンを防ぐには、オフラインディスクに対するVirtIO注入機能の有無が成否を分けます。Veeamの自動インジェクション機能が有効に働くことで、わずか18分という極めて短時間での正常起動が担保されます。
  3. リストア後のデバイスマネージャー点検ルーティン:
    OS起動後は必ずデバイスマネージャーを開き、I/OコントローラがVirtIOで稼働しているか、旧ハイパーバイザーの管理エージェントが潜在的な競合を起こしていないかを最終確認する運用手順の確立が肝要です。