マルチクラウド環境の管理

VMware vCenter Site Recovery Manager 5.0 | 2011 年 9 月 14 日 | ビルド 474459 最終更新日： 2016 年 3 月 9 日 これらのリリース ノートへの追加や更新を確認してください。

リリース ノートの概要

このリリース ノートには、次のトピックが含まれています。

• 新機能
• ローカライズ
• 互換性
• インストールとアップグレードに関する注記
• SRM SDK
• オープン ソースのコンポーネント
• 注意と制限
• 既知の問題

新機能

VMware vCenter Site Recovery Manager 5.0 は、仮想環境のための信頼できるディザスタ リカバリ プランを作成、管理、および実行する点で大きな助けになります。VMware は、バージョン 5.0 のリリースで Site Recovery Manager の機能を拡大し、これまでなかったような保護レベルを実現しました。次の機能が追加されたため、これまで以上に様々な使用例に対応できるようになりました。

• vSphere Replication。Site Recovery Manager 5.0 では、VMware vSphere 5.0 と組み合わせた場合に、vSphere 5.0 ホストを利用して、パワーオン状態の仮想マシンをネットワーク経由で他の vSphere 5.0 ホストに複製する機能が導入されました。これにより、ストレージ アレイベースのレプリケーションの要件が満たされていなくても、レプリケーションを実行することができます。仮想マシンの使用状況が変化した場合、変更されたブロックはリカバリ サイトに常駐する仮想マシンのシャドウ コピーに複製されます。この処理は、仮想マシン自体のプロパティとしての Recovery Point Objective セットと一致するように行われます。

• 計画移行。データ損失のリスクを最小にしながら移行を実行する、新しいワークフローがデザインされました。計画移行では、エラーが発生した場合にはワークフローを停止します。これによって問題を解決する機会が得られ、システムが適切に休止できるように、またすべてのデータ変更が完全に複製されるようにできます。

• 自動再保護。再保護は、アレイベースのレプリケーションでのみ使用される、リカバリ プランの新しい拡張機能です。自動再保護を使えば、リカバリ サイトの環境で環境のレプリケーションと保護を確立して、1 回のクリックで元の保護されたサイトに戻すことができます。

• 自動フェイルバック。自動フェイルバックは、環境全体を、元の保護されていたプライマリ サイトに戻します。この処理は、再保護によりデータのレプリケーションが確実に行われ、元のプライマリ サイトとの同期が取られた後にのみ実行されます。フェイルバックでは、環境を保護されたサイトに移行するのと同じワークフローが実行されます。これによって、リカバリ プランによってカプセル化された非常に重要なシステムが、元の環境に戻されます。自動フェイルバックは、再保護と同じように、アレイベースのレプリケーションで保護された仮想マシンでのみ使用できます。

• 改善された依存関係定義。これには、より多く（5 つ）の優先グループの追加と、優先グループ内で仮想マシンの依存関係を設定する機能が含まれています。仮想マシンの依存関係を定義すれば、依存側の仮想マシンがパワーオンになる前に、必要なシステムを確実に利用可能にすることができます。これにより、高度に組織されたワークフロー コントロールを実現し、依存している仮想マシンをパワーオンにする前に必要なサービスが確実に利用できます。

ローカライズ

VMware vCenter Site Recovery Manager 5.0 は次の言語で利用できます。

• 英語
• フランス語
• ドイツ語
• 日本語
• 簡体字中国語

互換性

SRM の互換性マトリックス

現在の相互運用性および製品互換性マトリックスについては、 VMware vCenter Site Recovery Manager の互換性マトリックスを参照してください。

互換性のあるストレージ アレイおよびストレージ レプリケーション アダプタ

サポートされていて互換性のあるストレージ アレイおよび SRA の現在のリストについては、 Site Recovery Manager ストレージ パートナー互換性マトリックスを参照してください。

VMware の VSA のサポート

vSphere ストレージ アプライアンス（VSA）上に存在している仮想マシンは、vSphere レプリケーション（VR）を使用して SRM 5.0 により保護することができます。VSA は、SRM 5.0 と組み合わせる場合でも、ストレージ レプリケーション アダプタ（SRA）を必要とはしません。

インストールとアップグレードに関する注記

管理、インストール、およびアップグレードに関するドキュメントについては、『 Site Recovery Manager 管理者ガイド』を参照してください。

Site Recovery Manager 5.0 の主要な特徴と機能に関するテクニカル ウォークスルーのための評価ガイドについては、 ビジネス継続性のための VMware vCenter Site Recovery Manager リソースを参照してください。

以前のリリースからのアップグレード：

SRM 5.0 に上書きアップグレードできるのは、SRM 4.1 および 4.1.1 を使用している場合に限られます。SRM 5.0 アップデート リリースでサポートされているアップグレード パスについては、これらのアップデート リリースのリリース ノートを参照してください。この場合には、新規インストールよりも上書きアップグレードの方が推奨されます。すべての履歴レポート、リカバリ プラン、保護グループおよびリカバリ プランのカスタマイズがすべて保存されるからです。

SRM 5.0 は、アレイベースのレプリケーションを使用している場合に限り、vSphere の以前のバージョン（4.0、4.1）および仮想インフラストラクチャの以前のバージョン（3.5）とともに実行することができます。vSphere レプリケーションを（単独で、またはアレイベースのレプリケーションと組み合わせて）使用する場合には、アップグレード プロセスの一部として、vSphere ホストをバージョン 5.0 にアップグレードする必要があります。

SRM 5.0 の高レベルのアップグレード ステップでは、次の操作を行います。

1. vSphere Client から SRM プラグインをアンインストールします。
2. 保護サイトの vCenter Server サービスを停止して、バージョン 5.0 にアップグレードします。
3. vSphere レプリケーションを使用する予定の場合には、この時点で vSphere ホストを ESXi 5.0 にアップグレードする必要があります。
4. 保護サイトの SRM サービスを停止して、バージョン 5.0 にアップグレードします。
5. SRM 5.0 と互換性のあるストレージ レプリケーション アダプタ（SRA）をアップグレードまたはインストールします。この SRA は、VMware により SRM 5.0 で使用可能として認定されたものである必要があります。
6. リカバリ サイトで、ベースとなる vSphere および vCenter Server の機能が正しく動作していることを確認してから、この手順を繰り返します。SRM は、両方のサイトが完全にアップグレードされるまでは機能しません。
7. SRM プラグインをダウンロードして、vSphere Client にインストールします。
8. SRM を起動して、SRA が正しく更新されていることを確認します。
9. サイト、アレイ マネージャ、およびデバイスをペアリングします。アレイのペアを有効にします。
10. srm-migration コマンド ライン ユーティリティを実行して、以前のリカバリ プラン、保護グループ、履歴レポート、スクリプト、および IP カスタマイズをインポートします。

アップグレード プロセスの詳細なドキュメントについては、『 Site Recovery Manager 管理ガイド』の 33 ～ 37 ページを参照してください。

SRM SDK

SRM 5.0 には、33 個の新しい API 操作が含まれています。その多くはサイト特有のもので、各サイトに固有のプロセスの自動化を可能にします。SRM 5.0 の新しい API 操作には次のものが含まれています。

• ListProtectionGroups
• ListInventoryMappings
• GetInfo
• GetPeer
• ListProtectedVms
• ListProtectedDatastores
• ListAssociatedVms
• GetProtectionState
• ProtectionGroupListRecoveryPlans
• ProtectionGroupQueryVmProtection
• ProtectVms
• UnprotectVms
• AssociateVms
• UnassociateVms
• GetTasks
• IsComplete
• GetProtectionStatus
• ListPlans
• GetHistory
• RecoveryPlanGetInfo
• RecoveryPlanGetPeer
• 起動
• キャンセル
• ListPrompts
• AnswerPrompt
• GetResultCount
• GetRecoveryResult
• GetResultLength
• RetrieveStatus
• RetrieveContent
• SrmLoginLocale
• SrmLoginSites
• SrmLogoutLocale

VMware では、SRM SOAP ベースの API の使用方法についての、更新された総合的なガイドを公開する予定です。これは VMware vCenter Site Recovery Manager APIでご利用できる予定です。

オープン ソースのコンポーネント

