HPE

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） をオンラインで極小化することには物理的な限界が存在します。 ...

1. はじめに：HPE Alletra 9000 系列ファームウェア更新の重要原則 企業の最重要ミッションクリティカル基盤を支える HPE Alletra 9060（Alletra 9000 / Primera アーキテクチャベース） ストレージは、デュアルまたはクアッドコントローラー構成により、完全無停止（Online）でのファームウェアアップグレードに対応しています。 Alletra 9000 系列のOS更新において最も重要な前提条件は、最新の Upgrade Tool（UT）の事前準備です。ストレージOS本体を適用する前に、対象バージョンに対応した Upgrade Tool をシステムに先行登録しておくことで、正確な事前適合性チェック（Readiness Check）と安全なローリングノード再起動が実現します。 本記事では、実運用中の HPE Alletra 9060 実機をベースに、OS 9.6.5 から OS 9.6.30（Extended Support Release） への無停止アップグレード手順と現場での確認ポイントを解説します。 2. 作業前の事前準備とパッケージ入手 2.1. 必須パッケージの入手手順 Alletra 9000 および Primera のファームウェアとツールは、HPE 公式ライセンスポータルより入手します： HPE Enterprise License Portal（My HPE Software Center） へアクセス Software メニュー ➔ 保守契約情報（SAID）またはシリアル番号を入力 以下のパッケージをダウンロード： 最新 Upgrade Tool パッケージ: Upgrade Tool 80（build 260625） 以降 対象 OS ファームウェアパッケージ: HPE Alletra 9000 OS 9.6.30.xx（tar/iso 形式） 2.2. 事前確認チェックリスト ホスト I/O マルチパス（Multipath）正常性の確認: ノード再起動時に残存ノードへ I/O が集約されるため、接続ホスト（15台以上）のマルチパス稼働パスを確認 ストレージハードウェアおよびシステム健全性の点検: コントローラーノード、電源モジュール、ドライブエンクロージャーの正常性（OK）および未解決アラート（New alerts: 0）の確認 備考（Remote Copy およびスケジュールジョブ）: 最新の Alletra/Primera OS はノードのローリング再起動時にもリモートコピー（Remote Copy）セッションやスケジュールを安全に自律制御するため、特定のリリースノート・アドバイザリ（Advisory）がない限り、手動停止を行わずオンラインのまま作業を進めます。 3. ステップ別 無停止アップグレード実務手順 Step 1. 事前ダッシュボードおよびシステム健全性の点検 Webコンソールにログインし、システムアラート（New alerts: 0）、利用可能容量、ホスト接続状態を確認します。System ➔ Software より現在の稼働バージョン（9.6.5）を確認します。 ...

1. はじめに：10.6.0 全面刷新とホワイトツリーUIの導入背景 HPEの次世代モジュラー型オールNVMeストレージである HPE Alletra Storage MP（B10120 / B10K）環境において、OSファームウェアが10.6.0 へアップデートされたことに伴い、システム管理インターフェースが大幅に刷新されました。 従来の10.5.x系まで採用されていた単一階層のダークサイドバーUIから脱却し、10.6.0からは クラウドネイティブ感覚のモダンなホワイトテーマと、直感的な多階層ツリーナビゲーション構造 が新たに導入されています。 本記事では、実機環境の Alletra Storage MP B10K をベースに、10.6.0 新UIにおけるメニュー構造の変化点と、エンジニアリング実務の観点から重要なモニタリングポイントを整理して解説します。 2. 10.5.x vs 10.6.0 UI比較 比較項目 従来UI (OS 10.5.50 以前) 新規UI (OS 10.6.0) 実務におけるメリット テーマデザイン 暗いダークグレーのサイドバー 明るくモダンなホワイトカードベースUI 視認性が大幅に向上、最新HPE GreenLake統合ルック＆フィール 左側ナビゲーション 単純なアイコン中心の単一階層 テキストラベル付き多階層折りたたみツリー 下位メニュー（ドライブ、ポート等）へ1クリックで即時遷移可能 上部ブランディング 基本シンボルアイコンのみ表示 HPEロゴおよび製品モデル名を明記 複数ストレージの同時運用時における識別性が向上 ポート/スイッチ管理 詳細ハードウェア配下を探索 Ports / Switches が独立メニューとして常時表示 SANファブリックのリンク状態やポート速度を即座に確認可能 セキュリティ・設定統合 各所に分散していた設定項目 Settings 配下にネットワーク/テレメトリ/証明書を集約 セキュリティポリシー（ランサムウェア検知、保持期間）のワンストップ設定 アップグレード前／後の System 画面比較 図 1. [アップグレード前] OS 10.5.50 ダークサイドバー採用の従来 System ダッシュボード画面 ...

