VMware vSphere 8.0 | 2022 年 10 月 11 日

VMware ESXi 8.0 | 2022 年 10 月 11 日 | ビルド ISO ビルド 20513097

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

リリース ノートの概要

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

新機能

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

  • トレードオフのないパフォーマンス

    vSAN Express Storage Architecture。vSAN ESA は、より予測可能な I/O 遅延と最適化された容量効率によってパフォーマンスを大幅に向上させる可能性を提供する代替アーキテクチャです。

    書き込みバッファの増加。vSAN Original Storage Architecture は、より集中的なワークロードをサポートできます。vSAN ホストを構成して、書き込みバッファを 600 GB から 1.6 TB に増やすことができます。

    パフォーマンスへの影響を最小限に抑えたネイティブ スナップショット。vSAN ESA ファイル システムにはスナップショットが組み込まれています。これらのネイティブ スナップショットは、スナップショット チェーンが深くなった場合でも、仮想マシンのパフォーマンスへの影響を最小限に抑えます。スナップショットは、VMware VADP を使用する既存のバックアップ アプリケーションと完全な互換性があります。

  • 最高のリソースと容量効率

    • パフォーマンスを損なうことのないイレージャ コーディング。イレージャ コーディングを備えた vSAN ESA RAID5/RAID6 機能は、非常に効率的なイレージャ コーディング コード パスを提供するため、高パフォーマンスと容量効率に優れたストレージ ポリシーの両方を実現できます。

    • 圧縮の向上。vSAN ESA には最大 4 倍の圧縮率を実現する高度な圧縮機能があります。データが vSAN ネットワークを介して送信される前に圧縮が実行されるため、バンド幅の使用率が向上します。

    • 使用可能なストレージの可能性の拡張。vSAN ESA は、すべてのデバイスが容量に影響する単一層アーキテクチャで構成されます。このフラット ストレージ プールにより、キャッシュ デバイスを備えたディスク グループが不要になります。

    • 高い仮想マシンの統合率によるパフォーマンス オーバーヘッドの低減。リソースと容量効率が向上すると、クラスタあたりの仮想マシン データをより多く保存できるようになり、仮想マシンの統合率が向上する可能性があります。

    • 10 個のクライアント クラスタでの HCI メッシュのサポート。ストレージ サーバ クラスタは、最大 10 個のクライアント クラスタと共有できます。

  • vSAN ESA ネイティブ スナップショットによる高速で効率的なデータ保護

    • パフォーマンスへの影響を無視できる。スナップショット チェーンが長くスナップショットが深いため、パフォーマンスへの影響を最小限に抑えます。

    • 高速スナップショット操作。スナップショット作成またはスナップショット削除の際の停止時間の影響を受けていたアプリケーションは、vSAN ESA によってパフォーマンスが向上します。

    • VMware VADP を使用した一貫性のあるパートナー バックアップ アプリケーション エクスペリエンス。VMware スナップショット API は変更されていません。VMware VADP は、vSphere プラットフォームでのすべての vSAN ESA ネイティブ スナップショット操作をサポートします。

  • 可用性と保守性

    • デバイスごとのサービスの簡素化と高速化。vSAN ESA はディスク グループの複雑さを排除し、障害が発生したドライブの交換プロセスを効率化します。

    • 障害ドメインの縮小とデータ再同期の低減。vSAN ESA のストレージ プール設計には単一障害点がありません。vSAN データとメタデータは、許容される障害 (FTT) の SPBM 設定に従って保護されます。ディスクがクラッシュした場合、キャッシュも圧縮も単一のディスク障害ドメイン以上にはなりません。vSAN ESA を使用すると、再同期操作が迅速に完了します。

    • データ可用性の強化と SLA の向上。ディスク障害ドメインの削減と修復時間の短縮は、ユーザーまたはビジネス ユニットに提供される SLA を向上できることを意味します。

    • vSAN 起動時間の最適化。vSAN 起動ロジックは、より高速な起動のためにさらに最適化されました。

    • シャットダウンと起動のワークフローの強化。vSAN クラスタのシャットダウンおよびクラスタの起動プロセスが強化され、vCenter Server、または Active Directory、DNS、DHCP などのインフラストラクチャ サービスを収容する vSAN クラスタがサポートされるようになりました。

    • vSAN ファイル サービスのフェイルオーバー時間の短縮。vSAN ファイル サービスの計画フェイルオーバーが効率化されました。

  • 直感的で俊敏な運用

    • すべての vSAN プラットフォームで一貫性のあるインターフェイス。vSAN ESA は vSAN OSA と同じ画面とワークフローを使用するため、習得に時間がかかりません。

    • 仮想マシンごとのポリシーによる柔軟性の向上。vSAN ESA はクラスタ全体の設定を SPBM レベルに移行しています。このリリースでは、SPBM 圧縮設定により、仮想マシン レベルまたは VMDK レベルまできめ細かく制御でき、データストアのデフォルト ポリシーを使用して広範囲に適用できます。

    • 互換性とコンプライアンスに関するプロアクティブ インサイト。このメカニズムは、VMware Analytics Cloud に接続された vSAN クラスタがソフトウェアおよびハードウェアの異常を特定するのに役立ちます。OEM パートナーが vSAN HCL にリストされているドライブまたは I/O コントローラの問題に関するアドバイザリを公開している場合、影響を受ける可能性のある環境について通知を受けることができます。

  • 追加機能と機能拡張

    • 拡張されたネットワーク アップリンク遅延メトリック。vSAN は、遅延が一時的なものであれ、過剰なワークロードからのものであれ、環境に合わせたより意味のある関連メトリックを定義します。

    • RDT レベルのチェックサム。RDT レイヤーでチェックサムを設定できます。これらの新しいチェックサムは、デバッグとトリアージに役立ちます。

    • vSAN ファイル サービスのデバッグ。ファイル サービスの Day 0 の操作が向上され、検証とトラブルシューティングが効率化されました。

    • IPv6 経由の vSAN ファイル サービス。IPv6 ネットワークを使用してファイル サービス ドメインを作成できます。

    • vSAN ファイル サービス ネットワークの再構成。プライマリ IP アドレスを含むファイル サーバの IP アドレスを、同じサブネットまたは異なるサブネット内の新しい IP アドレスに変更できます。

    • vSphere Client リモート プラグイン。VMware が所有するすべてのローカル プラグインは、新しいリモート プラグイン アーキテクチャに移行しています。vSAN ローカル プラグインが vSphere Client リモート プラグインに移動されました。ローカル vSAN プラグインは、このリリースで廃止されました。

    • vLCM HCL ディスク デバイス。機能強化により、目的のイメージとの互換性を確認するための vLCM の機能と効率が向上します。これには、「partNumber」と「vendor」のチェックが含まれ、より多くのベンダーがカバーされます。

    • vSAN Health Service の開始時間の短縮。vCenter Server の再起動またはアップグレードの一環として vSAN Health Service を停止するのに必要な時間が 5 秒に短縮されました。

    • vSAN 健全性チェックにより、VCF LCM に予測を提供。このリリースでは、VCF での LCM の耐障害性を向上させるために、関連する vSAN 健全性チェックのみが VCF に提供されます。

    • vSAN による、VMC のクラスタ NDU の向上。新しい機能により、安全性と信頼性に優れ、運用効率の高いサービスの設計と運用が可能になります。

    • vSAN 暗号化キーの検証。KMS サーバから送信された無効なキーまたは破損したキーを検出し、インメモリとオンディスクの DEK の不一致を識別し、不一致があればユーザーに警告します。

    • 大規模コンポーネントの削除処理の向上。NO_SPACE エラーを引き起こすことなく、論理容量を再利用し、物理容量をより迅速に処理します。

    • vSAN 健全性「チェック」という名前を「検出」に変更しました。この変更により、すべての VMware 製品間で用語が統一されるようになりました。

    • 別のサンドボックス ドメインへの vSAN の配置。デーモン サンドボックスは、ラテラル ムーブメントを防止し、多層防御を提供します。vSAN 8.0 以降では、最小権限セキュリティ モデルが実装されています。カスタム サンドボックス ドメインが定義されていないデーモンは、権限のないドメインとして実行されます。これにより、ESXi ホストで最小権限モデルが実現されます。すべての vSAN は、最小権限を持つ独自のサンドボックス ドメインで実行されます。

    • vSAN プロアクティブ インサイト。このメカニズムにより、VMware Analytics Cloud に接続された vSAN クラスタは、ソフトウェアおよびハードウェアの異常をプロアクティブに特定できます。

    • SAP HANA の PMEM の管理と監視。ホスト内の PMEM デバイスを管理できます。vSAN は、PMEM デバイスの健全性チェック、パフォーマンス監視、容量レポートなどの管理機能を提供します。PMEM 管理機能では、vSAN サービスを有効にする必要はありません。vSAN は、vSAN メタデータのキャッシュや、暗号化、チェックサム、重複排除、圧縮などの vSAN データ サービスに PMEM デバイスを使用しません。PMEM データストアは各ホストに対してローカルですが、クラスタ レベルで [監視] タブから管理できます。

    • vSAN での MD5、SHA1、SHA2 の置き換え。SHA1 は安全であると見なされなくなったため、VMware は vSAN を含むすべての VMware 製品で SHA1、MD5、および SHA2 を SHA256 に置き換えています。

    • IL6 準拠。vSAN 8.0 は IL6 に準拠しています。

