Veeam

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