vCenter Site Recovery Manager 5.0 で配布されているオープン ソース ソフトウェア コンポーネントに適用される著作権表記とライセンスは、 IT のディザスタ リカバリを実現する VMware vCenter Site Recovery Manager をダウンロードのリンクから参照できます。また、vCenter Site Recovery Manager の一般リリースの最新版で利用できるソースコードへの変更やソースコードを要求する GPL、LGPL、あるいはその他の同等のライセンスに対するソースファイルをダウンロードすることもできます。

注意と制限

• Storage vMotion および Storage DRS との相互運用性
  ストレージ移動中の回復機能が制限される、一部の特殊なケースが存在するため、Site Recovery Manager 5.0 を Storage vMotion（SVmotion）と組み合わせて使用すること、またデータストア クラスタの使用を含む Storage Distributed Resource Scheduler（SDRS）と組み合わせて使用することはサポートされていません。

• vCloud Director との相互運用性
  Site Recovery Manager 5.0 は、vCloud Director 環境に対する制限付きのサポートを提供しています。SRM を使用して、vCloud リソース プール（組織に展開される仮想マシン）内の仮想マシンを保護することは、サポートされていません。SRM を使用した vCD の管理構造の保護がサポートされています。SRM を使用して vCD サーバ インスタンス、vCenter Server インスタンス、vCloud Director の管理インフラストラクチャを提供するデータベースを保護する方法については、『 VMware vCloud Director Infrastructure Resiliency Case Study』を参照してください。

• vSphere レプリケーションでの再保護と自動フェイルバックはサポートされていない
  再保護と自動フェイルバックは、アレイで複製された仮想マシンでのみサポートされています。vSphere レプリケーションで構成されている仮想マシンを、既存のリカバリ プランを使用して元のサイトに自動的にフェイルバックすることはできません。

• SRM で CPU 単位から VM 単位に変換した場合のライセンス数は正しくない
  SRM 1.x および SRM 4.0 を購入したカスタマの一部は、依然として CPU 単位で割り当てられたライセンスを使用しています。これらの古い CPU 単位のライセンスから VM SRM 5.0 単位のライセンスへの変換プロセスには、CPU ライセンスの使用数をカウントする公式が厳格さに欠けているという、既知の問題があります。このようなシナリオでは、変換により、SRM 5.0 用の VM 単位のライセンスが誤って多く与えられることになります。この動作は正しくないため、SRM へのパッチで修正される予定です。注意してライセンス変換数の記録を取り、それが、ライセンス契約の内容と一致していること、そしてライセンスを受けている保護された仮想マシン数を超えていないことを確認してください。

• アレイベースのレプリケーション（ABR）および vSphere レプリケーション（VR）のスケーラビリティ制限数
  

  『Site Recovery Manager 管理者ガイド』に記されているスケーラビリティ制限数には間違いがあり、間もなく更新される予定です。正しいスケーラビリティ制限数は次のようになります。

  アレイベースのレプリケーション（ABR）のスケーラビリティ制限数

  保護グループごとの保護される仮想マシン数	500
  保護された仮想マシン	1000
  リカバリ プランごとの保護グループ数	150
  データストア グループ	150
  同時リカバリ数	10

  vSphere レプリケーション（VR）のスケーラビリティの制限数

  単一の保護グループごとの保護される仮想マシン数	500
  保護された仮想マシン	500
  単一のリカバリ プランごとの保護グループ数	250
  データストア グループ	250
  同時リカバリ数	10

既知の問題

次の既知の問題は、厳密なテストで発見されたものであり、このリリースで起こる可能性のあるいくつかの動作を理解するのに役立ちます。

• New: glibc ライブラリの脆弱性によってリモート コードの実行が許可される

  vSphere Replication アプライアンスが glibc の脆弱性の影響を受け、それによってリモート コードの実行が許可される可能性があります。

  回避策：この問題の回避方法については、 http://kb.vmware.com/kb/2144289 を参照してください。

• SRM ではリカバリ中にデータストアのマウントに関連するエラーが発生する場合がある

  テスト フェイルオーバーまたは実際のフェイルオーバー中に、SRM はリカバリされたデータストアが利用可能になるのを待ちます。データストアが利用可能になると、SRM はマウントされていないデータストアをマウントしようと試みます。稀な例では、これらのデータストアは自動的にマウントされてから、SRM がマウントできるようになります。テスト フェイルオーバー中にこのようなことが起きた場合に、フェイルオーバーは完了しません。実際のフェイルオーバー中にこのようなことが起きた場合には、フェイルオーバーはエラーを示して完了します。この問題を解決するためには、フェイルオーバーをやり直してください。

• サブフォルダにレプリケートされた仮想マシンが予期しないフォルダを作成する

  仮想マシンに対して vSphere レプリケーション (VR) を構成するときに、リカバリ サイトのデータストアの任意のディレクトリにレプリケートするように、仮想マシンを構成することができます。選択されたディレクトリがルート ディレクトリにある場合は、レプリケーションは期待通りに完了します。選択されたディレクトリがルート レベルよりも下位にある場合、仮想マシンは指定されたディレクトリにレプリケートされません。代わりに、別のフォルダとサブフォルダの名前から構成される名前をもつ新しいディレクトリが作成されます。たとえば、 /path1/path2/path3は /path1path2path3となります。仮想マシンはレプリケートされますが、目的とする場所にはレプリケートされません。この問題を回避するためには、仮想マシンをルート レベルのフォルダにレプリケートしてください。

• リソースのマッピング中に SRM サービスを停止すると vSphere Client に障害が発生する

  ユーザーが vSphere Client を使用してリソース マッピングを構成している間に SRM サービスが停止した場合は、クライアントは接続エラーのメッセージを表示する動作となっています。代わりに、クライアントは無応答状態になります。この問題を解決するためには、Windows のタスク マネージャを使用して vSphere Client プロセスを終了してください。この問題を回避するためには、SRM サービスがリソース マッピングを構成中に実行されていることを確認してください。

• 権限の足りないユーザーは、誤解を招く条件レプリケーションを作成する場合がある

  vSphere レプリケーション ウィザードを使用して、仮想マシンのレプリケーションを構成することができます。このウィザードの使用は適切な権限をもつユーザーに制限されています。不十分な権限をもつユーザーが vSphere レプリケーション ウィザードを使用してレプリケーションを再構成しようとすると、操作が許可されないことを示すエラーが、ウィザードの最後に表示されます。次のエラーが表示されます。

  ディスク「 [Disk Name] VMDK name」のコントローラ タイプを特定できません。この操作の実行権限が拒否されました。

  vSphere Client が問題を示しても、仮想マシンのレプリケーションが期待通りに続行されます。この問題を解決するには、十分な権限をもつユーザーが操作を再実行して、クライアントのメッセージを解決します。

• vSphere レプリケーション管理サーバ（VRMS）のペアリングまたはペアリングの解除が LockingFailedException で失敗する

  稀なケースですが、VRMS サーバ間のペアリングまたはペアリングの解除を行うとき、vSphere サービスがその時停止している場合、次の例外により処理が失敗します。

  LockingFailedException: 障害のある書き込みロックされたオブジェクト: com.vmware.hms.db.entities.HmsLocalServerEntity: VRM Server GUID

  この問題を解決するためには、VRMS を再起動してください。

• vCenter Server 接続を一時的に失うと、Raw ディスク マッピングを使用している仮想マシンにリカバリの問題が生じる可能性がある

  フェイルオーバー中に vCenter Server への接続が失われた場合、次のいずれかが起こる場合があります。

  • vCenter Server は引き続き利用できず、フェイルオーバーは失敗します。この問題を解決するためには、vCenter Server との接続を再確立し、リカバリを再実行してください。
  • 稀に、vCenter Server が再び利用可能になり、仮想マシンがリカバリされます。このような場合、仮想マシンに Raw ディスク マッピング (RDM) がある場合、RDM は正しくマッピングされない場合があります。RDM を正しくマッピングできなかった結果として、仮想マシンの電源をオンにすることができない場合があり、ゲスト オペレーティング システムまたはその中で実行中のアプリケーションに関連するエラーが発生する場合があります。
    • これがテスト フェイルオーバーの場合、クリーンアップ操作を完了し、テストをもう一度実行してください。
    • これが実際のフェイルオーバーの場合、手動で正しい RDM をリカバリした仮想マシンに接続してください。

  Raw ディスク マッピングの追加に関する詳細は、仮想マシン設定の編集に関する vSphere のマニュアルを参照してください。