VMware vSAN コミュニティ

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

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

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

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

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

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

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

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

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

  4. FSVM をアップグレードして、SMB 共有のアクセス権に基づく列挙などの新しいファイル サービス機能を有効にします。

注：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

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

vSAN 8.0 へのアップグレード中に重複排除および圧縮を有効にすると、vSphere Client から [冗長性の低下を許可] を選択できます。

制限

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

解決した問題

  • vSAN の健全性で、プロキシが構成された VUM が見つからない

    プロキシが vSAN 用に構成されている場合、vsan-health service で、VMware Update Manager (VUM) が無効になっているか、インストールされていないと誤って報告されていました。

    今回のリリースで、この問題は修正されました。

  • RemoveFileShare タスクが失敗すると vSAN ファイル サービス サーバでフェイルオーバーが発生することがある

    共有が削除されていても、NFS 共有の RemoveFileShare タスクが vCenter Server で失敗することがあります。これは、エクスポートの削除中に NFS サーバで障害が起きたために発生します。共有は正常に削除されるため、これにより、ワークフロー全体で問題が発生することはありません。

    NFS サーバで障害が発生すると、vSAN ファイル サービス サーバのフェイルオーバーがトリガされます。NFS サーバと SMB サーバは同時にフェイルオーバーするため、同じ vSAN ファイル サービス サーバからエクスポートされた SMB 共有があると、SMB マウントが中断します。サーバのフェイルオーバーによる SMB マウントの中断は、vSAN が SMB サーバの透過的なフェイルオーバーをサポートしていないため、既知の動作です。

    回避策：なし。

