SimpliVity

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 6.2.0およびVME（VM Essentials）クラスターのデプロイが完了したら、次はインフラ上で実業務を担う仮想マシン（VM、Instance）を作成し、OS（Linux、Windowsなど）をインストールする段階に入ります。 VME環境で仮想マシンを作成してOSをセットアップするには、OSインストール用ISOファイルを仮想イメージライブラリにあらかじめ登録しておく必要があります。特に大容量のISOファイルが安定して保存され、クラスター内の全ホストから共通参照できるように、事前にNFSファイル共有ストレージ（File Share）をVME Managerに連携しておくことが基本設計となります。 本記事では、管理サーバー上のNFS共有フォルダーをVME Managerのイメージストアとして登録し、実際のOSインストール用ISOイメージをアップロードしてストレージパスを検証するまでの全手順を整理しました。現場での大容量ファイルアップロード時のタイムアウト回避策やアクセス権限のポイントも併せて解説します。 1. 全体作業ワークフロー VME ManagerへのISO仮想イメージ登録は、ストレージバックエンド確認からファイル共有登録、ISOアップロード、ストレージパス検証までの4段階で進行します。 flowchart TD Step1["第1段階：NFSサーバー公開状態確認<br/>(ホストCLI: exportfs -v)"] --> Step2 Step2["第2段階：VME ManagerへのNFSファイル共有登録<br/>(インフラ > ストレージ > ファイル共有 > NFSv3)"] --> Step3 Step3["第3段階：仮想イメージライブラリへのISO登録<br/>(ライブラリ > 仮想イメージ > + 追加 > ISO)"] --> Step4 Step4["第4段階：アップロード完了およびストレージパス確認<br/>(morpheus-virtual-images 配下確認)"] 2. 作業前の重要チェックポイント 作業をスムーズに進めるため、事前に以下の3点を確認しておきます。 「デフォルトの仮想イメージストア」の指定 VME ManagerでNFSファイル共有を登録する際、画面下部の デフォルトの仮想イメージストア (Default Virtual Image Store) チェックボックスを必ず有効化します。これにより、今後仮想イメージを登録する際に該当NFSが既定のストレージバケットとして自動割り当てされ、VM作成時に全ホストからスムーズに参照できるようになります。 NFSアクセス権限の設定 (no_root_squash) VME ManagerサービスがNFSサーバー上にISOファイルを書き込み、内部フォルダーを作成できるように、管理サーバーの /etc/exports に rw,no_root_squash,no_subtree_check オプションが正しく設定されていることを確認します。 VMEにおけるISO保存ディレクトリ構造 VME Webコンソール経由でISOを登録すると、NFS公開フォルダー（例: /nfs）の直下ではなく、/nfs/morpheus-virtual-images/<固有数字ID>/<ファイル名.iso> という階層で整理されて安全に保管されます。 3. ISOイメージ登録手順 Step 01. NFSサーバー公開状態の確認 (CLI) 管理サーバー（Ubuntu BaseOS）に構築したNFSサービスが、共有ディレクトリ（/nfs）を正常にエクスポートしているかをターミナルで確認します。 ...

HPE SimpliVity HVMやVME（VM Essentials）環境の初期セットアップ直後は、デフォルトの管理ネットワーク（Management）のみが構成されている状態です。実際の業務仮想マシン（VM）を本番稼働させるには、サービス用データネットワークや業務別VLANを追加する作業が不可欠となります。 作業の流れは大きく2段階に分かれます。まず物理ホストレベル（HPE VM Console TUI）でボンディングインターフェースを作成し、その後VME Manager WebコンソールでOVS（Open vSwitch）ルーターとして登録し、仮想マシンへ割り当てる手順です。 本記事では、TUIコンソールでのボンディング設定からVME Webコンソールでのルーターマッピング、VMへの割り当てまでの標準手順を整理しました。さらに、現場で物理ポートが1本（Single NIC）しか接続できない状況であっても、なぜ最初からボンディングで構成しておくべきなのかという実務的な理由と、OVS設定時のトラブルシューティングポイントを併せて解説します。 1. 全体作業ワークフロー HVMホストに外部ネットワークを追加してVMに接続する構成は、物理ホスト層と仮想化管理層で明確に分離されています。 flowchart TD subgraph HostLevel["第1段階：物理ホストレベル (HPE VM Console TUI)"] A1["HPE VM Consoleアクセス<br/>(Configure Network)"] --> A2["Device Type: bond(0) 選択およびAdd"] A2 --> A3["Bondデバイス名指定<br/>(例: net-10g)"] A3 --> A4["物理インターフェース選択<br/>(例: eno2)"] A4 --> A5["ボンディングモード設定<br/>(active-backup等)"] A5 --> A6["Save & Netplan適用<br/>(Netplan changes applied)"] end subgraph VMELevel["第2段階：管理Webコンソール (VME Manager Web GUI)"] B1["Infrastructure > Network > Routers 移動"] --> B2["+ Add クリックして新規ルーター追加"] B2 --> B3["GROUP / CLOUD / NAME / CLUSTER /<br/>Host Bridge & Network Interface マッピング"] B3 --> B4["ルーター状態検証<br/>(STATUS: OK, OVS Bridge Domain)"] B4 --> B5["仮想マシン(Instance) Reconfigure<br/>(新規ネットワーク net-10g 追加割り当て)"] end HostLevel --> VMELevel 2. 実務設計原則：「シングルNIC（単一ポート）環境でもなぜボンディングで組むべきなのか」 現場導入を進めていると、上位L2/L3スイッチ側のポート手配が遅れていたり、ラック配線スケジュールの関係で、当面は物理ポート1本（eno2など）のみを接続してサービスを開始しなければならないケースがよくあります。 ...