• リカバリ プランのキャンセルが完了しない

  リカバリ プランが実行されたとき、仮想マシンを同期するための試みが行われます。リカバリ プランをキャンセルすることはできますが、同期が完了するか、有効期限が切れるまで、リカバリ プランの実施のキャンセルを試みても完了しません。デフォルトの有効期限は 60 分間です。次のオプションは、リカバリ プランのキャンセルを完了するために使用できます。

  • vSphere Replicationを一時停止する。同期が失敗します。フェイルオーバーがエラー状態になった後で、vSphere Client を使用して、vSphere レプリケーション タブで vSphere レプリケーションを再開します。レプリケーションが再開した後で、リカバリ プランを適宜、もう一度実行することができます。
  • 同期が完了するか、タイムアウトするのを待つ。これは大幅に時間がかかりますが、最終的には終了します。同期が完了するか、タイムアウトすると、リカバリ プランのキャンセルが続行します。

• 有効な証明書で警告が出される

  vSphere レプリケーション管理サーバ（VRMS）に証明書をアップロードし、インストールすると、次のエラーが発生します。

  The certificate installed with warnings.「信頼性のある CA により署名された SSL 証明書のみを受諾する」オプションが有効になっているリモート VRM システムは、「証明書が指定されたホスト名： VRM ホスト名で使用するように発行されていない」という理由で、このサイトに接続できない場合があります。

  このエラーは無視することができます。または、Internet Explorer 以外のサポートされているブラウザを使用すれば、このエラーを避けることができます。

• 有効な証明書で警告が出される

  vSphere レプリケーション管理サーバ（VRMS）は、次の条件が両方とも成立していた場合、証明書に関連した問題のためにペアリングに失敗します。

  • サーバの証明書のホスト名の値が、VRMS のアドレスとマッチしない。
    ホスト名の値には、サブジェクト名または代替のサブジェクト名が含まれている場合があります。VRMS アドレスは、アプリケーションの構成時に仮想アプライアンス管理インフラストラクチャ（VAMI）によって指定されます。
  • ピア VRMS サーバが、証明書のための認証局（CA）への信頼の有効なチェーンを持っている。
    このことは、証明書が Verisign や Go Daddy のような信頼性のある CA から発行されたものである場合、または、不明な CA から発行されたものであっても、その証明書がピア VRMS サーバの hms-truststore.jksファイルに追加されていて、その理由で信頼が確立されている場合に生じます。

  この問題を解決するには、次の手段のうちのいずれかを実行してください。

  • VAMI の [ 生成とインストール] 機能を使用して、新しい証明書を作成してインストールします。
  • VAMI を使用して、VRMS サーバとマッチするホスト名の値を持つ証明書をアップロードします。
  • ピア VRMS の hms-truststore.jksファイルから、自己署名された認証局からの証明書を削除します。

• VMware Tools のハートビートを無視するためのプランごとのオプションが利用できない

  リカバリ プランは一般的に、仮想マシンが VMware Tools ハートビートを発行するのを待ちます。前のバージョンの SRM では、リカバリ プランごとにこのチェックを無効にすることができました。リカバリ プラン レベルでこのオプションを有効にしたり、無効にすることはできなくなりました。ツールのハートビート待ちを無効にすることは、詳細設定を使用してシステム全体に対して、または個々の仮想マシンに対して行うことができるようになりました。

• 複数の vSphere Client SRM プラグインのインストールにより問題が生じる

  常に 1 つのバージョンの vSphere Client SRM プラグインのみをインストールするようにする必要があります。SRM 5.0 のプラグイン上にバージョン 4.0.x または 4.1.0 のクライアント プラグインをインストールしようとしても、問題なく続行できます。クライアント プラグインの新しいバージョンをインストールする前に、既存の SRM プラグインをアンインストールしてください。複数の vSphere Client プラグインをインストールしている場合には、すべてのクライアント プラグインをアンインストールしてから、管理対象のサーバからプラグインをダウンロードして、再インストールしてください。

• 仮想マシンが同期されないため、保護グループでエラーが報告される

  仮想マシンが vSphere レプリケーションにより保護されると、その仮想マシンはリカバリ サイトにレプリケートされます。レプリケーション操作では、進行していないように見える操作をキャンセルするタイムアウト値が設定されています。仮想マシンがレプリケートされていない場合、それが属する保護グループはエラー状態になります。場合によっては、期待通りに進行しているのにもかかわらず、仮想マシンはタイムアウトの前にレプリケートできません。たとえば、大型仮想マシンが作成されたり、大量の変更が仮想マシンに対して行われるとき、必要なレプリケーションは使用可能な時間を超える可能性があります。この問題を解決する方法:

  • レプリケーションが完了するまで、目標リカバリ時点を増やす。
  • SRM 構成ファイルでタイムアウトを増やす。

  たとえば、レプリケーション タイムアウト 2 時間 (7200 秒) に変更するために、構成ファイルを次の通り変更します。

  <config>
  ...
  <hbrProvider>
  <synchronizationTimeout>7200</synchronizationTimeout>
  </hbrProvider>
  ...
  </config>
  
• SRM サービスが、データベースの応答を待った後に停止する

  SRM は、データベースへのクエリに対する応答を待つようになっています。ネットワークの帯域幅が不十分な場合、またはデータベースの負荷が大きすぎる場合には、応答が返る前にタイムアウトになることがあります。そのようなときには、SRM のログに次のエラーのいずれかが記録されます。

  • パニック：'DrReplicationProviderInterface' の待機中にタイムアウトになりました（300 秒）
  • パニック：'DrReplicationRecoveryInterface' の待機中にタイムアウトになりました（300 秒）
  • パニック：'DrStorageManager' の待機中にタイムアウトになりました（300 秒）

  この問題を回避するためには、SRM の、クエリへの応答の待ち時間を長くしてください。たとえば、タイムアウトを 15 分（900 秒）に変更するには、vmware-dr.xml 構成ファイルを次のように変更します。

  <config>
  ...
  <waitForObjectTimeout>900</waitForObjectTimeout>
  ...
  </config>
  
• 評価モードの SRM のライセンスが誤った情報を表示する

  ライセンスは、vSphere ライセンスの管理ウィザードを使用して管理できます。このウィザードが評価モードで実行される SRM のインストールで使用されるとき、ライセンス数に関して表示される情報が誤っている可能性があります。評価モードで、vSphere Client は無制限のライセンスが使用できることを示す場合があります。vCenter Server は使用可能なライセンス数および使用数を追跡し、適宜、ライセンスを制限します。

• vSphere Client が仮想マシンの古いリカバリ ステータスを表示する

  リカバリ プランの実行時には、仮想マシンのリカバリ ステータスの変化が vSphere Client に自動的に反映されるようにはなっていません。この問題を解決するためには、[ 更新] をクリックします。

• ユーザーは拒否された操作に関して通知されない

  ユーザーが仮想マシンを保護グループから削除しようとしていて、十分な権限を持っていなかった場合には、操作は失敗しますが、ユーザーにはこの失敗が通知されません。システムが期待通りに機能しますが、エラー メッセージが表示されないため、ユーザーにそのタスクが完了したものと信じ込ませてしまう可能性があります。

• 再保護によりユーザーは許可されていないタスクを完了できる場合がある

  ユーザーが再保護操作を実行したときには、与えられている権限で許可されている以上のタスクが完了することがあります。ユーザーが、許可がなくても完了できる可能性のあるタスクとしては、再保護されているターゲット サイト上での仮想マシンの作成、または再保護されているソース サイトでの新しいデバイスの保護があります。これは、他のユーザーが古い本番サイトで仮想マシンを削除した後、またはフェイルオーバー先となっている仮想マシンを修正した後で再保護が開始された場合に生じます。

