VMware vSAN 8.0 Update 2 | 2023 年 9 月 21 日 | ISO ビルド 22380479

リリース ノートに追加または更新された内容をご確認ください。

リリース ノートの概要

これらのリリース ノートでは、VMware vSAN 8.0 Update 2 の新機能を紹介し、既知の問題に関する情報を提供します。

新機能

vSAN 8.0 Update 2 には、次の新機能および機能強化が含まれています。 

  • 分離されたストレージ

    vSAN Express Storage Architecture との分離のためのトポロジが強化され、vSAN OSA と vSAN ESA の機能パリティが提供されます。

    vSAN ESA による分離されたトポロジのストレッチ クラスタのサポート。vSAN ESA は、vSAN ストレッチ クラスタを使用する場合、分離をサポートします。複数のストレッチ クラスタ構成のサポートに加えて、vSAN は特定のトポロジのネットワーク パスを最適化し、ストレッチ クラスタ構成のパフォーマンス機能を向上させます。

    複数の vCenter Server を使用したクラスタ間の分離のサポート。vSAN 8.0 Update 2 では、vSAN ESA 使用時に複数の vCenter Server を使用する環境間での分離がサポートされます。これにより、1 つの vCenter Server によって管理される vSphere または vSAN クラスタは、別の vCenter Server によって管理される vSAN クラスタのストレージ リソースを使用できます。

    分離されたストレージの vSAN ESA 適応型書き込みパス。分離された展開では、vSAN 8.0 Update 1 で以前に標準 ESA ベースの展開に対して導入された新しい適応型書き込みパスのパフォーマンス上のメリットが得られます。別の vSAN ESA クラスタのストレージを使用する vSphere または vSAN クラスタで実行されている仮想マシンは、この機能を利用できます。分離された環境での適応型書き込みパス テクノロジーにより、管理者の操作なしで、自動的にリアルタイムで仮想マシンのスループットを向上させ、遅延が低減させることができます。

  • コア プラットフォームの機能強化

    クラウド ネイティブおよび従来のワークロード用の統合ファイル サービス。vSAN 8.0 Update 2 は、vSAN Express Storage Architecture 上で vSAN ファイル サービスをサポートします。ファイル サービス クライアントは、vSAN ESA によって提供されるパフォーマンスと効率の向上によってメリットを得ることができます。

    vSAN ESA での適応型書き込みパスの最適化。vSAN ESA では、クラスタによるデータの取り込みと処理をより迅速に行うことができる適応型書き込みパスが導入されています。この最適化により、単一オブジェクト (VMDK) に対して高い I/O を実行するワークロードのパフォーマンスが向上し、クラスタ全体のパフォーマンスも向上します。

    vSAN ESA クラスタ内のホストあたりの仮想マシン数が増加しました（最大 500/ホスト）。vSAN 8.0 Update 2 では、基盤となるハードウェア インフラストラクチャでサポートできる場合、vSAN ESA クラスタ上のホスト仮想マシン 1 台あたり最大 500 台の仮想マシンをサポートします。コア密度が高い最新世代の CPU 用に最適化された NVMe ベースの高性能ハードウェア プラットフォームを活用し、ホスト 1 台あたりでより多くの仮想マシンを統合できるようになりました。

    新しい ReadyNode プロファイルおよび vSAN ESA の読み取り集約型デバイスのサポート。vSAN ESA は、小規模なデータセンターおよび Edge 環境向けに設計された新しい ReadyNode プロファイルの可用性を発表し、全体的なハードウェア要件をノード単位で低くします。このリリースでは、読み取り集約型ストレージ デバイスのサポートも導入されています。

    vSAN ESA による暗号化の深い再キー化のサポート。保存データの暗号化を使用する vSAN クラスタで、深い再キー化操作を実行できます。深い再キー化は、古い暗号化キーを使用して vSAN クラスタに暗号化および保存されたデータを復号化し、vSAN クラスタに保存する前に、新しく発行された暗号化キーを使用してデータを再暗号化します。

  • 充実した操作

    vSAN ESA の規範的なディスク要求。vSAN ESA には、vSAN クラスタ内の各ホストのストレージ デバイスの管理をさらに簡素化する規範的なディスク要求プロセスが含まれています。この機能は、初期展開およびクラスタ拡張中のディスク要求プロセスに一貫性を提供します。

    容量レポート機能の強化。vSAN ESA 容量レポートのオーバーヘッドの内訳には、ESA オブジェクトのオーバーヘッドと元のファイル システムのオーバーヘッドの両方が表示されます。

    vSAN ESA での自動ポリシー管理の強化。拡張自動ポリシー管理機能は、ユーザーがクラスタでホストを追加または削除するときに、デフォルトのストレージ ポリシーを調整する必要があるかどうかを決定します。vSAN がデフォルトのストレージ ポリシーを変更する必要があると判断すると、健全性チェックの警告をトリガします。変更は、クリックするだけで簡単に行うことができます。この時点で vSAN は、新しいポリシーを使用してクラスタを再構成します。

    Skyline Health 修正の機能強化。vSAN Skyline Health は、展開固有のガイダンスと、問題を解決する方法に関する規範的なガイダンスを提供することで、解決時間を短縮することができます。

    保存データの暗号化を使用するクラスタのキーの有効期限。vSAN 8.0 Update 2 では、キー暗号化キー (KEK) に有効期限を割り当てるために使用されるキー有効期限属性を持つ KMS サーバの使用がサポートされています。

    I/O 上位コントリビュータの機能強化。vSAN パフォーマンス サービスでは、カスタマイズ可能な期間にパフォーマンス ホット スポットを検出するプロセスが改善され、複数のタイプのソース（仮想マシン、ホスト ディスクなど）を使用しながらパフォーマンスの問題を診断することができます。

    I/O トリップ アナライザは、2 ノード クラスタとストレッチ クラスタでサポートされます。vSAN 8.0 Update 2 では、I/O トリップ アナライザが強化され、vSAN ストレッチ クラスタ内のワークロードに関するレポートが作成されるようになりました。これで、vSAN ストレッチ クラスタで遅延の主な原因が発生している場所と、仮想マシンで発生する全体的な遅延に寄与するスタックの他の部分の遅延を判断できるようになりました。

    2 ノード クラスタとストレッチ クラスタの構成が容易化。2 ノード クラスタとストレッチ クラスタの展開の管理に役立ついくつかの新機能は次のとおりです。

    • vSphere Client で構成された監視ホスト トラフィック。

    • vSAN ESA での中規模の監視ホスト アプライアンスのサポート。

    • 共有監視ホスト アプライアンス タイプのライフサイクルを管理するための vLCM のサポート。

  • クラウド ネイティブ ストレージ

    TKG サービスの CSI スナップショットのサポート。クラウド ネイティブ ストレージでは、TKG サービスに対する CSI スナップショットのサポートが導入され、K8s ユーザーとバックアップ ベンダーは TKGS でパーシステント ボリューム スナップショットを作成できます。

    データストア間のクラウド ネイティブ パーシステント ボリュームのデータ モビリティ。このリリースでは、vSphere Client 内のデータストア間でのパーシステント ボリュームの組み込みの移行が導入されています。