昨今、VMwareのライセンス体系刷新を契機に、KVMベースの軽量な仮想化基盤への移行を検討する企業が急速に増えています。その有力なエンタープライズ選択肢の一つが、HPE SimpliVity 6.2.0 と HPE VM Essentials (VME) によるHCI基盤です。 16年間にわたり現場でサーバーやストレージを構築してきた経験から断言できるのは、HCI構築の成否は **「事前にネットワークセグメントとArbiter（仲裁者）構造をどれだけ緻密に設計したか」**に9割以上かかっているということです。 本記事では、事前ネットワーク設計から外部管理インフラ構築、物理ノード初期化、VME Managerを通じたクラスタおよびOVC（仮想コントローラ）自動展開までの全工程を、現場エンジニアの視点で要点だけを凝縮して解説します。 1. 失敗しない2ノードネットワーク設計（現場の鉄則） 2ノード構成は高いコストパフォーマンスを誇りますが、物理リンクと論理VLANが厳密に分離されていないと、ストレージトラフィックと制御通信が干渉しクラスタ障害を引き起こします。 必須5大ネットワークセグメント セグメント名 推奨帯域 MTU 役割および現場の注意事項 1. iLO Out-of-Band 1 Gbps 1500 物理サーバーのリモート監視および仮想コンソール専用。 2. Management（管理網） 1 Gbps / 10 Gbps 1500 ホストBaseOS、VME Manager UI、OVC管理通信用。 3. Storage（ストレージ網） **10 Gbps / 25 Gbps ** 9000 (ジャンボ) 【最重要】 ノード間のリアルタイムデータミラーリング。エンドツーエンドでMTU 9000必須。 4. Federation（連携網） 10 Gbps 1500 SimpliVity OVC間のクラスタメタデータ同期用。 5. VM Workload（業務網） 10 Gbps 1500 稼働するテナント仮想マシンのサービス通信用（VLAN分離）。 💡 現場トラブルシューティングのツボ：ジャンボフレーム（MTU 9000）不整合 ホスト側だけMTU 9000に設定し、対向のL2スイッチ側でジャンボフレームを有効化し忘れると、パケットが静かにドロップされます。OVC展開が70〜80%でタイムアウト停止する場合、99%ストレージスイッチのMTU設定漏れが原因です。 ...

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. 概要 HPE SimpliVityは、ハイパーコンバージドインフラストラクチャ（HCI）に基づいてコンピューティング、ストレージ、ネットワークを統合提供するソリューションです。 ストレージアーキテクチャは RAID + RAIN構造とNFSプロトコルに基づいており、VMwareベースのSimpliVityとVMEには共通点と相違点があります。 2. ストレージアーキテクチャのコア構成 1) RAID+RAIN構造 RAID (Local): 各ノード内で RAID を構成し、ディスク障害に備えて RAIN (Cluster): クラスタ内の他のノードへのデータの複製 → ノードの障害にもデータの整合性を確保 二重保護構造により高レベルの 高可用性(HA)を確保 2) NFSプロトコルベースのデータストア VMware ESXiまたはVME環境で NFSデータストアを使用する OmniStack（VMwareベース）またはVMEソフトウェアがローカルストレージを仮想化して 論理ストレージプールを提供 仮想マシン（VM）はこのNFSデータストアを介して安定して運用されています 3) データ効率 重複除去(Deduplication)+圧縮(Compression) 技術によりストレージスペースを節約 内蔵バックアップおよびリカバリ機能を提供 → 外部ストレージなしで独自のDR（災害復旧）可能 3. VMwareベースのSimpliVity vs HPE SimpliVity VME比較表 アイテム VMwareベースのSimpliVity HPE SimpliVity VME ストレージプロトコル NFSベース NFSベース データ保護方式 RAID+RAIN+OmniStackアクセラレーションカード RAID+RAIN(ソフトウェア定義方式) ハードウェアの依存関係 OmniStack Accelerator Cardが必要 追加のハードウェア不要、標準のx86サーバーベース 管理プラットフォーム VMware vCenter 統合 VME Manager + Morpheus(VMwareと同時管理可能) 拡張性 ノードをさらに拡張可能 同様にノードベースの拡張可能 バックアップ/回復 内蔵機能を提供 同様に内蔵機能を提供 コスト構造 VMwareライセンス+ OmniStackカードのコスト ソケットベースのライセンス（VMwareと比較して最大70％削減可能） 4. VME アーキテクチャの追加の利点 ハードウェアの簡素化：OmniStackカードの取り外しにより、障害点の削減とメンテナンスが容易 ソフトウェア定義方法：最新のOS（Ubuntuベース）とオープンソース技術を活用して柔軟性と更新速度を向上 IPv6および近代的なネットワークサポート：次世代ネットワーク環境に最適化 管理効率: Morpheus統合により、VMwareとVMEを同時に管理できるハイブリッドオペレーティング環境を提供 クラウドに優しい：HPE GreenLakeインターロックによるオンプレミス+クラウドのスケーラビリティを強化 5. 重要な要約 共通点：RAID + RAIN構造、NFSプロトコルベースのデータストア、内蔵バックアップ/回復機能 違い：VMwareベースはOmniStackカードが必要、VMEはソフトウェア定義の方法でシンプルさとコスト効率を強化 6. 参考ソース [HPE SimpliVity公式製品ページ]（https://www.hpe.com/us/en/integrated-systems/simplivity.html） [HPE VME リリースノート Documentation] (https://support.hpe.com/hpesc/public/docDisplay?docId=a00156081en_us&docLocale=en_US) [HPE InfoSightソリューションガイド]（https://www.hpe.com/us/en/solutions/infosight.html）