• 計画された移行中にユーザー インターフェイスが予期なく変更される

  計画された移行中に、仮想マシンはアクティブでなくなり、リカバリ サイトに同期されます。このプロセス中に、保護グループとその仮想マシンが一時的に [ 部分的にリカバリされました] の状態で表示されます。vSphere Client は、これらの状態に適切な [ 保護グループの編集] および [ 保護グループの削除] などのボタンを有効にしますが、これらのボタンによりトリガされた操作は成功しません。これらの状態とボタンの使用可能性が変化することにより、ユーザーが混乱する場合があります。これらの変更は正常で、計画された移行中に発生するはずで、無視することができます。

• SRM 5.0 のアップグレード後にリカバリ履歴が失われる場合がある

  サーバの移行アップグレードの際、インストーラは、現在使用されているサイト名ではなく、デフォルトのサイト名を使用します。デフォルトのサイト名を現在のサイト名で置き換えなかった場合には、リカバリ履歴が失われる可能性があります。この問題を回避するためには、サイト名を、構築環境で使用されている名前に変更してください。デフォルトのサイト名でアップグレードを完了して、リカバリ履歴が失われてしまった場合には、バックアップから 4.1 のデータベースをリストアして、アップグレードをもう一度実行してください。このときには正しいサイト名を指定してください。

• VRM サーバはパスワード保護されていない PKCS#12 ファイルをサポートしない

  PKCS#12 ファイルは一般的にパスワードで保護されています。VRM サーバはパスワード保護されていない証明書をサポートしていません。パスワード保護されていないファイルを検索し、選択することは可能ですが、証明書はインストールされません。この問題を回避するためには、パスワード保護された PKCS#12 ファイルを使用してください。

• デフォルト サイト名でライセンス情報が取得できない

  SRM のライセンス情報は、SRM サイト名を使用して vCenter でラベルが付けられます。デフォルト サイト名が使用され、複数の SRM サーバが同じ vCenter グループで登録されている場合、デフォルトの SRM サーバ名によってライセンス情報が識別できなくなります。この問題を回避するために、インストール中に固有のサイト名を指定してください。

• [はじめに] ページが見つからない

  [はじめに] ページは SRM および VR の構成を支援するリンクや情報を含みます。すべての [はじめに] タブを以前に閉じている場合は、[編集] メニューの [クライアント設定] ダイアログのオプションを選択することでリストアできます。

• SRM を ASCII 以外の文字が使用されているマシンにインストールすると、アクセスの問題が生じる

  SRM を、名前に ASCII 以外の文字が含まれているマシンにインストールすると、ユーザー アクセスの問題が生じることがあります。マシン名は URL を構成するために使用されますが、ASCII 以外の文字を含む URL は無効なものになる場合があります。この問題を回避するためには、SRM は、すべて ASCII 文字から構成されている名前を持つマシンにインストールしてください。

• ASCII 以外の文字を含むパスワードは、仮想アプライアンス管理インフラストラクチャ（VAMI）へログインする際には受け付けられない

  ユーザーは VAMI を使用して、vSphere レプリケーション管理サーバ（VRMS）を管理できます。ASCII 文字以外を使用するパスワードを持つアカウントで、VAMI にログインしようとすると失敗します。これは、正しい認証情報が指定されたときでも起こります。この問題は、ASCII 以外の文字が VAMI で使用されているすべての場合に起こります。この問題を回避するためには、ASCII パスワードを使用するか、SSH を使用して接続してください。

• ASCII 以外の文字を含む DNS サフィックスを、Windows XP および Windows 2003 のカスタマイズ後正しく設定することはできない

  Windows XP または Windows 2003 をカスタマイズするために [仮想マシンのリカバリ プロパティ] ダイアログの [IP 設定] セクションの [DNS] タブに ASCII 以外の文字を含む DNS サフィックスを入力した場合、カスタマイズは正常に行われたと報告されますが、ASCII 以外の文字を含む DNS サフィックスは正しく設定されません。この問題を回避するためには、Windows XP および Windows 2003 内で DNS サフィックスを手動で設定してください。

• ASCII 以外の文字を出力するカスタム リカバリ ステップでは SRM サーバがクラッシュする

  ASCII 以外の文字を出力するカスタム リカバリ ステップは作成しないでください。そのようなステップをプランに追加して、テストまたはリカバリを実行すると、SRM サーバはクラッシュします。ASCII 以外の文字を出力するステップを含むプランを使用すると、プランは変更や削除のできない状態に入ります。ASCII 以外の文字を出力しない新しいプランを作成して、保護グループのリカバリ プランで使用してください。そして、将来のテストやリカバリでは ASCII 以外の文字を出力するプランを使用しないでください。ASCII 以外の文字のためにクラッシュしたサーバは、再起動してください。

• テスト クリーンアップ中に仮想マシンをパワーオフできない

  テスト クリーンアップ中に、仮想マシンがパワーオフになります。これは、ストレージ集中操作となる可能性があります。稀に、パワーオフには 30 分以上かかる場合があり、SRM が仮想マシンがパワーオフになるのを待つ 15 分を超えることがあります。15 分間のタイムアウトを超える場合、メッセージ「 エラー - 操作のタイムアウト: 900 秒間」が表示されます。この問題を解決するためには、パワーオフが完了するのを待ち、クリーンアップをもう一度実行してください。テスト仮想マシンを手動でパワーオフすることもできます。

• 実行中の vSphere Client はインストール後の vSphere レプリケーション サーバを管理することができない

  vSphere レプリケーション（VR）サーバは vSphere Client を使用して管理されます。vSphere Client は、SRM プラグインが有効になっていれば、インストールされた VR サーバの管理を行えます。SRM プラグインを含む vSphere Client が起動すると、vSphere Client は利用可能なすべての VR サーバを検索し、それらを管理対象候補の選択項目として提示します。vSphere Client の起動後に VR サーバを構成した場合、これらの新しいサーバは自動的には検出されません。利用可能なすべての VR サーバが管理対象 VR の選択項目として提示されるようにするには、VR サーバのインストールまたは構成後に、次の操作を実行してください。

  • SRM プラグインを有効にします。
  • クライアントを再起動します。

  どちらを実行しても、クライアントの利用可能な VR サーバのリストは更新されます。

• リカバリ プランの構成インターフェイスに無効なネットワークオプションが表示される

  リカバリ プランの構成の際には、仮想マシンと関連付けるネットワークを選択する必要があります。リカバリ プランのユーザー インターフェイスには、有効なオプションがないにもかかわらず、DVS アップリンク ポート グループが可能な選択項目として表示されます。DVS アップリンク ポート グループは選択しないでください。

• データストアが利用できなくなると古いレプリケーション ステータスが表示される

  仮想マシンの同期が開始した後で、ターゲットのデータストアが利用できなくなることがあります。このような場合、グループのステータスにはこのエラーについての情報が表示されるはずですが、実際にはステータスは変化しません。データストアが利用できなくなったことに関連する問題を確認するには、ターゲット データストアが生成するイベントを参照してください。このような場合、次のイベントが生成されます。

  • Datastore is not accessible for VR Server...データストアにアクセスできなくなると、直ちに生成されます
  • Virtual machine vSphere Replication RPO is violated...指定された RPO 内でレプリカを生成することができません

• vSphere レプリケーション管理サーバとの接続が切れると、仮想マシンのステータスが更新されない

  vSphere レプリケーション管理サーバ（VRMS）は、仮想マシンのレプリケーションに関する情報をサイトの間で交換します。 [ VRMS 接続の切断] オプションで VRMS との接続を切ると、VRMS 接続を再構成しても、複製された仮想マシンについての情報の交換は、自動的には再確立されません。そのため、どの仮想マシンを保護グループに追加できるかを含む、仮想マシンのレプリケーションについての情報が不完全になります。この問題を解決するには、SRM サービスを再起動してください。

• vSphere Client に表示される情報が古くなることがある

  リカバリ プランの内容などの SRM のデータを変更しているとき、表示される情報が SRM 情報の変更に合わせて更新されないことがあります。たとえば、あまり重要でない仮想マシンをサスペンドするためにリカバリ プランに追加するとき、この変更についての情報は自動的には表示されません。この種の問題を解決するには、利用できる場合には [ 更新] をクリックします。または、古くなった情報を表示しているページからいったん移動して再び戻ります。これにより、画面の内容は更新され、最新の情報が表示されます。