VMware vSAN コミュニティ

「vSAN コミュニティ Web サイト」を使用して、vSAN の使用中に見つかった問題に対してフィードバックを提供し、サポートを依頼します。

このリリースのアップグレード

vSAN のアップグレードの詳細については、「VMware vSAN 8.0 Update 2 のドキュメント」を参照してください。 

注：アップグレードを実行する前に、「VMware 互換性ガイド」の最新バージョンを確認して、ご使用のプラットフォームで最新の vSAN バージョンが利用可能であることを確認してください。

注：vSAN Express Storage Architecture は、新しい展開でのみ使用できます。クラスタを vSAN ESA にアップグレードすることはできません。

vSAN 8.0 Update 2 は、vSphere 8.0 Update 2 への完全アップグレードを必要とする新しいリリースです。アップグレードを完了するには、次のタスクを実行します。

  1. vCenter Server 8.0 Update 2 にアップグレードします。詳細については、「VMware vSphere 8.0 Update 2 リリース ノート」を参照してください。 

  2. ホストを ESXi 8.0 Update 2 にアップグレードします。詳細については、「VMware vSphere 8.0 Update 2 リリース ノート」を参照してください。 

  3. vSAN のオンディスク フォーマットをバージョン 19.0 にアップグレードします。オンディスク フォーマット バージョン 3.0 以降からアップグレードする場合、データの退避は必要ありません（メタデータの更新のみ）。

  4. FSVM をアップグレードして、新しいファイル サービス機能を有効にし、最新の更新をすべて取得します。

注：vSAN 7.0 Update 1 で、バージョン 1.0 のディスク フォーマットが廃止されました。バージョン 1.0 のディスク フォーマットを実行しているディスクは vSAN によって認識されません。vSphere Update Manager、ISO のインストールまたは esxcli による vSAN 7.0 Update 1 へのアップグレードはブロックされます。この問題を回避するには、ディスク フォーマット バージョン 1.0 を実行しているディスクを新しいバージョンにアップグレードします。バージョン 1.0 のディスクを使用している場合、健全性チェックでアラートが表示され、ディスク フォーマットのバージョンをアップグレードするように警告されます。