既知の問題

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

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

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

  • クラスタを vSAN Express Storage Architecture にアップグレードできない

    vSAN Original Storage Architecture 上のクラスタを vSAN Express Storage Architecture にアップグレードまたは変換することはできません。vSAN ESA は、新しい展開でのみサポートされます。

    回避策：なし。

  • vSAN ESA で暗号化の深い再キー化がサポートされていない

    このリリースでは、vSAN Express Storage Architecture は暗号化の深い再キー化をサポートしていません。

    回避策：なし。

  • vSAN ESA で vSAN ファイル サービスがサポートされていない

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

    回避策：なし。

  • vSAN ESA の暗号化設定を変更できない

    暗号化は、クラスタの作成時にのみ vSAN ESA で構成できます。後で設定を変更することはできません。

    回避策：なし。

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

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

    回避策：なし。

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

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

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

  • vSAN ストレッチ クラスタ パーティション中に、CNS ボリュームを持つ Kubernetes ポッドを作成、削除、または再スケジュールできない

    vSAN ストレッチ クラスタにサイト間のネットワーク パーティションがある場合、断続的なタイミングの問題により、ボリューム情報が CNS から失われる可能性があります。ボリューム メタデータが CNS に存在しない場合、CNS ボリュームを持つポッドを作成、削除、または再スケジュールすることはできません。vSphere CSI ドライバは、これらの操作を実行するために CNS からボリューム情報にアクセスする必要があります。

    ネットワーク パーティションが修正されると、CNS ボリューム メタデータが復元され、CNS ボリュームを持つポッドを作成、削除、または再スケジュールできます。

    回避策：なし。

  • クラスタのシャットダウン ウィザードで、HCI メッシュ コンピューティング専用クラスタのエラーが表示される

    vSAN クラスタのシャットダウン ウィザードは、vSAN データストアと vSAN サービスのある vSAN クラスタ用に設計されています。HCI メッシュ コンピューティング専用クラスタはサポートされていません。ウィザードを使用してコンピューティング専用クラスタをシャットダウンすると、次のエラー メッセージが表示されます。

    健全性サービス データを取得できません。

    回避策：なし。HCI メッシュ コンピューティング専用クラスタで、vSAN クラスタのシャットダウン ウィザードを使用しないでください。

  • 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 関連の操作を実行する前にファイル サービスを無効にします。

  • esxcli vsan cluster leave コマンドは、ESXi ホストで vSAN を無効にできない 

    次のコマンドを実行して、メンバー ホスト上の vSAN を無効にできないことがあります。 esxcli vsan cluster leave

    次のようなエラー メッセージが表示されることがあります。

    Failed to unmount default vSAN datastore.Unable to complete Sysinfo operation.Please see the VMKernel log file for more details.

    回避策：vSphere Client で次の手順を実行して、単一のメンバー ホストの vSAN を無効にします。

    1. ホストをメンテナンス モードにします。

    2. ホストを vSAN クラスタから親データセンターに移動します。

      移動中、ホストの vSAN サービスは自動的に無効になります。

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

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

    回避策：なし。

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

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

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

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

  • vSAN over RDMA で、ネットワークの輻輳が原因でパフォーマンスが低下する場合がある

    RDMA には、輻輳のないロスレス ネットワーク インフラストラクチャが必要です。ネットワークが輻輳している場合、特定の大規模な I/O ワークロードで TCP よりもパフォーマンスが低下する可能性があります。 

    回避策：RDMA の OEM ベスト プラクティスに従い、ネットワークの輻輳の問題を解決します。

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

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

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

  • VMFS データストアまたは vSAN データストアから vSAN データストアへの仮想マシンの移行が失敗する

    コンテンツ ベースの読み取りキャッシュ (CBRC) を有効にすると、sVmotion または xVmotion で 1 つ以上のスナップショットを持つ仮想マシンを vSAN データストアに移行できないことがあります。次のエラー メッセージが表示されることがあります：「このオブジェクトでは、この操作はサポートされていません。」

    次のメッセージが表示されます。 /var/log/vmware/vpxd

    /2021-01-31T17:12:27.477Z error vpxd[18588] [Originator@6876 sub=vpxLro opID=65ef3b53-01] [VpxLRO] Unexpected Exception: N5Vmomi5Fault12NotSupported9ExceptionE(Message is: The operation is not supported on the object.,

    --> Fault cause: vmodl.fault.NotSupported

    --> Fault Messages are:

    --> (null)

    --> )

    -->

    回避策：移行前にスナップショットを統合するか、すべてのスナップショットを削除します。

  • 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 ディスク フォーマットのバージョンをアップグレードしてください。

  • vSAN 健全性ネットワーク テストの問題が原因で、大規模なクラスタでクラスタの修正タスクが失敗することがある

    ホストが 16 台を超える大規模なクラスタでは、ホストのアップグレード中に ping が断続的に失敗する場合があります。この障害により、vSphere Life Cycle Manager でホストの修正が中断する場合があります。

    回避策：修正の事前チェックが成功すると、次の vSAN 健全性テストのアラートを無効にします。

    • vSAN：基本（ユニキャスト）接続チェック

    • vSAN：MTU チェック（パケット サイズの大きい ping）

    修正タスクが完了したら、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 が変更された場合、またはデバイスでリカバリ不能なハードウェア エラーが発生した場合は、数分待ってからディスク グループを削除してください。

  • vSAN の健全性が、非可用性に関連する不適合（保留中のポリシーが失敗）状態を示す

    ポリシー変更要求を行っても、vSAN のオブジェクト健全性ステータスが非可用性に関連する不適合状態のままになります。これは、要求されたリソースを利用しているスケジュール設定された作業が他にあるためです。ただし、リソースが使用可能になると、vSAN はこのポリシー要求を自動的に再スケジュール設定します。

    回避策：通常は、vSAN の定期スキャンを行うと、この問題が自動的に修正されます。ただし、ポリシー変更が受け入れられていて、適用されなかった場合も、進行中の他の作業で使用可能なリソースが使用されることがあります。容量レポートに高い値が表示される場合は、容量を追加できます。

  • 重複排除クラスタでディスク使用率が 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] > [コンポーネントの再同期] の順に選択して、再同期のステータスを確認します。

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

  • クラスタ上で vSAN を無効にした後で vSAN ストレッチ クラスタの構成が失われる

    ストレッチ クラスタ上で vSAN を無効にすると、ストレッチ クラスタの構成は保持されません。ストレッチ クラスタ、監視ホストおよびフォルト ドメインの構成は失われます。

    回避策：vSAN クラスタを再度有効にするときに、ストレッチ クラスタのパラメータを再構成してください。

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

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

    回避策：なし。

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

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

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

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

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

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

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

    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 は、不完全なコンポーネントの修復を開始するときに一部のホストを過度に使用する可能性があります。

    回避策：障害のあるサイトのすべてのホストを、短時間で一括して復元します。

  • ストレッチ クラスタでの HA の問題が原因で、仮想マシン操作が失敗する

    ストレッチ クラスタでの特定の障害シナリオで、vMotion や仮想マシンのパワーオンなどの特定の仮想マシン操作が影響を受ける場合があります。該当する障害シナリオには、サイトの一部または全体の障害や、サイト間の高速ネットワークの障害などがあります。この問題は、ストレッチ クラスタ サイトの通常操作に使用される VMware HA への依存性が原因です。

    回避策：vMotion、仮想マシンの作成、または仮想マシンのパワーオンを実行する前に、vSphere HA を無効にします。その後、vSphere HA を再び有効にします。

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

    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 を手動で無効にしてから再度有効にします。

  • iSCSI MCS がサポートされていない

    vSAN iSCSI ターゲット サービスでは、Multiple Connections per Session (MCS) がサポートされていません。

    回避策：なし。

  • すべての iSCSI イニシエータで iSCSI ターゲットが検出される

    vSAN iSCSI ターゲット サービスでは、ネットワーク上のすべてのイニシエータで iSCSI ターゲットが検出されます。

    回避策：ESXi ホストを個別の VLAN に配置することによって、それらのホストを iSCSI イニシエータから隔離します。

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

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

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

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

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

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

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

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

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

  • HA ハートビート データストアのあるクラスタ内でネットワークのパーティション分割が発生した場合に、他のデータ サイト上で仮想マシンが再起動されない

    vSAN クラスタ内の優先サイトまたはセカンダリ サイトで他のサイトへのネットワーク接続が失われた場合、ネットワーク接続を失ったサイト上で実行中の仮想マシンが他のデータ サイト上で再起動されず、次の内容のエラーが表示される場合があります：vSphere HA virtual machine HA failover failed。

    これは、vSAN クラスタにおいて想定されている動作です。

    回避策：クラスタで vSphere HA を構成中は、HA ハートビート データストアを選択しないでください。

  • アンマウントされた 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