• 保護されている仮想マシンのデータストア レプリケーションを停止すると、間違ったエラー メッセージが出される

  複数のデータストア上にディスクを持っている仮想マシンを保護して、その後、データストアの 1 つでレプリケーションを無効にすることは可能です。そのような場合、保護グループ内の仮想マシンのステータスは、次のように変更します。 Invalid: Virtual machine 'VM' is no longer protected.Internal error: Cannot create locator for disk'2001'...この情報は正しくありません。ステータスは Datastore '[ datastore name]' is no longer replicatedとなるはずです。

• 無効な証明書は認証中に拒否される

  SRM は証明書ベースの認証をサポートしています。SRM サーバが無効な証明書を持っている場合に、vSphere Client が SRM サーバに接続するために SRM プラグインを使用すると、エラーが発生します。無効な証明書は、証明書チェーンのいずれかの証明書の期限が切れた場合、またはまだ有効になっていない場合に発生します。そのよう場合には、次のメッセージが出されます。 The SSL connection to the remote host has terminated.リモート ホストの証明書に次の問題があります：ホストのチェーン内にある証明書の期間が有効ではありません。この問題を解決するには、SRM サーバに有効な証明書をインストールしてください。

• プレースホルダを短い時間内に削除し、再作成を行うと、問題が発生する

  データストアからすべてのプレースホルダ仮想マシンを削除し、データストアをアンマウントしてから、データストアの再マウントを行うと、プレースホルダ仮想マシン再作成までに 10 分間待たなければならないことがあります。データストアのアンマウントの 10 分以内にプレースホルダを再作成すると、操作が失敗し、フォールト NoCompatibleHostFoundが発生することがあります。この問題を回避する、または解決するには、10 分以上待ってからプレースホルダ仮想マシンの再作成を試みてください。

• ポリシーの制限のためにインストールが失敗する

  SRM のインストールは、「 システム管理者はこのインストールを妨げるポリシーを設定しています。」というエラーにより失敗することがあります。これは通常、オペレーティング システムのアップグレード時、またはパッチの適用時に、新しい設定が適用された結果として生じます。この問題は、次のもののうち、状況と関連するソリューションによって解決してください。

  • Windows のアップデートのために、制限が厳しくなって、インストールが妨げられている場合には、十分な権限を持つアカウントを使用してインストールを完了してください。必要な権限を得るには、十分な権限を持つアカウントでログインし、そのアカウントでインストールを完了します。または他のアカウントに権限を与えて、そのアカウントでインストールを完了します。
  • エラーが、デジタル署名ポリシーのために拒否されて発生した場合には、ホットフィックス 925336 をインストールしてください。
• 変更操作中にユーザー生成による証明書を使用しようとすると失敗する

  インストールの変更操作は、初期インストールの際に使用した SRM マシン アドレス以外のサブジェクトの別名（SAN）を含む証明書を使用すると、失敗します。証明書の SAN で使用されている SRM マシン アドレスは、SRM のインストール時に入力したものと正確に一致している必要があります。この値としてはマシン名、FQDN、または IP アドレスがあり得ます。

  問題が発生した場合には、初期インストールで使用した値とマッチする SAN を含む証明書を生成し、インストールの変更操作でこの証明書を使用してください。マッチする値を含む証明書を生成できない場合には、データベースの内容を保存しながら、サーバの再インストールを行う必要があります。

• パワーオフ状態の仮想マシンのリカバリは失敗することがある

  仮想マシンのリカバリを行う際、SRM は前もって仮想マシンを保護サイトからリカバリ サイトに複製する必要があります。ある場合には、vSphere レプリケーション（VR）で保護されている仮想マシンが複製されず、結果としてテスト リカバリができないことがあります。これは次のような場合です。

  • レプリケーションが最初に確立されてから、レプリケーションが完了するまでには、少しの時間があります。仮想マシンが複製される前に災害が発生した場合には、仮想マシンをリカバリすることができません。この問題を避ける方法はありません。
  • テスト リカバリの際、[ 最近の変更をリカバリ サイトに複製する] オプションがオンになっていると、パワーオン状態の仮想マシンだけが同期されます。このことは、VR 保護が確立してからパワーオンされていない仮想マシン、または初期同期が完了していない仮想マシンは、テスト リカバリではリカバリできないことを意味しています。この問題を回避するためには、テスト リカバリを実行する前に、初期同期が完了していることを確認してください。
  • 初期同期が完了していないパワーオフ状態の仮想マシンについては、[ 最近の変更をリカバリ サイトに複製する] オプションをオンにせずに計画移行を実行すると、リカバリ サイトに仮想マシンデータが存在しないため、計画移行が失敗します。この問題を回避するためには、計画移行の際、そのような仮想マシンでは常に [ 最近の変更をリカバリ サイトに複製する] を有効にしておいてください。
• 仮想マシンのリカバリはディスク構成エラーが原因で失敗する

  複数のデータストア上の単一の保護仮想マシンに対し、複数のディスクと構成ファイルを配置することは可能です。リカバリの際に、SRM は、Raw ディスク マッピングと親ディスク ファイルにアクセスする必要があります。このアクセスが行えないと、SRM はリカバリの際のディスク タイプを決定することができません。そのような場合、SRM は Raw ディスク マッピング（RDM）ディスクを非 RDM のディスクであると仮定するため、再構成に失敗します。この問題を回避するためには、リカバリされた仮想マシンの構成ファイルにアクセスできるすべてのホストが、RDM マッピング ファイルおよびすべての親ディスク（存在する場合）にもアクセスできることを確認してください。

• VRMS 用にユーザーが用意する証明書には、VRMS の FQDN であるサブジェクトの別名が含まれている必要がある

  ユーザーが用意する証明書を使用する場合、そのサブジェクトの別名は、vSphere レプリケーション管理サーバ（VRMS）の完全修飾ドメイン名（FQDN）である必要があります。OpenSSL 認証局を使用している場合には、OpenSSL の構成ファイルを変更して、この情報を含めてください。この必要な構成情報は、次の例のようになります。

  subjectAltName = DNS:VRMS.example.com

• SRM サーバはネットワーク再構成後の開始に失敗する

  SRM サーバ名または IP アドレスの変更はサポートされていません。SRM サーバのマシン名と IP アドレスは初期インストール時に保存されます。この値を SRM システム内で変更することはできません。この問題を解決するには、SRM をアンインストールし、SRM データベースの内容を保存しておいて、現在のマシン名、アドレス、および保存されたデータベースを使用して SRM を再インストールしてください。

• サイトのペアリングは証明書の信頼方式が異なっていると失敗する

  SRM サイトのペアリングの際に、 Local and Remote servers are using different certificate trust methodsというエラーが表示されることがあります。これは、証明書に署名している認証局（CA）のルート証明書が SRM サーバ上に存在していない場合に生じます。この問題を解決するには、SRM の証明書に署名している認証局のルート証明書を、Microsoft 管理コンソールを使用してインストールします。証明書のインストール後に、SRM のインストール変更操作を実行して、ユーザー生成の証明書をもう一度指定してください。

• 多数の vSphere Client が SRM に接続していると操作が失敗することがある

  SRM は、大規模な固定サイズの接続プールを使用して、他のサイトにある vCenter Server および SRM サーバと通信し、タスクを実行します。利用可能な接続数は、接続している vSphere Client の数が増えると減少します。多くの場合、そのためにシステムのパフォーマンスに悪影響が出ることはありませんが、多数の仮想マシンの保護および保護解除や、多数のリカバリ プランの実行およびテストなど、多くの操作が同時に実行されている場合には、問題が生じることがあります。操作が、様々な理由でタイムアウトになったり、失敗したりすることがあります。この問題が発生した場合には、SRM サーバへの、当面必要のないクライアントからの接続を閉じれば解決できます。接続は放棄されるものの、タイムアウトして完全に閉じるまでには最大 30 分かかることに注意してください。放棄された接続をもっと速く終了させるには、SRM サーバを再起動してください。

• プレースホルダ仮想マシンで間違ったアイコンが使用されることがある

  ある状況では、vSphere Client がプレースホルダ仮想マシンのアイコンのダウンロードに失敗することがあります。このような場合には、代わりに汎用のソリューション仮想マシンのアイコンが表示されます。vSphere Client を再起動すれば、この問題は解決されることがあります。