ディスク フォーマット バージョン 1.0 では、パフォーマンスとスナップショットの機能が強化されていません。チェックサム、デデュープと圧縮、暗号化など、高度な機能はサポートされていません。vSAN ディスク フォーマットのバージョンの詳細については、KB2148493を参照してください。

容量の少ないホストのオンディスク フォーマットのアップグレード

vSAN オンディスク フォーマットをバージョン 1.0 または 2.0 からアップグレードしている間に、ディスク グループの退避が実行されます。ディスク グループが削除されて、オンディスク フォーマット バージョン 17.0 にアップグレードされてから、ディスク グループが再びクラスタに追加されます。2 ノードまたは 3 ノード クラスタの場合、または各ディスク グループを退避させるための十分なキャパシティのないクラスタの場合は、vSphere Client から [冗長性の低下を許可] を選択します。次の RVC コマンドを使用して、オンディスク フォーマットをアップグレードすることもできます： vsan.ondisk_upgrade --allow-reduced-redundancy

冗長性の低下を許可する場合、この方法ではデータがクラスタ内の他のホストに退避されないため、アップグレードの間、仮想マシンが保護されません。この方法では、各ディスク グループが削除されて、オンディスク フォーマットがアップグレードされ、ディスク グループが再びクラスタに追加されます。すべてのオブジェクトを引き続き使用できますが、冗長性は低下します。

アップグレード中にデデュープと圧縮を有効にすると、vSphere Client から [冗長性の低下を許可] を選択できます。

制限

vSAN 8.0 Update 2 リリースにおける構成の上限については、「構成の上限」ドキュメントを参照してください。