1. 背景: Alletra MP 10.6.0 アップグレードと新UIへの刷新 ミッションクリティカルストレージである HPE Alletra Storage MP (B10K / B10120)において、システムの安定性向上と最新機能のサポートを目的とした10.6.0 OSファームウェアアップグレード を実施しました。 今回の10.6.0リリースは、バックエンドの性能向上とプラットフォームの安定化だけでなく、Web管理コンソールが従来のダークサイドバーからモダンなホワイトツリー型新UIへと大幅に刷新される重要なアップデートとなっています。 ストレージがインターネット(HPE Cloud Connect)に接続されている環境であれば、10.6.0ファームウェアパッケージが自動的にStaged(事前ダウンロード) されているため即座に作業を開始できます。閉域網環境の場合でも、ローカルコンソールからファイルを直接アップロードして安全に適用可能です。 2. 環境および前提条件 項目 スペック / 設定情報 実務上の設定理由 対象ストレージ HPE Alletra Storage MP B10120 2ノード アクティブ-アクティブ エンタープライズブロックストレージ 現行OSバージョン OS 10.5.50 既存稼働ファームウェアバージョン ターゲットOSバージョン OS 10.6.0 (ArcusOS) 新UI対応およびプラットフォーム安定化推奨バージョン パッケージ準備方式 オンラインStaged / ローカルファイル手動アップロード インターネット接続時は10.6.0自動受信済み 事前必須検証 System Readiness Checks アップグレード前に100% Passed確認が必須 想定所要時間 約60分 〜 90分程度 ノード順次再起動およびCDMコンポーネント書き込み含む 3. 実践アップグレード手順 (ステップ別) Step 1. 現在のOSバージョンおよびダッシュボード状態の点検 作業を開始する前にオンプレミスWebコンソールへログインし、System ➔ Dashboard にて現行OSバージョン(10.5.50)と各コントローラー、シャーシ、IOMモジュールの正常稼働状態(OK)を点検します。 ...

1. 背景: サーバールームは低温なのに、なぜスイッチ前面にAmber LEDが点灯するのか？ データセンター現場での保守作業時、室温は18〜20°Cと十分に涼しく保たれているにもかかわらず、Cisco MDS 9148T (HPE SN6620C) ストレージスイッチ前面パネルのSYS/ENVステータスLEDがオレンジ色(Amber)に点灯している現象によく遭遇します。 実際に show environment コマンドで内部センサー温度を確認すると 32°C (Normal) と極めて正常な状態であるにもかかわらず、NX-OS 9.2.2 のセンサーポーリング処理バグ(CSCwo09244等)によって閾値超過アラートが誤検知され、警告灯が点灯してしまうのが原因です。 本記事では、温湿度センサー誤診断によるAmber LED問題の原因と、推奨安定版9.4.5へのアップグレードによる根本的解決手順、さらに障害解析時にログのタイムスタンプ齟齬を防ぐためのタイムゾーン(Timezone)設定方法を整理します。 2. 環境および前提条件 項目 スペック / 設定情報 実務上の設定理由 対象機器 Cisco MDS 9148T / HPE SN6620C 32G Enterprise FC SAN スイッチ 発生バージョン Cisco NX-OS 9.2(2) 温湿度センサーポーリング誤診断バグが存在 対処完了バージョン Cisco NX-OS 9.4(5) センサーポーリングおよびプラットフォーム監視バグ修正済み 適用タイムゾーン Timezone (KST/JST, UTC+9) 標準時基準でのログ解析同期化 3. 実践対処および設定手順 作業前のスイッチ前面LEDおよびステータス点検画面 Step 1. 温湿度センサーおよび環境ステータスの点検 前面のAmber LEDが点灯した際、ハードウェア故障かソフトウェアバグかを切り分けます。 # 環境センサーおよび温度情報の詳細確認 show environment temperature 出力結果で全センサー項目が OK かつ正常温度範囲(Normal)内にあるにもかかわらずAmber LEDが消灯しない場合、NX-OS 9.2.2 のセンサー誤診断バグであると判断できます。 ...