• 保護サイトへの接続が失敗した後ではリカバリの進行が失敗する

  非アクティブ化操作中、または RemoteOnlineSync または RemotePostReprotectCleanup 中（どちらも再保護時に発生します）に保護サイトにアクセスできなくなると、リカバリ プランがそれ以上進行できなくなることがあります。そのような場合、システムは、保護サイトの一部である仮想マシンまたはグループが、それら中断されたタスクを完了するのを待ち続けています。再保護操作の際にこの問題が発生した場合には、元の保護サイトに再接続し、リカバリ プランをキャンセルしてから再起動する必要があります。フェイルオーバーの際にこの問題が発生した場合には、リカバリ プランをキャンセルして再起動するだけで十分です。

• 混合モード リカバリ プランを再保護しようとすると、再保護が不完全な状態になる

  保護グループとしては SAN ベースのものまたは vSphere レプリケーション（VR）ベースのものが可能です。そして、リカバリ プランを両方のタイプの保護グループを含むように構成することもできます。再保護は、SAN ベースおよび VR ベースの両方の保護グループが含まれているプランに対して実行することはできません。再保護機能では、保護グループが SAN ベースと VR ベースのどちらか一方だけから構成されているかどうかはチェックしません。両方の保護グループタイプから構成されている保護グループに対して再保護を実行しようとすると、プロセスは失敗し、リカバリ プランは [再保護が不完全] 状態のままになります。この問題を回避するためには、両方の保護タイプを含むリカバリ プランは作成しないでください。この問題を回避するためには、再保護の前に VR ベースの保護グループを削除してください。

• VRM サーバの一般エラー

  次のようなエラー メッセージが表示されることがあります： VRM サーバの一般エラー。このドキュメントでトラブルシューティング情報があるかどうかをチェックしてください。詳細な例外は <ホスト名>   です。このエラーは、vSphere レプリケーション管理サーバが、エラー メッセージに示されているホストの IP アドレスを解決できなかった場合に発生します。この問題を解決するには、DNS 構成に、解決が可能な何らかの問題があるかどうかを確認してください。また、完全修飾ドメイン名（FQDN）が要求されている箇所で、非 FQDN 名を使用していないかどうかチェックしてください。

• ユーザーが有効にしたアラームが全く出されない

  ユーザーは、[ Reconfigured protection settings for VM] アラームを有効にすることができますが、実際にはこのアラームは全くトリガーされません。これは、このリリースではユーザーが保護設定を編集することはできないからです。SRM の仮想マシン設定でユーザーが行おうとした変更を追跡するには、管理者が [ Reconfigured recovery location settings for VM] アラームを有効にする必要があります。

• ユーザーが vSphere Replicationの構成を試みると失敗する

  管理者権限を持つユーザーでも、やはり vSphere レプリケーションを構成できないことがあります。これは多くの場合、[ VRM Datastore Mapper > View] 権限が与えられていないためです。この問題を解決するには、保護サイトで適切なユーザー アカウントにこの権限を与えてください。

• vSphere レプリケーション管理サーバ（VRMS）が有効な ESX ホストのサポートに失敗する

  vSphere レプリケーション（VR）構成の際、サポートされているバージョンの ESX 上のデータストアを選択すると、 VR サーバ サーバ名 にはターゲット データストアにアクセスするためのホストがありません ...が表示されます。このことは、有効な選択対象であるにもかかわらず、ホストが 未サポート とタグ付けされているために発生します。VR サーバの登録の際、そのホストで、「 ホストは vSphere レプリケーション用に構成されています」イベントがトリガーされていません。ホストが未サポートとタグ付けされることは、VRM サーバの登録の際、または新しいホストを vCenter Server インベントリに接続する際に、VRM サーバと VR サーバの間で通信のエラーまたは中断が生じたために発生します。通信の問題は通常、接続性が一時的に失われたため、またはサーバのサービスが中断したために発生します。

  この問題を解決し、VR で使用できるようにホストを有効にするには、次の手順を実行する必要があります。

  1. リカバリ サイトで VRM データベースを参照します。
  2. HostEntity テーブルから、状態 4（未サポート）になっていて、HbrHostEntity テーブルから参照されていない（vcMoId 値）レコードをすべて削除します。HbrHostEntity テーブルからの参照項目（vcMoId 値）が存在する場合には、そのレコードは削除せず、状態値を 4 から 1（アクティブ）にアップデートします。
  3. ホストを vCenter インベントリから切断してから再接続します。
  4. そのホストで、「 Host is configured for vSphere Replication」イベントがトリガーされていることを確認します。

  VRM サーバ データベースでのこの問題を解決するために使用できるクエリの例は、次のようになります。

  1. クエリ
     • 未サポートとタグ付けされていて、VR サーバと関連付けられていないすべてのホストを問い合わせます：
       select * from HostEntity h where state=4 and not exists (select * from HbrHostEntity where h.vcMoId=HbrHostEntity.vcHost_vcMoId).
     • 未サポートとタグ付けされていて、VR サーバと関連付けられているすべてのホストを問い合わせます：select * from HostEntity h where state=4 and exists (select * from HbrHostEntity where h.vcMoId=HbrHostEntity.vcHost_vcMoId).
  2. 解決
     • VR サーバと関連づけられていないホストの、未サポートのレコードをクリーンアップします：
       delete from HostEntity where state=4 and not exists (select * from HbrHostEntity where vcMoId=HbrHostEntity.vcHost_vcMoId).
     • VR サーバと関連づけられていて、未サポートとタグ付けされているホストの状態をアクティブに変更します：
       update HostEntity set state=1 where state=4 and exists (select * from HbrHostEntity where vcMoId=HbrHostEntity.vcHost_vcMoId).

• 仮想マシンのディスクのレプリケーションを停止して再開すると、ディスクが複製されないままになる

  仮想マシン上の vSphere レプリケーションで保護されたディスクで、短い時間内にレプリケーションを無効に、それから有効に切り替えると、そのレプリケーション ステータスが [ 非アクティブ] になることがあります。この問題を解決するには、仮想マシンのレプリケーションの構成を解除してから再構成してください。

• ユーザーがカスタマイズした詳細設定がアップグレード時に失われる

  SRM 4.1 から SRM 5.0 にアップグレードすると、ユーザーがカスタマイズしたすべての詳細設定は、初期値のデフォルト設定で置き換えられます。この問題に対処するには、アップグレード後にカスタマイズした設定を再適用してください。上書きアップグレードの場合の、アップグレード前のカスタム設定についての参照情報は、 C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\vmware-dr.xml.bakにあります。

• 変化が生じるような方法で識別される NFS は一貫した保護を提供しない

  NFS ボリュームは、IP アドレスまたはホスト名によってデータストアとしてマウントされます。vCenter は、IP アドレスまたはホスト名を使用して、どの NFS マウンティングがどのデータストアにマップされるかを管理します。その結果、同じ NFS ホストの同じボリュームでも、別の IP アドレスまたはホスト名でマウントすると、異なるデータストアとして登録されます。

  ストレージ レプリケーション アダプタ（SRA）は、デバイス検出の際に、アドレスのリストを返します。SRM は、SRA が提示したアドレスを、マウントおよびデータストアとできる限りマッチさせようとします。SRA は、設定のグループを SRM に返します。SRM はこれらの値をアレイ構成の要素として提示しますが、これらの設定に対するコントロールは一切行いません。これらの値にはストレージのアドレスとポートが含まれており、この値はマウント ポイントを構成し、検出するために使用されます。SRA が 1 つのストレージ ポート値だけを提示した場合には、SRM はこのポート値だけを使用してマッチ項目を探します。しかし、他の有効な値が存在していることもあります。

  アレイ マネージャが使用する識別子が SRM が使用する識別子とは異なっている場合には、データストアは期待通りには保護されません。そのような共有上の仮想マシンは保護されず、フェイルオーバーの際にシャットダウンされません。

  この問題を回避するためには、NFS データストアのマウント、およびアレイ マネージャが行うストレージ ポート フィルタリングでは、いつも同じ IP アドレスまたはホスト名を使用してください。

