トラブルシューティング

1. 背景: Windows パスワード更新直後に発生する Veeam サービス起動停止 企業の IT インフラ運用現場では、セキュリティ診断ガイドラインや定期的な資格情報更新ポリシーに従い、Windows Server のローカル管理者（Administrator）パスワードの変更や専用管理アカウントへの移行が実施されます。 しかし、**Veeam Backup & Replication（VBR）**が稼働するバックアップ管理サーバー上で Windows のパスワードを変更した直後、以下のような問題が発生し緊急障害へと発展するケースが多発します。 Veeam Backup & Replication Console 起動時にログオン画面で停止、または接続エラーが発生する。 Windows イベントログに Event ID 7000 / 7038（ログオンの失敗によりサービスを開始できませんでした） が記録される。 サービス管理画面（services.msc）から手動で起動を試みると エラー 1069（ログオン失敗） が返される。 [Windows サービスエラーメッセージ] エラー 1069: ログオンに失敗したため、サービスを開始できませんでした。 (Error 1069: The service did not start due to a logon failure.) この現象は、Veeam のバックアップエンジンやカタログサービス、ブローカーなどの中核バックグラウンドサービスが、インストール時に指定した管理者アカウント権限で稼働するように登録されているために発生します。Windows アカウントのパスワードのみを変更し、サービスプロパティ内の認証情報を更新しない場合、サービスの認証が通らず一斉に停止します。 2. 事前確認: 影響を受ける主な Veeam サービス一覧 Veeam サーバーには多数の常駐サービスが存在します。パスワード更新が必要となる代表的なサービスは以下の通りです。 サービス名 (Service Name) 表示名 (Display Name) 役割 VeeamBackupSvc Veeam Backup Service バックアップ/リストア処理およびスケジュール制御の中核エンジン VeeamBrokerSvc Veeam Broker Service インフラ構成情報の通信ブローカーサービス VeeamCatalogSvc Veeam Guest Catalog Service ゲスト OS ファイルインデックスおよび検索管理 VeeamCloudSvc Veeam Cloud Connect Service クラウドリポジトリおよびテナント連携サービス VeeamEnterpriseManagerSvc Veeam Backup Enterprise Manager エンタープライズ統合管理 Web サービス VeeamRESTSvc Veeam Backup Server RESTful API Service VBR REST API 連携用エンドポイント [図 1] Windows サービス管理画面（services.msc）の Veeam サービス一覧とプロパティメニュー ...

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 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基盤です。 ...