KVM

KVMベースの HPE VM Essentials（VME）および HPE SimpliVity HCI 基盤の構築後、エンタープライズバックアップ標準である Veeam Backup & Replication を導入し、イメージバックアップおよびリストア検証（DR訓練）を実施することは、システム運用継続性において極めて重要な実務工程です。 しかし、VME上で既存バックアップから復旧した仮想マシン（VM）や特定テンプレートから展開されたインスタンスのうち、2つ以上の仮想ディスク（OSディスクおよびデータディスク）を構成するVMにおいて、Veeamリストア実行時にディスクマッピングの不一致エラーで処理が中断する事象に遭遇することがあります。 本稿では、実務現場で発生した VeeamのVirtIOディスク照合失敗エラーの原因を分析し、VME Managerの隠れた詳細設定（Cloud Advanced Options）を有効化してVirtIO番号を再割り当てする解決手順 を共有します。 1. 障害事象とVeeamリストアログのエラー内容 2台の仮想ディスクを持つVMに対してVeeamイメージバックアップを取得後、復旧検証のためにFull VM Restoreを実行したところ、以下のAPIエラーが出力されてリストアが停止しました。 In the Morpheus external infrastructure API response, the affected VM (vm-name) has two Virtio disks (id 11 and id 15) but both disks are reported with the same index value (index=0) and no diskLabel is provided. This makes disk identification ambiguous and may cause the restore workflow to fail disk-to-disk matching, resulting in the error: “Failed to match the original disk 15 to any disk of the restored VM.” エラーログの要点分析 Morpheus基盤のVME APIレスポンス: HPE VME Managerは内部的に実績あるクラウドオーケストレーション基盤（Morpheus）をベースとしてインフラAPIを処理しています。 ディスクインデックスの重複報告（index=0）: 対象VMに接続された2つのVirtIOディスク（id 11、id 15）が、いずれもインデックス番号 0 として応答し、個別のディスクラベルが欠落していました。 ディスク識別の競合による復旧遮断: 元バックアップとリストア先VMの間でディスクを1対1で正確にマッピングする必要があるVeeamにとって、双方が同一のバスアドレスに見えるため disk 15 を照合できず処理を中断したものです。 2. VME Manager上の設定確認：同一マウントポイント（VIRTIO 0:0） 原因を究明するため、HPE VME Managerコンソールで対象VMのストレージ詳細設定を確認しました。 ...

昨今、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 v11 Veeam Backup & Replication (VME Worker アーキテクチャ) バックアップ形式 フルバックアップデータ（.vbk）+ バックアップメタデータ（.vbm） ローカルリポジトリへ物理配置後 Import Backup ネットワーク環境 拠点間 10Mbps の極小帯域（物理複製が必須） 移行先内部の10G/25G高速ファブリック 対象ゲストOS Windows 10 Pro（VMware Tools導入済み） KVM VirtIOドライバによる正常クリーン起動 1. 10Mbps帯域の壁とオフラインバックアップ搬送戦略 回線帯域が10Mbpsに制限された拠点間では、転送遅延の観点から RPO（目標復旧時点、Recovery Point Objective） をオンラインで極小化することには物理的な限界が存在します。 ...