• IPv6 が要求された場合には、ネットワーク情報フィールドに有効な情報が設定されない

  vSphere レプリケーション管理サーバ（VRMS）が IPv6 だけを使用するように構成されている場合、次の問題が発生します。

  • 仮想アプライアンス管理インフラストラクチャ（VAMI）のスタートアップページで、vCenter Server のアドレス フィールドに IPv4 リテラル アドレスが事前設定されます。このアドレスは、IPv6 のみを使用するアプライアンスでは使用できません。この問題を解決するには、フィールドを編集して、有効な DNS 名または IPv6 リテラル アドレスを入力してください。
  • サイト名フィールドには、事前設定が行われません。このフィールドには通常、vCenter Server インベントリ内のアプライアンスの仮想マシン名が事前設定されます。この問題を解決するには、有効なサイト名を入力してください。有効なサイト名とは、ピア サイトのサイト名とは異なるものです。

• Distributed Power Management (DPM) 対応のクラスタでは、データストアのアンマウントが失敗する

  計画移行およびリカバリは、ホストがスタンバイ モードに入っている場合、DPM クラスタに接続されているホストからのデータストアのアンマウントに失敗します。エラー Error: Cannot unmount datastore datastorename from host hostname.リモート ホストが切断されたため、通信できませんが表示されることがあります。この問題を解決するには、計画移行またはリカバリを完了する前に、保護サイトで DPM をオフにしてください。リカバリ タスクの完了後に、DPM をオンに戻すことができます。

• リカバリ中にストレージの同期を行うとエラーが発生する

  稀な例ですが、同期を有効にしていた場合、 ストレージの同期ステップで、次のエラーが発生することがあります： VRM グループ グループ名 の VR 同期が失敗しました。VRM Server generic error.このドキュメントでトラブルシューティング情報があるかどうかをチェックしてください。The detailed exception is: 'Optimistic locking failure'。このエラーが発生する可能性が高いのは、同期の必要な多数の仮想マシンと多量のデータの組み合わせがある場合のように、リカバリ プランの実行中に大量のデータの転送が行われる場合です。エラーは出ますが、同期は実際には成功しています。リカバリ プランをもう一度実行すれば、エラーが出ずに完了します。

• リカバリ中の NFC への接続失敗またはコピー エラー

  リカバリ中に、次のエラー メッセージが出されることがあります。

  • <host>  の NFC サービスに接続できませんでした。
  • ファイル <filePath>   を <newFilePath>   にコピーできませんでした: <errorCode>   - <errorMsg>  。

  このエラーは、多数の同時操作を完了しようとしているときに発生します。通常は、次の条件下で発生します。

  • vSphere Replication（VR）を使用して、保護されている 40 台以上の仮想マシンをリカバリしたとき。
  • ESX 3.5 ホスト上の 10 台以上のデータストアをリカバリしたとき。
  • Raw ディスク マッピング（RDM）ディスクを持っている仮想マシンに影響を及ぼす多数のリカバリ プランを実行したとき。このエラーは通常、4.x ホストで 20 個以上のリカバリ プランを実行した場合、または 5.0 ホストで 40 個以上のリカバリ プランを実行した場合に発生します。

  この問題を解決するには、影響を受けたリカバリ プランを再実行してください。

• [レプリケーションの構成] ウィザードの [次へ] ボタンをクリックしてもウィザードが進まない

  [レプリケーションの構成] ウィザードには、 [VR サーバ] というタイトルのページがあります。このページには常に有効になっている [ 次へ] ボタンがありますが、これをクリックしてもウィザードの次のページに進まないことがあります。このことは、SRM で VR サーバが 1 つ構成されていて、そのサーバが切断状態にある場合に発生します。この問題を解決するには、別の VR サーバを登録してください。または現在のサーバのステータスを [ 接続中] に変更してください。

• vSphere レプリケーション サーバに、指定した IPv6 アドレスが割り当てられない

  vSphere レプリケーション（VR）サーバおよび vSphere レプリケーション管理（VRM）サーバのデプロイの際、ユーザーはこれらのサーバが使用する IPv6 アドレスを指定することができます。これらのアドレスをブラケットで囲むと、アドレスは正しく適用されません。この問題を解決するには、IPv6 アドレスをブラケットなしで指定してください。

• vSphere レプリケーション管理（VRM）サーバは仮想マシン テンプレートの複製をサポートしていない

  VRM サーバは、仮想マシン テンプレートの複製をサポートしていません。テンプレートの複製を構成するオプションは、利用できません。VR により複製されたものの、その後テンプレートに変換された仮想マシンについては、複製は継続されません。テンプレートに変換された仮想マシンの複製の継続の問題を回避するためには、次のプロセスを実行してください。

  1. vSphere Client を vCenter Server に接続して、[ Site Recovery Manager] プラグインをクリックします。
  2. 左側のペインで [ vSphere レプリケーション] を選択して、リモートの VRM サーバを選択し、[ 仮想マシン] タブをクリックします。
  3. テンプレートに変換された仮想マシンを選択して、[ レプリケーションの削除] をクリックし、選択を確認します。

• レプリケーション構成の失敗後にも仮想マシンが選択可能になっている

  ウィザードを使用して複数の仮想マシンのレプリケーションを構成した場合、一部の仮想マシンを正しく構成できないことがあります。構成が失敗していても、これらの仮想マシンは、 保護グループの作成 ウィザードで選択項目として表示されるようになっています。これは、構成が失敗したという情報が伝えられないためです。この問題を解決するには、保護サイトの SRM サーバを再起動してください。

• Start コマンドを使用するカスタムのリカバリ ステップは完了しない

  カスタムのリカバリ ステップではコマンドを実行することができます。カスタムのリカバリ ステップでパラメータを付けずに Startコマンドを実行した場合、コマンドは完了しません。たとえば、コマンド c:\windows\system32\cmd.exe /C startは完了しません。この問題を解決するには、 startコマンドを実行したコマンド ウィンドウを手動で閉じてください。

• ネットワーク構成を指定しないでデプロイされた vSphere レプリケーション（VR）サーバは正しく動作しない

  VR サーバは、OVF デプロイ ウィザードを使用して、OVF ファイルからデプロイできます。デプロイ ウィザードには、VR サーバのネットワーク構成を指定するためのページが用意されています。ネットワーク構成でネットワーク設定を指定しなかった場合には、DHCP のアドレス指定が使用されますが、VR サーバは DHCP のアドレス指定をサポートしていません。この問題を回避するためには、デプロイの際に、VR サーバに有効なネットワーク設定を指定してください。

• 大規模なディスクで必要のない完全同期が実行される

  256GB よりも大きなディスクが vSphere Replication（VR）で保護されている場合、仮想ディスク デバイスの内部再起動を生じさせる操作を行うと、ディスクで完全同期が実行されます。内部再起動は、次のいずれかが行われると発生します。

  • 仮想マシンが再起動される
  • 仮想マシンで vMotion が実行される
  • 仮想マシンが再構成される
  • 仮想マシンのスナップショットが取られる
  • レプリケーションが一時停止されてから再開される

  完全同期は ESX により開始されるので、この問題の解決には ESX のアップデートが必要です。このような同期が行われると、保護サイトとリカバリ サイト両方のディスクで余分の I/O が発生します。これにはたいてい Recovery Point Objective（RPO）よりも長い時間がかかるので、RPO ターゲットが失われる結果になります。この問題を回避するためには、小規模なディスクを使用してください。

  注：これは ESXi Server 5.0 Update 1 で修正されています。

• ストレージが切断されるとリカバリ プランが完了できない

  リカバリ プランのテストまたは実行時に、仮想マシンをパワーオンするステップで、エラー テスト バブル イメージの作成中にエラーが発生しました...のため、リカバリ プランが失敗することがあります。このエラーは、複製データを保存する LUN が ESX サーバから切断され、その後再接続された場合に発生します。再接続後、レプリケーションは以前と同じく継続しますが、LUN には新しい内部識別子が割り当てられています。この新しい識別子は、保護される仮想マシンとは関連づけられていません。そのため SRM は、ストレージの同期も、複製された仮想マシンのイメージ作成も行うことができません。その結果、パワーオンのステップ全体が失敗します。この問題を解決するには、次の手順で、レプリケーションを再構成する必要があります。

  1. 直前に失敗したリカバリ プランをクリーンアップします。
  2. 影響を受けた保護グループに対して、再構成ウィザードを開始します。
  3. 切断されたデータストア上にあるファイルの場所を変更します。同じデータストアとフォルダの場所を選択します。
  4. ウィザードの提案どおり、既存のディスクの再使用に同意します。仮想マシンを再構成します。

  保護グループは完全同期状態に入り、その間にデータの整合性がチェックされます。プロセスが完了するのを待ちます。