1. 背景: なぜ 9.4.5 バージョンへのアップグレードが必要だったのか？ HPE SN6620C (Cisco MDS 9148Tベース) 32Gb FC SANスイッチを運用中のお客様環境において、安定性向上のためのファームウェア更新を実施しました。 旧バージョンの9.2.2では、長期稼働時の環境センサー誤検知やISSU実行時のBIOSタイムアウトの懸念が報告されていました。そのため、HPEおよびCisco公式の 推奨安定バージョン(Recommended Release)であるNX-OS 9.4(5)へのアップグレードを決定しました。 外部接続が遮断された閉域網環境であるため、エンジニアの作業用ノートPCにRebex Tiny SFTP/SCP Serverを起動し、ローカル接続でファームウェアを転送する方式を採用しました。 2. 環境および前提条件 項目 スペック / 構成情報 実務上の設定理由 対象スイッチ HPE SN6620C (Cisco MDS 9148T OEM) 32Gbps ファイバチャネル(FC) SAN スイッチ 現行 NX-OS バージョン 9.2(2) 既存稼働バージョン ターゲット NX-OS バージョン 9.4(5) HPE/Cisco 推奨安定版 (Recommended) 転送プロトコル SCP (Secure Copy Protocol) 作業PC ↔ スイッチ Managementポート直結転送 SCP サーバーツール Rebex Tiny SFTP/SCP Server インストール不要のポータブルSCPサーバー ファームウェアファイル m9000-pkg2.9.4.5.bin, m9000-kickstart-pkg2.9.4.5.bin システム(System)およびKickstartバイナリパッケージ 3. 実践アップグレード手順 (ステップ別) Step 1. 現在のOSバージョンおよびスイッチ状態の確認 作業開始前にスイッチCLIに接続し、現行バージョン(show version)とモジュール/ポート状態(show module)を点検します。 ...

ベンダーの公式マニュアルは存在しますが、本記事は実際の現場でHPE Alletra 6000の新UIを使用してOSアップグレードを実施した際の実務記録です。初めて作業する方にとって、UI画面のキャプチャがないとファームウェア更新のイメージを掴みにくい場合があるため整理しました。現場の環境やバージョンによって順序が若干異なる場合がありますので、実務の参考としてご活用ください。 📌 作業概要 現在のOSバージョン: 6.1.2.500 ターゲットOSバージョン: 6.1.3.300 所要時間: 約 2時間前後（ダウンロード、ノードの順次再起動、ファームウェア適用時間を含む） 1. ファームウェアイメージの準備 (インターネット vs ローカル) AlletraストレージはOSアップデートファイルの準備方法として2つの方式をサポートしています。 インターネット直接ダウンロード: ストレージが外部（HPE InfoSight等）と通信可能な環境であれば、UI上から直接最新バージョンを確認してダウンロードできます。 ローカルファイルアップロード: 閉域網環境や特定バージョンを手動適用する場合、PCに事前ダウンロードしたファイルをブラウザ経由でアップロードします。 Alletra 新UI メインダッシュボード画面 2. アップグレード手順 Step 1. ソフトウェア(Software)メニューへ移動 管理者アカウントでログイン後、メインメニューの ソフトウェア(Software) 項目へ移動します。現在インストールされているバージョン(6.1.2.500)と利用可能なアップデート情報が表示されます。 ソフトウェア管理メニュー画面 Step 2. ファームウェアファイルのダウンロード/アップロード 選択した方式に応じて手順を進めます。 インターネット直接ダウンロード: 「ダウンロード」ボタンをクリックすると、利用可能なOSバージョン一覧が表示されます。 ローカルアップロード: 「Browse(参照)」ボタンを押して、ローカルPCのファームウェアファイル(.iso/.img)を選択しアップロードを実行します。 ダウンロードボタンクリック時に表示される利用可能OSバージョン一覧画面 ローカルアップロード用ファームウェアファイルを選択するため「Browse(参照)」ボタンを押す画面 選択したファームウェアファイルのアップロード進行画面 インターネットダウンロードおよびファイル適用進捗画面 Step 3. 事前チェック (Pre-check) および Updateボタンの有効化 ファイルの準備が完了すると、システム事前チェック(Pre-check)が自動実行されます。(※キャプチャ漏れ) チェック結果が正常(Passed)になると、無効化されていたUpdate(アップデート)ボタンが有効化されます。 Step 4. UpdateボタンのクリックとEULAライセンス同意 有効化されたUpdateボタンを押すと、最終EULAライセンス同意ポップアップが表示されます。内容を確認し同意を進行します。 Updateボタンクリック後に表示されるEULAライセンス同意画面 Step 5. OSおよびファームウェア更新の進行状況モニタリング ライセンス同意完了後、コントローラーノードが順次再起動しながらファームウェアが適用されます。新UIでは進捗率(%)がリアルタイムで表示されます。 OSアップデート進行画面 Step 6. アップグレード完了と最終バージョンの確認 すべてのノードの再起動と適用が完了したら、ダッシュボードでターゲットバージョン(6.1.3.300)が正しく反映されているか確認します。 ...

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など）のみを接続してサービスを開始しなければならないケースがよくあります。 ...