HPE SimpliVity with VME (VM Essentials) の2ノードクラスタを顧客先に導入する際、ほぼ確実に担当者から次のように要望されます： 「新しく導入した高スペックなSimpliVityサーバー2台の中に、Arbiter（仲裁者）VMも一緒に乗せて全部動かしてください。」 しかし、現場を知るインフラエンジニアであれば、この要望には 2つの重大なジレンマが存在することに即座に気づきます。 1. 現場のジレンマ：『鶏と卵の矛盾』と『ライセンスの罠』 ジレンマ1：SimpliVityストレージ作成前にArbiterが起動していなければならない 2ノードのSimpliVityクラスタは、展開ウィザードを実行する前にArbiter IPとの通信が確立していなければクラスタ作成を開始できません。まだノード初期化も終わっておらずストレージプールも存在しない状態で、SimpliVity上にArbiter VMを作成することは不可能です（鶏と卵の矛盾）。 さらに、Arbiterはスプリットブレインを防ぐ「審判」の役割を果たすため、自身が判定するストレージ基盤の内側に同居させることは絶対的な禁忌です。 ジレンマ2：VME GUIから作ると高額な有料ライセンスが請求される では、Arbiterはどこに配置すべきか？ 答えは VME Managerアプライアンスが稼働している外部管理ホスト（KVMベース）です。 しかし、ここでVME ManagerのWeb GUIコンソールから管理ホストを正式登録してVMを作成しようとすると、管理ホストの全物理CPUコアがVMEの有料ライセンス対象としてカウントされてしまいます！ わずか2コアの軽量なArbiter VMのために高価なライセンスを追加購入するのは現実的ではありません。 flowchart TD A["顧客要望: 『新規SimpliVityサーバーにArbiterも乗せて』"] --> B["ジレンマ: クラスタ展開前にArbiterが必須（鶏と卵）"] B --> C["解決策: 外部管理ホスト（VME Managerホスト）に配置"] C --> D{"VME ManagerのGUIから作成する？"} D -- "YES" --> E["❌ 警告: ホスト全CPUコアにVMEライセンス課金が発生！"] D -- "NO: エンジニアの現場ノウハウ" --> F["✅ KVM CLI(virt-install) + VNCでライセンス課金ゼロ構築！"] 2. 16年目エンジニアの実践的解決策：KVM CLI + VNCの組み合わせ 解決策は非常にシンプルです。 VME ManagerホストのOS（BaseOS）は 標準のLinux KVM / libvirt基盤です。 ...

1. 概要 VMwareはエンタープライズクラスの仮想化プラットフォームで長年の市場をリードしてきました。両方のプラットフォームには、目的と機能に差別化された強みがあります。 2.主な違い 1) アーキテクチャと基盤技術 VMware vSphere：ESXiハイパーバイザーベースの高度なVM管理機能を提供 HPE VME：KVMベース、HPE ProLiantサーバー+ Ubuntu OS、MorpheusプラットフォームでVMwareと同時管理可能 2) 管理と統合 VMware: vCenter 中心管理、VMware エコシステム(NSX、vSAN)と強力な統合 HPE VME：シングル管理コンソール（VME Manager）、HPE GreenLake、およびMorpheus統合、マルチハイパーバイザーのサポート 3) コスト構造 VMware：コアベースのライセンス→コストの増加、Broadcomの買収後のポリシーの変更 HPE VME：ソケットベースのライセンス→シンプルで予測可能、最大70％のコスト削減 4) 機能差別点 VMware：vMotion、DRS、SR-IOVなどの高度な機能を提供 HPE VME: 内蔵バックアップ・復旧、データ重複除去・圧縮、単純性強調（NSXレベルネットワーク自動化は未サポート） 5) 拡張性と柔軟性 VMware: さまざまなハードウェア互換性、クラウドネイティブ、コンテナ統合の強化 HPE VME: HPE GreenLake ベースのクラウド拡張、高速構築 3. 比較表 アイテム VMware vSphere HPE VME (VM Essentials) ハイパーバイザー ESXi KVMベース 管理プラットフォーム vCenter VME Manager + Morpheus 統合性 VMwareエコシステム（NSX、vSAN） HPE GreenLake、VMwareを同時管理可能 ライセンス コアベース(コスト増加) ソケットベース(予測可能、コスト削減) 高度な機能 vMotion、DRS、SR-IOVなど バックアップ・復旧、重複除去・圧縮（単純性強調） 拡張性 さまざまなハードウェア、クラウドネイティブ HPE ProLiantベース、GreenLake拡張可能 コスト効率 比較的高い 最大70％削減可能 4. 重要な要約 VMware：エンタープライズクラスの機能とエコシステムの統合における強み、しかしコストと複雑さの負担 HPE VME: シンプルさ、コスト効率、ハイブリッド管理における強み、VMware環境と共存可能 5. 参考ソース [HPE公式サイト - VMEについて]（https://www.hpe.com） [VMware vSphere 製品ページ] (https://www.vmware.com) [HPE VME vs VMware比較レビュー]（https://www.hpe.com/greenlake/vme）