[Veeam] Windows サーバーのパスワード変更後に必要なサービスログオン情報の一括更新手順

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 サービス一覧とプロパティメニュー ...

2026-10-12 15:52 · CK notes

[HPE VME] Veeamリストア失敗の解決:VirtIOディスク番号重複(index=0)の修正手順

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のストレージ詳細設定を確認しました。 ...

2026-10-09 16:10 · CK notes

[HPE VME] VMwareバックアップ(VBK)から18分で異機種間リストア

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

2026-10-09 15:30 · CK notes

[日常] アウディA3 給油口キャップの切れたストラップゴムを5分でDIY交換

アウディ(Audi)やフォルクスワーゲン(Volkswagen)の車両を長年乗り続けていると、給油のたびに地味にストレスとなるトラブルが発生します。給油口キャップと車体をつなぐゴム製の脱落防止ストラップ(テザー)が経年劣化でぷつりと切れてしまう現象です。 ストラップが切れると、セルフ給油時に外したキャップの置き場に困り、計量機の上に不安定に置いたり、ボディ塗装面に触れて傷がつかないか気を遣うことになります。 正規ディーラーに相談した場合、ゴムストラップ単体での部品供給はなく、キャップアセンブリ(Assembly)ごとの丸ごと交換となるため、工賃込みで数千円から1万円以上の整備費用が発生します。 しかし、ネット通販で千円台の互換ゴムリングパーツとカッターナイフを1本用意すれば、車体に一切の傷をつけずわずか5分で綺麗にDIY交換できます。同一構造を採用しているアウディA3、A4、A6やフォルクスワーゲン ゴルフ、ティグアンなどの車種にも共通して適用できる作業手順と注意点をまとめます。 作業概要および準備物 項目 内容 対象車種 アウディ A3(VW ゴルフ、パサート、ティグアン、アウディ A4、A6など共通構造) 準備パーツ 給油口キャップ互換ゴムリングストラップ(曲線型オプション、送料込み約1,200円前後) 所要工具 カッターナイフ、作業用手袋(内張りはがしやドライバーは不要) 作業時間 約5分程度 難易度 低(切断と弾性を活かした押し込み結合のみ) 1. ストラップ断線の原因と交換パーツの準備 (写真:10年以上の歳月と度重なる給油による繰り返しの曲げ疲労と経年劣化で切れたゴムストラップ) 今回の断線は、キャップ自体の気密性低下や燃料蒸気漏れといった機能的な不具合によるものでは決してありません。10年以上にわたる愛車の運用の中で、数百回に及ぶ給油のたびにキャップを開閉し、ゴムストラップが繰り返しねじれや曲げ疲労(Bending Fatigue)を受けたことが根本原因です。これに四季の外気温差が長年加わったことで、ゴム素材が自然に弾性を失って徐々に硬化し、疲労限界を迎えてぷつりと破断した形です。キャップ本体の密閉性や内部バルブは健全そのものであるため、ストラップのみを交換すれば完璧に復旧できます。 (写真:キャップ側固定リングと車体側結合ホールが一体成形された互換パーツ) 今回用意した互換パーツです。給油口キャップ外周に嵌めるリングとストラップコード、車体側ピンに固定する円形アイレットホールが一体成形された構造となっています。 薄すぎず、純正同等の適度な厚みと復元弾性を備えており、耐久性も良好です。注文時は車両のキャップ形状に合わせて「曲線型」または「直線型」の適合オプションを選択します(アウディA3は曲線型が適合)。 2. 作業における最重要原則:車体側ピンの取り外し厳禁 (写真:車体給油口ハウジングに固定されたプラスチックピンのブラケット構造) 作業を開始する前に、最も注意すべき物理的注意事項があります。 ネット上の整備記事を参考にして、車体側リッド(カバー)に埋め込まれているプラスチック固定ピンを内張りはがしやマイナスドライバーでテコの原理を使って無理に引き抜こうとするケースが見られます。しかし、年式の経過した樹脂ブラケットは硬化が進んでおり、無理な力を加えるとピンやブラケット根元が破損します。ブラケットが破損すると給油口リッドアセンブリ全体の交換という大規模な修理に発展してしまいます。 したがって、車体側のピンには一切手を触れず、切れた古いゴムの残骸だけを切断して除去し、新しいゴムの柔軟性を利用して押し込む方式で作業するのが最も安全です。 3. 残留ゴムの切除と古いリングの取り外し (写真:プラスチックピンを傷つけないよう残ったゴムスリーブのみをカッターで切除する様子) まず、車体側の固定ピンに残っている古いゴムの切れ端をカッターナイフで慎重に切除します。内部のプラスチックピンの頭を削らないよう、外側のゴム部分だけに軽く刃を当てて切れ込みを入れれば、簡単に剥がれ落ちます。 (写真:給油口キャップ外周の溝に固定されていた古いプラスチックリングを切断除去) 続いて、キャップ本体の溝に嵌まっている古いリングを取り外します。手では溝に固着して外しにくいため、カッターナイフでリング外周の一箇所をスパッと切断すると、張力が抜けて簡単に外れます。 4. テーパー形状の確認と新品ゴムリングの装着 (写真:給油口キャップ本体のリング装着溝に見られる内向きの傾斜テーパー) 古いリングを外したキャップ本体を観察すると、リングが収まる溝が直角ではなく、内側に向かって傾斜(テーパー)がついていることが分かります。 (写真:新品互換リングの内側傾斜角度とキャップ装着方向の確認) 新品の互換ゴムリング内側の断面も、キャップ本体のテーパー傾斜角度と正確に噛み合うように成形されています。 傾斜の向きを確認後、キャップの片側から溝に引っ掛け、親指で外周に沿って均等に押し込んでいくと、ゴムの弾性により「パチン」と気持ちよく溝内部に嵌まります。工具を使わず素手だけでスムーズに装着可能です。 5. アライメント角度の確認と車体ピンへの最終固定 (写真:給油口キャップを軽く締めてストラップのねじれやクリアランス角度を事前確認) キャップにリングを取り付けたら、給油口キャップをネジ山に合わせて軽く締め込んでみます。キャップを閉めた状態でストラップがねじれたり無理なテンションがかからず、車体側ピンの位置と自然に一致する角度を確認するためです。 (写真:新品ストラップの先端ホールを車体固定ピンの頭に押し込み装着を完了した状態) 角度を確認したら、ストラップ先端の円形ホールを車体固定ピンの頭に当て、親指で奥へグッと押し込みます。ゴムの柔軟な弾性により、ピンのツバを乗り越えてカチッと確実に嵌合します。工具で車体側ピンを分解する必要が全くない理由がここにあります。 6. 作業結果の検証と費用比較 (写真:キャップ開放時にボディ塗装面に干渉せず安定して吊り下げられている完成状態) 取り付け後、給油口キャップを開けて保持状態を確認しました。手を離してもボディのフェンダー塗装面に直接接触せず、適度なクリアランスを保ちながら安定して吊り下がっています。 これで給油時のキャップ紛失リスクやボディへの傷の心配が完全に解消されました。 ディーラーアセンブリ交換 vs 互換パーツDIY交換の比較 評価項目 正規ディーラー(Assy丸ごと交換) 互換パーツによる自力交換(DIY) 修理方法 給油口キャップアセンブリ一式交換 切れたゴムストラップパーツのみ1:1交換 発生費用 約5,000円〜10,000円以上(部品代+工賃) 部品代 約1,200円(通販送料込み) 所要時間 入庫予約および工場待機 わずか5分(その場で完了) 車体破損リスク ピン強制脱着による破損リスクあり 車体側ピン非脱着(破損リスク0%) 仕上がり満足度 純正新品同等 純正同様の保持・脱落防止機能を完全復元 7. フィールドエンジニアの整備メモ 車体側ピンは絶対に無理に引き抜かないこと: ピンを外そうとしてブラケットを破損させると、給油口リッドアセンブリ全体の交換という大掛かりな修理になってしまいます。古いゴムのみを精密に切除し、新品の弾性を活かして押し込む方式が最も安全確実です。 冬場の作業アドバイス: 気温が低い冬場はゴムが硬化して硬くなっている場合があります。ぬるま湯に1〜2分浸して柔軟性を出したり、薄い石鹸水を微量塗布してから押し込むと、より一層スムーズに装着できます。 フォルクスワーゲン・アウディグループ(VAG)共通性: アウディA3のほか、A4、A6、Q3、Q5、VWゴルフ7、パサート、ティグアンなど、同世代の共通プラットフォームを採用する多数の車種で全く同一の構造と手順で作業が可能です。

2026-10-08 15:00 · CK notes

[HPE Alletra 9060] OS 9.6.30無停止アップグレード実務手順

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)を確認します。 ...

2026-10-04 17:30 · CK notes

[HPE Alletra MP B10K] ArcusOS 10.6.0新UI実務ガイド

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 ダッシュボード画面 ...

2026-09-30 07:00 · CK notes

[HPE Alletra MP B10K] OS 10.6.0無停止アップグレードガイド

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)を点検します。 ...

2026-09-28 21:00 · CK notes

[Cisco MDS] TempセンサーAmber LED解決とタイムゾーン設定

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 のセンサー誤診断バグであると判断できます。 ...

2026-09-27 15:30 · CK notes

[HPE SN6620C] Cisco NX-OS 9.4.5ファームウェア更新手順

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)を点検します。 ...

2026-09-27 15:00 · CK notes

【HPE Alletra 6000】OSファームウェアアップグレード実践ガイド

ベンダーの公式マニュアルは存在しますが、本記事は実際の現場で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)が正しく反映されているか確認します。 ...

2026-09-26 13:30 · CK notes