既知の問題

  • vSAN ESA クラスタ で vRDM の vmdk を統合できなかった

    この問題は、互換モードが仮想に設定され、ディスク モードが依存に設定されている vRDM タイプの仮想ディスクを使用している場合に発生する可能性があります。vSAN ESA データストアでは、スナップショットの作成後、対応する仮想ディスクをスナップショットの削除操作に統合できません。この問題により、仮想ディスクが新しいスナップショットの作成に失敗する可能性があります。

    なし。

  • ネイティブ キー プロバイダがバックアップされていない場合、暗号化操作がブロックされる

    vSAN 保存データの暗号化にネイティブ キー プロバイダを使用していて、ネイティブ キー プロバイダがバックアップされていない場合、暗号化関連の再構成操作が失敗し、次のメッセージが表示されることがあります。The KMS cluster {kmsCluster} is a Native Key Provider that is not backed up yet.

    保存データの暗号化を有効にする前に、ネイティブ キー プロバイダをバックアップします。

  • リストアされた仮想マシンにストレージ ポリシーを手動で割り当てる必要がある

    削除された仮想マシンからリンク クローンをリストアまたは作成した場合、vSAN は自動的にストレージ ポリシーを割り当てません。新しい仮想マシンにはストレージ ポリシーがありません。

    リンク クローン仮想マシンの作成または仮想マシンのリストア後に、ストレージ ポリシーを手動で割り当てます。

  • vCenter Server がエアギャップ状態の場合、Skyline Health の日本語テキストが正しく表示されない

    この問題は、vCenter Server ネットワーク接続がエアギャップ状態の場合に発生する可能性があります。Skyline Health の一部の日本語テキストが正しくローカライズされません。次のようなメッセージ ID が表示されます。 com.vmware.vsan.health.XXX

    次の手順を実行します。

    1. vCenter Server に SSH 接続します。

    2. 次のファイルを開きます。/etc/vmware-vsan-health/cloudHealthResources/locale/ja/vsanhealthremediation.vmsg

    3. 次の行を検索します。vsan.health.optimaldsdefaultpolicy.htf.0.default.0.des

    4. 次のように 2 行を 1 行にマージし、ファイルを保存します。

    5. vSAN Health Service を再起動します。 /usr/sbin/vmon-cli -r vsan-health

    変更前：

    vsan.health.optimaldsdefaultpolicy.htf.0.default.0.des=健全性テーブルに表示される

    vSAN の最適なデータストアのデフォルト ポリシーの「許容される障害の数」または「サイトの耐障害性」の構成 (あるいは両方) が推奨ポリシーと一致しません。

    変更後：

    vsan.health.optimaldsdefaultpolicy.htf.0.default.0.des=健全性テーブルに表示される vSAN の最適なデータストアのデフォルト ポリシーの「許容される障害の数」または「サイトの耐障害性」の構成 (あるいは両方) が推奨ポリシーと一致しません。

  • アップグレード中に hostAffinity ポリシー オプションが失われる

    vSAN 6.7 から vSAN 8.0 にアップグレードすると、vCenter Server hostaffinity オプションの値が false に変更されます。

    回避策：通常の仮想マシンで vSAN HostLocal ポリシーを引き続き使用するには、hostaffinity オプションを true に戻します。

  • vCenter Server のインターネット接続が無効になっているとファイル サービスを有効にできない

    vCenter Server のインターネット接続を無効にすると、[ファイル サービスを有効にする] ダイアログに [ファイル サービス エージェント] セクションが表示されず、OVF を選択できません。

    回避策：vCenter Server のインターネット接続を有効にするには、次の手順を実行します。

    1. [クラスタ] > [構成] > [vSAN] > [インターネット接続] に移動します。

    2. [編集] をクリックして、[インターネット接続の編集] ダイアログを開きます。

    3. [すべての vSAN クラスタのインターネット アクセスを有効にします] チェックボックスをオンにして、[適用] をクリックします。

  • vSAN ESA の暗号化を無効にできない

    vSAN ESA クラスタで保存データの暗号化を有効にした後、無効にすることはできません。

    回避策：なし。

  • vSAN ファイル サービスは NFSv4 委任をサポートしない

    このリリースでは、vSAN ファイル サービスは NFSv4 委任をサポートしていません。

    回避策：なし。

  • ストレッチ クラスタで、アフィニティのないファイル サーバがリバランスできない

    ストレッチ クラスタの vSAN ファイル サービス環境で、アフィニティの場所が構成されていないファイル サーバを優先 ESXi ホストと非優先 ESXi ホスト間でリバランスできません。

    回避策：ファイル サービスのドメイン構成を編集して、ファイル サーバのアフィニティの場所を優先または非優先に設定します。

  • vCenter Server サービスがカスタム ポートにデプロイされている場合、vSAN を使用した vSphere Lifecycle Manager クラスタ内の ESXi ホストの修正に失敗する

    vCenter Server サービスが、vSAN、vSphere DRS、および vSphere HA を含むクラスタ内のカスタム ポートにデプロイされている場合、vSphere Lifecycle Manager クラスタの修正に失敗することがあります。この問題は、vSAN リソース健全性チェック エラーが原因で発生します。ESXi ホストをメンテナンス モードに切り替えることができないため、修正タスクが失敗します。

    回避策：なし。

  • vSAN ファイル サービスを有効にすると、アップグレード、暗号化の有効化、データ効率などの DFC 関連の操作が失敗することがある

    ファイル サービスを有効にすると、エージェント仮想マシンが各ホストで実行されます。基盤となる vSAN オブジェクトは、複数のディスクグループにまたがって配置される場合があります。最初のディスクグループが変換されると、vSAN オブジェクトにアクセスできなくなり、エージェント仮想マシンが無効な状態になります。仮想マシンを削除して新しい仮想マシンを再デプロイしようとすると、仮想マシンの無効な状態が原因で操作が失敗します。仮想マシンは登録解除されますが、アクセスできないオブジェクトはまだ存在します。次のディスクグループが変換されると、クラスタ全体でアクセスできないオブジェクトの事前チェックが行われます。このチェックでは、古いエージェント仮想マシンのアクセスできないオブジェクトを検出するため、DFC に失敗します。

    回避策：アクセスできないオブジェクトを手動で削除します。 

    このような障害が発生すると、DFC タスクの失敗が表示されます。

    1. 障害タスクの障害情報から、アクセスできないオブジェクトを特定します。

    2. オブジェクトがエージェント仮想マシンに属していることを確認するには、hostd ログ ファイルを調べて、オブジェクトが仮想マシンのオブジェクト レイアウトに属していることを確認します。

    3. ホストにログインし、/usr/lib/vmware/osfs/bin/objtool コマンドを使用してオブジェクトを手動で削除します。

    注：この問題を防ぐには、DFC 関連の操作を実行する前にファイル サービスを無効にします。

  • vSAN HCI メッシュ コンピューティング専用ホストでホスト プロファイルを抽出できない

    vSAN ホスト プロファイル プラグインは、vSAN HCI メッシュ コンピューティング専用ホストをサポートしていません。HCI メッシュ コンピューティング専用ホストでホスト プロファイルを抽出しようとすると、失敗します。 

    回避策：なし。

  • ファイル共有内のファイルの削除が、vSAN 容量ビューに反映されないことがある

    すべてのファイルが削除された後、割り当てられたブロックがすぐに vSAN ストレージに戻されないことがあります。このため、vSAN 容量ビューに再利用されたストレージ容量が更新されるまでには時間がかかります。新しいデータが同じファイル共有に書き込まれると、削除されたブロックが vSAN ストレージに戻される前に再利用されることがあります。

    マッピング解除が有効で、vSAN 重複排除が無効になっている場合は、VDFS で 4MB の整列領域が解放されないと、容量は vSAN に戻されません。マッピング解除が有効で、vSAN 重複排除が有効になっている場合は、VDFS によって解放された容量が vSAN に戻されますが、遅延が発生します。

    回避策：ストレージを解放して vSAN にすぐに戻すには、ファイル共有を削除します。 

  • 転送中データの暗号化を使用すると、ストレッチ クラスタで vCenter Server 仮想マシンがクラッシュする

    転送中データの暗号化が有効になっている vSAN に vCenter Server 仮想マシンが存在する場合、vSAN ストレッチ クラスタで vCenter Server 仮想マシンがクラッシュすることがあります。1 つのサイトですべてのホストが停止し、これらのホストを再びパワーオンすると、障害が発生したサイトが復旧した後で vCenter Server 仮想マシンがクラッシュすることがあります。

    回避策：この問題を解決するには、thumbPrintRepair.py スクリプトを使用します。

  • vSAN では 1 台の仮想マシンをローカル データストアとリモート データストアにプロビジョニングできる

    vSphere では、ユーザーが HCI メッシュ環境内のローカル データストアとリモート データストアに 1 台の仮想マシンをプロビジョニングすることを妨げません。たとえば、ローカル vSAN データストアに 1 つの VMDK をプロビジョニングし、リモート vSAN データストアに 1 つの VMDK をプロビジョニングできます。vSphere HA はこの構成をサポートしていないため、これはサポートされません。

    回避策：ローカル データストアとリモート データストアに 1 台の仮想マシンをプロビジョニングしないでください。

  • オブジェクトの再フォーマット タスクが進行していない

    アップグレード後にオブジェクトの再フォーマットが必要になると、健全性アラートがトリガされ、vSAN の再フォーマットが開始します。このタスクをバッチで実行します。この処理はクラスタ内で使用可能な一時的な容量に依存します。一時的な容量の上限を超えると、vSAN は一時的な容量が解放されるまで再フォーマットを続行しません。このフェーズでは、タスクが停止しているように見える場合があります。一時的な容量が使用可能になると、健全性アラートがクリアされ、タスクが続行します。

    回避策：なし。タスクは想定どおり動作しています。 

  • システム仮想マシンをパワーオフできない

    vSphere 7.0 Update 1 の vSphere Cluster Services (vCLS) のリリースでは、一連のシステム仮想マシンが vSAN クラスタ内に配置されることがあります。これらのシステム仮想マシンは、ユーザーがパワーオフすることはできません。この問題は、一部の vSAN ワークフローに影響を及ぼす可能性があります。詳しくは、https://kb.vmware.com/s/article/80877を参照してください。

    回避策：この問題の詳細については、ナレッジベースの記事https://kb.vmware.com/s/article/80483を参照してください。 

  • vSAN オンディスク フォーマットのバージョンが古いため、vSAN ファイル サービスを有効にできない

    バージョン 11.0（vSAN 7.0 のオンディスク フォーマットのバージョン）より前のバージョンの vSAN オンディスク フォーマットで vSAN ファイル サービスは有効にできません。

    回避策：ファイル サービスを有効にする前に、vSAN ディスク フォーマットのバージョンをアップグレードしてください。

  • ドライブを再挿入すると、ホットプラグ シナリオでホスト障害が発生する

    ホット ドライブの取り外し中に、NVMe ドライブが 1 分以内に抜かれて再挿入されると、VMware ネイティブ NVMe ホットプラグにより、ホスト障害が発生することがあります。この問題は、新規または既存のドライブを再挿入するときに、vSphere と vSAN で発生する可能性があります。

    回避策：ホット ドライブを取り外した後、1 分間待ってから、新しいドライブまたは既存のドライブを再挿入します。

  • クラスタ内の最後のホストをメンテナンス モードにしたり、ディスクまたはディスク グループを削除したりできない

    クラスタ内にホストが 1 台しかない場合に、そのホストがメンテナンス モードになると、新しいリソースを追加するためのガイダンスが表示されないで、全データの移行モードまたはアクセシビリティの確保モードで操作が失敗することがあります。この問題は、クラスタ内にディスクまたはディスク グループが 1 つしかない場合に、そのディスクまたはディスク グループを削除したときにも発生します。

    回避策：全データの移行モードまたはアクセシビリティの確保モードを選択した状態で、クラスタ内に最後に残ったホストをメンテナンス モードにする前に、同じ構成の別のホストをクラスタに追加します。クラスタ内に最後に残ったディスクまたはディスク グループを削除する前に、同じ構成および同じ容量の新しいディスクまたはディスク グループを追加します。

  • 1 つ以上のディスクまたはディスク グループがほぼいっぱいになっている場合は、容量不足のためにオブジェクト再構成ワークフローが失敗することがある

    重複排除されていないクラスタ内のディスクまたは重複排除クラスタ内のディスク グループが、構成可能な再同期一時停止の使用率のしきい値に達すると、vSAN の再同期が一時停止します。この動作の目的は、再同期 I/O でディスク使用率が 100% になるのを防ぐことです。ディスクがこのしきい値に達すると、vSAN は、EMM、修復、リバランス、ポリシー変更などの再構成ワークフローを停止します。

    回避策：クラスタ内の別の場所に使用可能な容量がある場合、クラスタをリバランスすると、その他のディスクの容量が解放されて、それ以降の再構成が成功します。

  • クラスタの容量に空きがない状態からリカバリした後、仮想マシンの HA 保護が失われることがある

    ディスク使用率が 100% に到達しているホストを含む vSAN クラスタでは、仮想マシンに保留中の質問があり、そのために HA 保護が失われることがあります。また、クラスタの容量が不足しているシナリオでリカバリすると、保留中の質問がある仮想マシンが HA で保護されなくなります。

    回避策：vSAN クラスタの容量が不足しているシナリオでリカバリした後、次のいずれかの操作を実行します。

    • HA を無効にしてから、再度有効にします。

    • HA を再構成します。

    • 仮想マシンをパワーオフしてから、パワーオンします。

  • 保留中の質問がある仮想マシンのパワーオフが失敗する

    仮想マシンに保留中の質問がある場合は、その質問に回答するまで仮想マシン関連の操作を実行できません。

    回避策：関連ボリューム上のディスク容量を解放してから、再試行 をクリックしてください。

  • クラスタ容量が 100% に到達すると、仮想マシンの IP アドレスが IPV6 に変更されるか、使用できなくなる

    1 つ以上のディスク グループの使用率が 100% に到達しており、vSAN クラスタの容量に空きがない場合は、仮想マシンに、ユーザー アクションが必要な保留中の質問が存在する可能性があります。質問に対する回答がなく、クラスタの容量に空きがない状態で放置されている場合は、仮想マシンの IP アドレスが IPv6 に変更されるか、使用できなくなります。これにより、SSH を使用して仮想マシンにアクセスできなくなります。また、root を入力した後にコンソールが空白になるため、仮想マシン コンソールを使用できなくなります。

    回避策：なし。

  • キャパシティ ディスクが PDL の状態になった後に、重複排除が有効なディスク グループを削除できない

    重複排除が有効なディスク グループ内のキャパシティ ディスクが削除された場合、その一意の ID が変更された場合、またはデバイスでリカバリ不能なハードウェア エラーが発生した場合は、Permanent Device Loss (PDL) 状態になります。ディスク グループを削除しようとすると、アクションを完了できないことを知らせるエラー メッセージが表示されることがあります。

    回避策：キャパシティ ディスクが削除された場合、その一意の ID が変更された場合、またはデバイスでリカバリ不能なハードウェア エラーが発生した場合は、数分待ってからディスク グループを削除してください。

  • 重複排除クラスタでディスク使用率が 80% を超えていると表示されている場合は、リアクティブ リバランスが実行されないことがある

    重複排除クラスタのダッシュボードに、ディスク使用率が 80% を超えていると表示されている場合は、リアクティブ リバランスが予測どおりに開始されないことがあります。これは、重複排除クラスタの空き容量の計算に、保留中の書き込みと削除も反映されるためです。

    回避策：なし。

  • ゲスト OS からの TRIM/UNMAP コマンドが失敗する

    オンライン スナップショットの統合中にゲスト OS が容量の再利用を実行すると、TRIM/UNMAP コマンドは失敗します。この障害により、容量が再利用されなくなります。

    回避策：オンライン スナップショットの操作が完了してから、容量の再利用を実行します。後続の TRIM/UNMAP 操作が失敗する場合は、ディスクを再マウントしてください。

  • オンライン スナップショット統合を実行すると、SCSI TRIM/UNMAP で得られた容量の再利用が失われる

    SCSI TRIM/UNMAP コマンドで得られた容量の再利用は、オンライン スナップショット統合を行うと、失われてしまいます。オフライン スナップショット統合は、SCSI UNMAP 操作に影響しません。

    回避策：オンライン スナップショット統合が完了してから、容量の再利用を実行します。

  • データ ホストを監視ホストに変換するときに、ホストに障害が発生する

    vSAN クラスタをストレッチ クラスタに変換する場合は、監視ホストを指定する必要があります。データ ホストは監視ホストに変換できますが、処理中にメンテナンス モードを使用して全データの移行を行う必要があります。アクセシビリティの確保 オプションを使用してこのホストをメンテナンス モードにしてから、監視ホストとして設定すると、ホストに障害が発生してパープル スクリーンが表示されることがあります。

    回避策：監視ホストのディスク グループを削除してから、ディスク グループを再作成します。

  • データストアの移行中に常駐ホストに障害が発生すると、vCenter Server で同じ名前の仮想マシンが複製される

    Storage vMotion で、vSAN から別のデータストア（NFS など）に仮想マシンを移行しているときに、仮想マシンが属するホストで vSAN ネットワークの障害が発生して仮想マシンの HA フェイルオーバーが実行されると、仮想マシンが vCenter Server で複製されることがあります。 

    回避策：無効な仮想マシンをパワーオフして、vCenter Server から登録解除します。 

  • 新しい vCenter Server で既存のストレッチ クラスタを再構成すると、vSAN が健全性チェックの警告を表示する

    新しい vCenter Server で既存のストレッチ クラスタを再構築すると、vSAN クラスタの健全性チェックが赤になります。「vSphere クラスタ メンバーと vSAN クラスタ メンバーが一致」というメッセージが表示されます。

    回避策：次の手順を使用してストレッチ クラスタを構成します。

    1. SSH を使用して、監視ホストにログインします。

    2. 監視ホスト上のディスクを廃止します。次のコマンドを実行します： esxcli vsan storage remove -s "SSD UUID"

    3. 監視ホストをクラスタから強制的に離脱させます。次のコマンドを実行します： esxcli vsan cluster leave

    4. 新しい vCenter Server から [構成] > [vSAN] > [ストレッチ クラスタおよびフォルト ドメイン] の順に進んでストレッチ クラスタを再構成します。

  • vSAN がサイズの大きいオブジェクトを再同期しているときに、ディスク フォーマットのアップグレードが失敗する

    vSAN クラスタにサイズの非常に大きなオブジェクトが含まれている場合、オブジェクトの再同期中にディスク フォーマットのアップグレードに失敗することがあります。次のエラー メッセージが表示されることがあります：vSAN のオブジェクトの変換に失敗しました。

    オブジェクトが再同期されるまで、vSAN はアップグレードを実行できません。プロセスが完了する時間を確認するには、[監視] > [vSAN] > [コンポーネントの再同期] の順に選択して、再同期のステータスを確認します。

    回避策：保留中の再同期がなくなるまで待機してから、ディスク フォーマットのアップグレードを再試行します。

  • パワーオフされた仮想マシンが、監視ホストの交換中にアクセスできないとして表示される

    ストレッチ クラスタの監視ホストを変更するときに、パワーオフされた仮想マシンがアクセス不能として vSphere Web Client に短時間表示されます。プロセスが完了すると、パワーオフされた仮想マシンがアクセス可能と表示されます。すべての実行中の仮想マシンはプロセスを通じてアクセス可能として表示されます。

    回避策：なし。

  • 障害のあるブート メディアがホストにあるとメンテナンス モードにすることができない

    vSAN がブート メディアに障害のあるホストをメンテナンス モードにすることができません。設定の変更を保存することができないため、メンテナンス モードに移行するタスクは内部 vSAN エラーで失敗することがあります。次のようなログ イベントが表示されます：Lost Connectivity to the device xxx backing the boot filesystem

    回避策：データの完全退避オプションを使用して、各ホストからディスク グループを手動で削除します。それからホストをメンテナンス モードにします。

  • ストレッチ クラスタのフェイルオーバーの後、優先サイト上の仮想マシンが次のアラートを登録する：フェイルオーバーに失敗しました

    ストレッチ クラスタのセカンダリ サイトが失敗すると、仮想マシンは優先サイトにフェイルオーバーします。すでに優先サイトにある仮想マシンは次のアラートを登録する場合があります：フェイルオーバーに失敗しました。

    回避策：このアラートは無視してかまいません。これはフェイルオーバーの動作には影響しません。

  • ネットワークのパーティショニング中に、アクティブなサイトのコンポーネントに一時的な障害が発生したと表示される

    vSAN 2 ホストまたはストレッチ クラスタでのネットワークのパーティショニング中に、vSphere Web Client は、非アクティブ サイトの観点からクラスタのビューを表示することがあります。プライマリ サイトのアクティブ コンポーネントに一時的な障害が発生したと表示されることがあります。

    回避策：RVC コマンドを使用して、クラスタ内のオブジェクトの状態をクエリします。例： vsan.vm_object_info

  • 強制的な修復後、一部のオブジェクトが非準拠になる

    強制的な修復後、一部のオブジェクトが修復されないままになることがあります。これは、オブジェクトの所有権が処理中に別のノードに転送されたためです。これらのオブジェクトに対する強制的な修復は遅延することがあります。

    回避策：他のすべてのオブジェクトが修復され再同期された後で、強制的な修復を実行します。vSAN がオブジェクトを修復するまで待機することができます。

  • ある暗号化クラスタから別の暗号化クラスタに移動したホストを元のクラスタに戻すと、タスクが失敗する

    ある暗号化 vSAN クラスタから別の暗号化 vSAN クラスタにホストを移動し、そのホストを元の暗号化クラスタに戻すと、タスクが失敗する場合があります。次のメッセージが表示される場合があります：A general system error occurred: Invalid fault.このエラーは、vSAN が元の暗号化キーを使用してホスト上のデータを再暗号化できないことが原因で発生します。しばらくすると、vCenter Server がホスト上で元のキーをリストアし、vSAN クラスタ内のマウント解除されていたディスクがすべてマウントされます。

    回避策：ホストを再起動し、すべてのディスクがマウントされるまで待ちます。

  • ディスク グループがアンマウントされている場合、深い再キー化を実行することができない

    vSAN は、深い再キー化を実行する前に浅い再キー化を実行します。アンマウントされたディスク グループがある場合、浅い再キー化は失敗します。そのため、深い再キー化を開始することができません。

    回避策：アンマウントされたディスク グループを再マウントするか削除します。

  • ログ エントリにファイアウォール構成が変更されたことが示されている

    vSAN 暗号化を有効にすると、新しいファイアウォール エントリ vsanEncryption がセキュリティ プロファイルに表示されます。このルールは、ホストが KMS とどのように直接通信するかを制御します。ルールが適用されると、ログ エントリが /var/log/vobd.log に追加されます。次のメッセージが表示される場合があります：

    Firewall configuration has changed. Operation 'addIP4' for rule set vsanEncryption succeeded.

    Firewall configuration has changed. Operation 'removeIP4' for rule set vsanEncryption succeeded.

    これらのメッセージは無視することができます。

    回避策：なし。

  • vmknic 上で監視トラフィックをサポートするトラフィック タイプ オプションを設定した後、HA フェイルオーバーが発生しない

    vmknic 上で監視トラフィックをサポートするトラフィック タイプ オプションを設定すると、vSphere HA は自動的に新しい設定を検出しません。HA を一度手動で無効にしてから再度有効にして vmknic を検出できるようにする必要があります。vmknic および vSAN クラスタを最初に構成し、次にクラスタ上で HA を有効にすれば、vmknic が検出されます。

    回避策：クラスタ上で vSphere HA を手動で無効にしてから再度有効にします。

  • ネットワーク パーティションの解決後、リンク クローン仮想マシンでの一部の仮想マシン操作が失敗することがある

    ゲスト OS 内に I/O が発生していないリンク クローン仮想マシン上での一部の仮想マシン操作が失敗することがあります。失敗する可能性がある操作には、スナップショットの作成や仮想マシンのサスペンドが含まれます。この問題は、ネットワーク パーティションが解決された後、親ベース仮想マシンのネームスペースにまだアクセスできない場合に発生する可能性があります。親仮想マシンのネームスペースがアクセス可能になった場合、HA には仮想マシンをパワーオンするように通知されません。

    回避策：I/O 操作がアクティブに実行されていない仮想マシンの電源を入れ直します。

  • 監視ホストをメンテナンス モードに切り替えることができない

    監視ホストをメンテナンス モードに切り替えようとしても、ホストの状態は変わらず、次の通知が表示されます。指定されたパラメータが正しくありませんでした。

    回避策：監視ホストをメンテナンス モードに切り替える場合、[データの移行なし] オプションを選択します。

  • 監視ホストを拡張クラスタ内に移動し、その監視ホストを拡張クラスタの外に移動すると、クラスタの構成が誤った状態のままになる

    vSAN 対応の vCenter Server クラスタに監視ホストを配置すると、監視ホストをクラスタに配置できないことがアラームで通知されます。ただし、監視ホストをクラスタから移動しても、クラスタの構成が誤った状態のままになります。

    回避策：監視ホストを vSAN ストレッチ クラスタから移動し、ストレッチ クラスタを再構成します。詳細については、https://kb.vmware.com/s/article/2130587を参照してください。

  • アンマウントされた vSAN ディスクおよびディスク グループが、vSphere Web Client の [動作ステータス] フィールドで [マウント済み] として表示される

    ディスクの待ち時間が継続的に長くなっている場合に、esxcli vsan storage disk group unmount コマンドまたは vSAN のデバイス監視サービスを実行して vSAN ディスクまたはディスク グループをアンマウントすると、vSphere Web Client の [動作ステータス] フィールドに [マウント済み] として誤って表示されます。

    回避策：[動作ステータス] フィールドの代わりに、[健全性] フィールドを使用してディスク ステータスを確認します。

check-circle-line exclamation-circle-line close-line
Scroll to top icon