1. ソリューションの概要 HPE SimpliVity VME（Virtual Machine Essentials）は、ハイパーコンバージドインフラストラクチャ（HCI）に基づくエンタープライズ仮想化プラットフォームであり、コンピューティング、ストレージ、ネットワークを単一アーキテクチャに統合することで、運用の複雑さを軽減し、データ効率と高可用性を提供するソリューションです。 従来の3-Tierアーキテクチャ（サーバー、SANスイッチ、外付けストレージ）の複雑さを排除し、KVMベースの軽量仮想化環境とHPE OmniStack仮想ストレージコントローラー（OVC）を組み合わせることで、オンプレミスインフラの効率的な運用を実現します。 2. 主なアーキテクチャの特徴 インラインデータ重複排除および圧縮: ストレージ書き込み時にリアルタイムでデータを圧縮・重複排除し、利用可能容量を最大化します。 RAID + RAINの二重データ保護: ノード内部のローカルハードウェアRAIDと、ノード間のネットワークレプリケーション（RAIN）を組み合わせ、単一ディスクやノードの障害時にも無停止サービスを保証します。 内蔵バックアップと超高速リカバリ: ストレージレベルのメタデータスナップショットにより、数秒以内にVMのバックアップおよび復旧が可能です。 シンプルなスケールアウト拡張: ワークロードの増加に合わせてノードを追加するだけで、コンピュートとストレージのプールを線形に拡張できます。 3. 構築および運用の流れ 実際の現場での構築は、事前ネットワーク設計から管理サーバーおよびノードの初期化へと進みます: 事前ネットワーク設計: iLO OOB、Management、Storage/Federation、VMトラフィックのVLAN分離およびMTU 9000の設定 管理インフラの展開: BaseOS（HVM）の構成、主要サービス（NTP/DNS/NFS）の準備、VM Essentials ManagerおよびArbiter VMのインストール ノード Initial Setup: SimpliVityノードのファームウェア更新および初期ネットワークパラメータの設定 クラスター作成およびOVC展開: VME ManagerをベースにHVMクラスターを構成し、OmniStack Virtual Controllerを展開 💡 詳細構築ガイド: 実際の段階的な構築手順は、HPE SimpliVity 6.2.0 実践構築連載シリーズ で現場画面とともに詳しく解説しています。 4. 運用と管理 導入完了後は、統合管理コンソール（VME Manager / Morpheus）を通じてVMの作成、リソース監視、データストア拡張を一元的に管理します。 また、HPE InfoSight のリモート分析エンジンと連携することで、ハードウェアの障害予兆やストレージ容量の枯渇を事前に検知し、プロアクティブな予防保全を実施できます。 5. まとめ HPE SimpliVity VMEは、高価な外部SANストレージや複雑なファブリック構成を必要とせず、エンタープライズ水準の高可用性とデータ効率を提供するソリューションです。ハイパーバイザーライセンスコストの増大を見直す際、既存仮想化基盤の刷新とコスト最適化の有力な選択肢となります。