• 計画移行のために ESX ホストが遅くなることがある

  計画移行の際、SRM はまず ESX ホストに対し、複製されたデータストアをアンマウントし、これらのデータストアの基になっている LUN を切り離すように指示します。次に SRM は、ストレージ アレイ ソフトウェアに対し、切り離された LUN を読み取り専用にするように指示します。これらのプロセスにより、ESX ホスト上のデバイスは、移行されるデータストアおよび LUN の全パス ダウン（APD）状態から分離されます。RDM を含む仮想マシンを移行した場合には、RDM LUN が APD 状態に入る可能性があります。RDM が APD 状態に入った後も、ESX ホストは、失われた RDM LUN への接続性確立を再試行し続けます。利用できない RDM の数が増えると、それに応じて、ESX ホストが失われた RDM への再接続を試みる回数も増加します。この状態が続くと、ESX ホストの応答は遅くなり、やがては vCenter Server からはホストが応答していないように見えることになります。特定のストレージ アレイでは、これの発生する可能性が高くなります。たとえば、SRA が LUN 単位で iSCSI ターゲットをサポートしている場合には、この現象が発生する可能性が高くなります。これらの問題を解決するには、ESX ホストをリブートしてください。

• リカバリが失敗すると SRM サーバのクラッシュが繰り返される

  リカバリ プランを継続できなくなった場合、ユーザーはリカバリ プランを再実行するかもしれません。稀な例ですが、リカバリ プランを再実行すると、SRM サーバがクラッシュすることがあります。サーバを再起動すると、リカバリ プランが継続し、またサーバをクラッシュさせます。この問題を解決するには、まずログの内容を確認して、クラッシュの直前に変更されていた仮想マシンを特定してください。エントリは通常、 仮想マシン <仮想マシン名>   の IP カスタマイズに成功という形式になっています。クラッシュの直前に IP カスタマイズが完了した仮想マシンがどれであるかがわかったら、次のいずれかのステップを実行してください。

  • この障害がテスト中に発生した場合には、影響を受けたプレースホルダ仮想マシンの登録を解除します。
  • この障害が実際のリカバリで発生した場合には、リカバリされた仮想マシンの登録を解除し、ネットワーク設定を手動でカスタマイズします。

  仮想マシンの問題を解決したら、SRM サーバを再起動して、リカバリ プランを再実行します。稀な例ですが、他の仮想マシンが同じ状態になっていることがあります。その場合には、1 つの仮想マシンを修復しても障害が続きます。それで、さらに処置を取る必要があります。障害が続く場合には、ログの確認と、影響を受けている仮想マシンを特定するプロセスを繰り返して、問題を解決してください。クリーンアップ ワークフローでエラーが発生した場合には、[ 強制クリーンアップ] チェックボックスをオンにして、システムを準備完了状態に戻してください。

• 韓国語のオペレーティング システムではイベントが正しく表示されない

  vSphere Client は開始すると、実行環境のロケールを判断し、ロケールに基づいて表示するメッセージのセットを選択します。vSphere Client を韓国語のオペレーティング システムにインストールした場合、クライアントは vCenter Server インストールの koフォルダからのメッセージを要求します。vCenter Server および vSphere Client は韓国語向けにローカライズされているからです。vCenter Server と vSphere Client は韓国語向けにローカライズされていますが、SRM はローカライズされていません。そのため、SRM サーバのメッセージの代わりに、 XXXというメッセージが表示されます。この問題を解決するには、 C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\にある enフォルダのコピーを作成します。このフォルダの名前を enから koに変更して、vCenter Server と SRM サービスを再起動してください。

• 証明書ポリシーの制限のためにサーバのペアリングが失敗すると、一般エラー メッセージが表示される

  サイト間のサーバのペアリング試行が失敗すると、 サイトのペアリングまたはペアリング解除操作に失敗しました。Details: VRM Server generic error.というエラー メッセージが表示されます。このエラーは、一方のサイトが厳密な証明書ポリシーを使用するように構成されていて、もう一方がゆるやかな証明書ポリシーを使用するように構成されている場合に発生します。このような場合にはペアリングは失敗するべきで、実際に失敗します。このような問題が発生した場合には、ゆるやかな証明書ポリシーの側を、厳密な証明書ポリシーを使用するように変更して、有効な証明書を指定してください。

• 古いバージョンの ESX で SRM 5.0 を使用すると、デバイスが恒久的に失われる可能性がある

  恒久的なデバイス損失（PDL）は、計画移行およびテスト フェイルオーバーの際に発生することがあります。SRM が ESX 5.0 ホストで実行されている仮想マシンを保護している場合には、PDL の原因となる多くの問題は適切に扱われるので、PDL は避けられます。

• 一部の SRA で、フェルオーバー中に特定のタイム ゾーンが正しく処理されない

  テストおよび実際のフェイルオーバーが、次のエラーで停止する場合があります。 Failed to create snapshots of replica devices for group 'protection-group-999' using array pair 'array-pair-999': Vmacore::SystemException "The parameter is incorrect." (87) このエラーは、ストレージ アレイから SRA へ返されるタイム ゾーンの誤った処理によるものです。1970 年 1 月 1 日より前のすべてのタイムスタンプで、この問題が発生します。詳細と回避策については、 KB 2018597 を参照してください。

• 次のメッセージでリカバリまたはテスト ワークフローが仮想マシンで失敗する。 Error - Unexpected error '3008' when communicating with ESX or guest VM: Cannot connect to the virtual machine.

  まれな状況下で、仮想マシンに対して IP のカスタマイズまたはゲスト内の呼び出しを構成するときに、このエラーが発生することがあり、リカバリ サイトのクラスタは完全自動化 DRS モードになります。予期しない vMotion は仮想マシンとの一時的な通信障害を引き起こす可能性があり、カスタマイズのスクリプト エラーが発生します。

  回避策：リカバリ プランを再実行します。エラーが解決しない場合は、リカバリ サイト クラスタ DRS を手動モードに構成し、リカバリ プランを再実行します。

• 「 Error creating test bubble image for group ...」でリカバリが失敗する。詳細な例外は、「 Error while getting host mounts for datastore: managed-object-id...」または「 The object has already been deleted or has not been completely created. 」

  テスト リカバリまたは計画済みのリカバリを実行し、特定の例外でリカバリ プランが失敗した場合、レプリケーション データの保存に使用された LUN が一時的に ESXi から切断されています。再接続すると、レプリケーションは通常どおり継続し、レプリケーション データが失われることはありません。例外は、次のようなシナリオで発生します。

  • LUN が内部 ID を変更したため、vSphere Replication が LUN を見つけることができない。
  • ターゲット データストアを含むホストが vCenter インベントリから削除されてから、追加された場合にターゲット データストアの内部 ID が変わる。

  新しい ID を更新するために手動でレプリケーションを再構成する必要があります。

  回避策：プライマリ サイトが使用できなくなった場合は、新しいデータストア管理オブジェクト ID を使って VRMS データベースを手動で更新する方法について、VMware サポートにお問い合わせください。プライマリ サイトが使用可能な場合は、以下を実行します。

  1. 失敗したリカバリ プランでクリーンアップ処理を実行します。
  2. [vSphere Replication] ビューの [仮想マシン] タブで、仮想マシンを右クリックして、 [レプリケーションの構成] を選択します。
  3. [次へ] をクリックし、 [参照] をクリックして、切断されているデータストア上のファイルの場所を変更し、再接続してから、前と同じデータストアとフォルダの場所を選択します。
  4. 既存のディスクを再利用して、仮想マシンのレプリケーションを再構成します。vSphere Replication Management Server が、vCenter Server の変更されたデータストア ID (管理されたオブジェクト ID) を取得します。
  5. 初回同期が終了するのを待ちます。この同期は既存のディスクを使用し、データ整合性を確認します。