VMware vCenter Site Recovery Manager 5.0.1 リリース ノート

お問い合わせ

VMware vCenter Site Recovery Manager 5.0.1 | 2012 年 3 月 15日 | ビルド 633117

最終更新日： 2016 年 3 月 9 日

これらのリリース ノートへの追加や更新を確認してください。

リリース ノートの概要

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

新機能

VMware vCenter Site Recovery Manager 5.0.1 では、以下の改良が行われています。

  • 強制フェイルオーバー。保護サイトでストレージ アレイに障害が発生し、結果として保護されている仮想マシンが管理不能になり、シャットダウン、電源オフ、登録解除ができなくなった場合に、仮想マシンをリカバリできるようにします。
  • 「 解決した問題」 に記載されているバグ フィックス。

ローカライズ

VMware vCenter Site Recovery Manager 5.0.1 は、以下の言語で利用できます。

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

互換性

SRM の互換性マトリックス

現在の相互操作性および製品互換性に関する詳細は、『 VMware vCenter Site Recovery Manager の互換性マトリックス』を参照してください。

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

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

VMware の VSA のサポート

vSphere Storage Appliance (VSA) に常駐する仮想マシンは、vSphere Replication (VR) を使用して、SRM 5.0.1 により保護できます。VSA は SRM 5.0.1 と連動するストレージ レプリケーション アダプタ (SRA) を必要としません。

インストールとアップグレード

SRM 5.0.1 は、アレイベースのレプリケーションを使用する場合のみ、ESXi Server 4.0 と 4.1 および Virtual Infrastructure 3.5 で実行できます。vSphere Replication を単独として、またはアレイベースのレプリケーションと連動して使用する場合、アップグレード プロセスの一部として、ESXi Server ホストをバージョン 5.0 または ESXi Server 5.0 update 1 にアップグレードする必要があります。

前のバージョンからのアップグレードなしで SRM 5.0.1 をインストールする場合、『 Site Recovery Manager 管理者ガイド 』の「 Site Recovery Manager のインストールとアップグレード」を参照してください。

SRM 5.0 から SRM 5.0.1 へのアップグレード

SRM 5.0 から SRM 5.0.1 への in-place アップグレードを実行できます。VMware はフレッシュ インストールよりも in-place アップグレードをお勧めします。これにより、すべての履歴レポート、リカバリ プラン、保護グループ、およびリカバリ プランのカスタマイズを保持できるためです。保護サイトとリカバリ サイトの両方でアップグレード手順を実行する必要があります。

  1. 保護サイトで SRM Server を実行中のマシンにログインします。
  2. データベース ソフトウェアが提供するツールを使用して、SRM データベースをバックアップします。
  3. VMware-srm-5.0.1- buildnumber.exe をダウンロードして実行します。
  4. SRM をアップグレードすることを確認するメッセージが表示されたら、 はい をクリックします。
  5. 前の SRM インストールからの設定を使用して SRM 5.0.1 をインストールするためには、[ 次へ] をクリックします。
  6. SRM データベースをバックアップしたことを確認するメッセージが表示されたら、 はい をクリックします。
  7. 処理が完了したら、 終了 をクリックします。
  8. リカバリ サイトでアップグレード処理を繰り返します。

SRM サーバをアップグレードした後で、SRM クライアント プラグインを再インストールする必要があります。

  1. SRM 5.0 クライアント プラグインをアンインストールします。
  2. vSphere Client インスタンスにログインして、SRM サーバが接続されている vCenter Server に接続します。
  3. プラグイン > プラグインの管理 を選択します。
  4. [ ダウンロードとインストール] をクリックして、SRM 5.0.1 クライアント プラグインをインストールします。
  5. プラグインのインストールが完了したら、SRM にログインして、前のバージョンの設定が保持されていることを確認してください。
  6. SRM サーバに接続するために使用するすべての vSphere Client インスタンスのプロセスを繰り返します。

vSphere Replication 1.0 から vSphere Replication 1.0.1 へのアップグレード

SRM 5.0 には vSphere Replication 1.0 を含みます。SRM 5.0.1 は vSphere Replication 1.0.1 を含みます。SRM 5.0 から SRM 5.0.1 へのアップグレードは、自動的に vSphere Replication 1.0 を vSphere Replication 1.0.1 にアップグレードしません。vSphere Replication 1.0.1 は機能的には vSphere Replication 1.0 と同一ですが、バグ修正が加えられています。

SRM 5.0.1 を vSphere Replication 1.0 で実行できますが、vSphere Replication をバージョン 1.0.1 にアップグレードして、バージョン 1.0.1 のバグ修正を利用することができます。vSphere Replication Management Server（VRM サーバ）と vSphere Replication（VR）Server を個別にアップグレードします。

重要： VAMI の 更新 > 設定 でオプションを選択して vSphere Replication を自動更新しないでください。自動更新を選択した場合、vSphere Replication は VAMI によって最新の 5.x バージョンに更新され、SRM および vCenter Server 5.0.x と互換性がなくなります。更新設定は 自動更新無効 のままにしてください。

VRM サーバのアップグレード:

  1. SRM サーバとクライアントの SRM 5.0.1 へのアップグレード。
  2. VRM サーバ設定インターフェイス https:// VRMS_IP_address:8080 にアクセスします。
  3. VRM サーバ設定インターフェイスにルートとしてログインします。
  4. 更新 タブを選択します。
  5. 更新のチェック をクリックします。更新チェッカーには、バージョン 1.0.1 が利用可能であることが示されます。
  6.  [ 更新のインストール] をクリックします。
  7. [ VRM] > [ 構成] タブを選択し、[VRM Server ステータス] の下の [ 再起動] ボタンをクリックして、VRM Server を再起動します。
  8. リカバリ サイトで VRM サーバのプロセスを繰り返します。

VR サーバのアップグレード:

  1. VRM サーバをアップグレードします。
  2. VR サーバ設定インターフェイス https:// VR_IP_address:5480 にアクセスします。
  3. VR サーバ設定インターフェイスにルートとしてログインします。
  4. 更新 タブを選択します。
  5. 更新のチェック をクリックします。更新チェッカーには、バージョン 1.0.1 が利用可能であることが示されます。
  6. [ 更新 のインストール] をクリックします。
  7. [ システム] を選択し、[ 情報] タブで [ 再起動] ボタンをクリックして、VR サーバを再起動します。
  8. リカバリ サイトで VR サーバのプロセスを繰り返します。

SRM 4.1.2 から SRM 5.0.1 へのアップグレード

SRM 4.1.2 から SRM 5.0.1 への in-place アップグレードを実行できます。VMware はフレッシュインストールよりも in-place アップグレードをお勧めします。これにより、すべての履歴レポート、リカバリ プラン、保護グループ、およびリカバリ プランのカスタマイズを保持できるためです。SRM クライアントを 5.0.1 にアップグレードするには、まず SRM 4.1.2 クライアントをアンインストールする必要があります。

注: SRM 4.1 または SRM 4.1.1 から SRM 5.0.1 へのアップグレードはサポートされていません。

SRM 4.1.2 から SRM 5.0.1 へアップグレードするためには、『 Site Recovery Manager 管理ガイド 』の「 SRM のアップグレード」に記載されている SRM 4.1 または 4.1.1 から SRM 5.0 へのアップグレード手順に従ってください。  SRM 5 アップグレード プロセスのブログも参照してください。

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

vCenter Site Recovery Manager 5.0.1 で配布されるオープン ソース ソフトウェア コンポーネントに適用される著作権に関する記述とライセンスは、 SRM ダウンロード サイト にあります。また、vCenter Site Recovery Manager の一般リリースの最新版で利用できるソースコードへの変更やソースコードを要求する GPL、LGPL、あるいはその他の同等のライセンスに対するソースファイルをダウンロードすることもできます。

注意と制限

  • Storage vMotion と Storage DRS との相互操作性
    ストレージ移動中にリカバリ機能が損なわれる一部の特定の限定された事例のために、Site Recovery Manager 5.0.1 は Storage vMotion (SVmotion) と共に使用することはサポートされておらず、データベース クラスタの使用を含む Storage Distributed Resource Scheduler (SDRS) での使用もサポートされていません。SVMotion を使用して、保護グループにあるデータストアから保護されていないデータストアに保護された仮想マシンを移動する場合、その仮想マシンの保護を手動で再設定する必要があります。

  • ネットワーク アドレス変換 (NAT) は SRM でサポートされていません
    vSphere レプリケーションを構成するときに、保護された vSphere レプリケーション管理サーバ（VRMS）とリカバリ VRM サーバの両方に見える IP アドレスをもつ vSphere レプリケーション サーバ（VR サーバ）を設定する必要があります。

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

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

  • 特定の vSphere 機能と RDM は vSphere レプリケーションでサポートされていません
    vSphere レプリケーションを vSphere Fault Tolerance、仮想マシン テンプレート、リンク クローン、または物理的な Raw ディスク マッピング (RDM) と連動させて使用することはできません。

  • メモリ状態スナップショットを持っている仮想マシンの保護とリカバリ
    メモリ状態スナップショットを持っている仮想マシンを保護する場合、保護とリカバリ サイトの ESX ホストでは VMware ナレッジベース記事『 VMotion CPU Compatibility Requirements for Intel Processors』および『 VMotion CPU Compatibility Requirements for AMD Processors』に記載されている通り、互換性のある CPU を装備していなければなりません。また、ホストでは同じ BIOS 機能が有効になっている必要があります。サーバの BIOS 構成が一致しない場合は、それ以外が同一であっても互換性のエラー メッセージが引き続き表示されます。チェックすべき最も一般的な二つの機能は、非実行メモリ保護（NX または XD）と仮想テクノロジー（VT または AMD-V）です。スナップショットを持っている仮想マシンの保護とリカバリを行うことの制限については、『 Site Recovery Manager 管理ガイド』の「 仮想マシンの保護とリカバリにおける制限事項」を参照してください。

  • vSphere Replication との相互運用性
    vSphere Replication は、2032GB の最大ディスク容量をサポートします。

  • SRM サーバ インスタンスごとのリカバリ プランの最大数
    SRM サーバ インスタンスごとに次の数までリカバリ プランを作成できます。

    • アレイベース レプリケーション：150 個のリカバリ プラン
    • vSphere レプリケーション：250 個のリカバリ プラン

    同時に実行できるリカバリ プランの数やその他の SRM の操作上の制限については、『 Site Recovery Manager 管理ガイド』を参照してください。

解決した問題

  • 計画移行のために 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 ターゲットをサポートしている場合には、この現象が発生する可能性が高くなります。これは、今回修正されました。

  • クリーンアップが高速すぎる SRM タスクは ManagedObjectNotFound 例外を発生させます

    SRM タスクは vmware-dr サービスから、タスクが完了してから 1 分後に削除されます。SRM が削除されているタスク オブジェクトを参照する場合、 ManagedObjectNotFound 例外を返し、エラー メッセージ 「オブジェクトがすでに削除されているか、その作成が完全ではありません」が表示されます。クリーンアップ タスクのデフォルト時間は 1 分です。この動作を経験した場合、 config.xml ファイルの Topology.drTaskCleanupTime パラメータを設定してクリーンアップ時間を構成できます。

    <topology>
    <drTaskCleanupTime>300</drTaskCleanupTime>
    </topology>

  • CPU ごとのライセンス数が間違っています

    SRM 1.x や SRM 4.0 を購入した一部のお客様は、引き続き CPU ごとに割り当てられたライセンスを使用している場合があります。これらのお客様は引き続き、CPU ごとのライセンスを使用して SRM 5.0.1 の操作ができます。SRM 5.0 では、使用されている CPU ライセンスの数をカウントする公式は非常に寛大です。変換が誤って、SRM 5.0 に対して多すぎる CPU ごとのライセンスを付与してしまうことが、このシナリオでも起こりえます。これは、SRM 5.0.1 で修正され、ライセンスが不足すると、より厳密な警告が発せられます。

  • 2 つのディスク パーティションにまたがるレプリケートされたデータストアの仮想マシンを保護すると、SRM は予期せずに停止したり、再起動できなくなります

    同じデバイス上で 2 個のディスク パーティションにまたがるレプリケートされたデータストアに含まれる仮想マシンを保護する場合、SRM はデータストア グループを再計算する間に予期せずに停止します。SRM ログは次のエラーを示します。 Panic:Assert Failed:"ok" @ d:\build\ob\bora-474459\srm\public\persistence/saveLoadUtils.h:329次に、SRM サーバの再起動が失敗します。この問題は修正されました。

  • ネットワーク通信の中断が起こると、それが短い場合でも、SRM サーバが永久に待機する場合があります

    保護およびリカバリ サイトの間のネットワーク通信が中断された時間が 5 分以内であっても、SRM サーバは反応しなくなることがあります。この問題は SRM サーバの更新結果がないことや、ネットワーク中断中のリモート サイトからのサーバ側の waitforupdate コールにおけるタイムアウトにより生じます。この問題は、 waitforupdate コールにクライアント側のタイムアウトを導入することにより修正されました。デフォルトのクライアント側のタイムアウトは 5 分間です。

  • テストとリカバリを再度有効にしている間に、ホストの再スキャンが繰り返されました

    SRM 4.1 には設定オプション storageProvider.hostRescanCnt があり、テストとリカバリ中に繰り返しホストをスキャンできるようにします。このオプションは SRM 5.0 にはありませんでしたが、SRM 5.0.1 では [ 詳細設定] メニューで復帰しました。[ サイト] ビューのサイトを右クリックし、[ 詳細設定]、[ storageProvider] を順に選択してください。 KB 1008283 を参照してください。

  • カスタマイズの仕様は Red Hat Enterprise Linux 5.x のゲートウェイを設定しません

    Red Hat Enterprise Linux 5.x 仮想マシンのイメージ カスタマイズは、ゲートウェイを適切に設定しませんでした。結果として、ユーザーがカスタマイズ中に新しいゲートウェイをリカバリ中の RHEL 5.x 仮想マシンに割り当てた場合、新しいゲートウェイ エントリが /etc/sysconfig/network-scripts/route-ethX ファイルに追加されます。RHEL ネットワーク サービスは、保護サイトの古いゲートウェイ設定であるそのファイルの最初のエントリを選択し、ユーザーがカスタマイズ中に指定したゲートウェイの変更は選択しません。この問題は修正されました。

  • リカバリ プランの誤ったコンテキストに関するエラーで中断した後、リカバリ SRM サーバは予期せずに停止しました

    保護およびリカバリ サイトの両方の中断後、リカバリ側の SRM サーバを再起動したときに予期せずにエラー CreateRemoteSuspendVmListViewAndCallback on plan Recovery Plan on wrong context で停止しました。この問題は修正されました。

  • vSphere レプリケーションの設定で、vCenter Server アプライアンスに簡体中国語の SRM を使用するときに、無効なロケール エラーが発生します

    vCenter Server アプライアンスに簡体中国語の SRM を使用する場合、仮想マシンの vSphere レプリケーションを設定しようとすると、無効なロケール エラーで失敗します。この問題は修正されました。

  • SRM は CPU ライセンスの使用のチェックを開始した後に起動中に予期せずに停止します

    特定の状況では、SRM は CPU のライセンス使用をチェックするときに起動中に予期せずに、エラー Unexpected Object in results:vim.VirtualMachine で停止します。この問題は修正されました。

  • 修復モードで SRM インストーラーを実行すると、exportConfig.xml ファイルが削除されます

    SRM 4.1.x から 5.0.x への in-place アップグレードは、ファイル exportConfig.xml を作成します。これにはインベントリ マッピング、データストア マッピング、保護された仮想マシンとグループ、リカバリ プランなどの詳細が含まれます。このファイルを使用して、アップグレード後にデータを SRM データベースに移行できます。しかし、データベースにデータを移行する前に SRM インストーラーを修復モードで実行する場合、インストーラーは exportConfig.xml を削除します。この問題は修正され、インストーラーを修復モードで実行しても exportConfig.xml ファイルは削除されなくなりました。

  • 仮想マシンの IP カスタマイズがエラー コード 14010 で失敗します

    仮想マシンの IP カスタマイズが VMware に固有でないアダプタを設定しようと試みた時、 There was an error in communication' Error Code: '14010' で失敗します。この問題は修正され、IP カスタマイズはデフォルトでないネットワーク アダプタをスキップし、物理アダプタのみを設定するようになりました。

  • SRA が複数のストレージ デバイスから重複したスナップショット ID を取得した場合、テスト リカバリが失敗する場合があります

    テスト リカバリの実行は次のエラーで失敗する場合があります. Panic:Assert Failed:"runtimeInfo._results != 0 (Missing results in plan:recovery-plan-10257)" @ d:/build/ob/bora-474459/srm/src/recovery/engine/manager.cpp:1300^Mこの問題はストレージ レプリケーション アダプタ (SRA) が異なるストレージ デバイスでスナップショット ID の重複を許可するが、SRM は固有のスナップショット ID を要求するため、発生します。この問題はテスト リカバリにのみ影響し、実際のリカバリには影響しません。この問題は修正され、SRM は重複したスナップショット ID を受け付けるようになりました。

  • 複数のネットワーク オプションを使用できる場合、リカバリ プランのためのネットワーク リストを下方へスクロールできません

    SRM 環境で 30 以上のネットワークが使用できる場合、リカバリ プランを作成するときに選択できるネットワークの完全なリストは表示できません。この問題は修正され、完全なリストを下方へスクロールできるようになりました。

既知の問題

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

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

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

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

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

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

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

    完全同期は ESX により開始されるので、この問題の解決には ESX のアップデートが必要です。このような同期が行われると、保護サイトとリカバリ サイト両方のディスクで余分の I/O が発生します。これにはたいてい Recovery Point Objective（RPO）よりも長い時間がかかるので、RPO ターゲットが失われる結果になります。この問題は、ESXi Server 5.0 には存在しますが、ESXi Server 5.0 update 1 で修正されています。

    回避策：ESXi Server をバージョン 5.0 update 1 にアップグレードしてください。

  • LVM.enableResignature を 1 に設定すると、テストのフェイルオーバー後も設定されたままになる

    SRM は LVM.enableResignature フラグが 0 に設定されている ESX 環境をサポートしません。SRM はテスト フェイルオーバーまたは実際のフェイルオーバー中に、フラグが設定されていない場合は、自動的に LVM.enableResignature を 1 に設定します。SRM はこのフラグを再署名スナップショット ボリュームに設定し、それらをリカバリするために ESX ホストにマウントします。操作が完了すると、フラグは 1 にセットされたままになります。詳細については、 KB 2010051 を参照してください。

  • 構成中に Error committing the transaction を受け取った後では仮想マシンの vSphere レプリケーションを再設定できない

    Error committing the transaction というメッセージを仮想マシンのレプリケーションの構成中に受け取った場合、仮想マシンのレプリケーションを再設定する試みは失敗します。この問題は、vSphere レプリケーションが設定の試みの後に正しく設定データをクリーンアップしないために起こります。結果として、仮想マシンのレプリケーションは vSphere レプリケーションは設定されていないにも関わらず設定されているように見えます。

    回避策：設定データを正しくクリーンアップするためには、コマンド行で仮想マシンのレプリケーションを無効にしてください。

    1. ESXi コンソールにログインします。
    2. コマンドを実行して ESXi ホストで仮想マシンの ID を検索します。 
      # vim-cmd vmsvc/getallvms | grep 
virtual_machine_name
      仮想マシン ID は最初の列の数値です。
    3. コマンドを実行して前のステップで見つけた ID をもつ仮想マシンのレプリケーションを無効にします。 
      # vim-cmd hbrsvc/vmreplica.disable 
virtual_machine_ID
  • 強制フェイルオーバー チェックボックスが計画された移行をもとに戻した後で選択されたままになる

    強制フェイルオーバー オプションを選択してリカバリ プランを実行し、 計画済みの移行 を選択することにより、計画された移行に戻る場合、強制フェイルオーバー チェックボックスが選択されたままになり、［リカバリ プランの実行（Run Recovery Plan）］ウィザードでグレイアウトされます。この問題はユーザー インターフェイスにのみ影響し、SRM は正しい動作を実行します。

    回避策：強制されたフェイルオーバー オプションの選択を解除した後で、[リカバリ プランの実行] ウィザードを閉じて再度開きます。

  • プレースホルダ データストアが保護されたクラスタのすべてのホストで見えない場合、リカバリまたは移行操作が失敗する場合がある

    リカバリと移行中に、プレースホルダ仮想マシンがリカバリされた仮想マシンで置き換えられます。リカバリ サイトに複数のホストをもつクラスタがある場合、すべてのプレースホルダ データストアはクラスタのすべてのホストで使用可能にする必要があります。そうしないと、仮想マシンのスワップが失敗します。SRM では、クラスタのすべてのホストで使用できないプレースホルダ データストアを選択しないですみません。プレースホルダ データストアがすべてのホストで見えない場合、リカバリ プランはエラー Error - Unable to access file [datastore]" Unable to access file [datastore] Failed to unregister protected VMs で失敗します。ホストはプレースホルダー仮想マシンとリカバリ仮想マシンの両方を含むデータストアにアクセスできなければなりません。

    回避策：プレースホルダー仮想マシンとリカバリ仮想マシンの両方のデータストアが、保護されたクラスタのすべてのホストに見えることを手動で確認してください。

  • VRM サーバと VR サーバのバージョンはアップグレード後に仮想マシン サマリで更新されません

    vSphere Replication Manager Server (VRMS) アプライアンスの既存のインストールをバージョン 1.0 からバージョン 1.0.1 にアップグレードする場合、VRM サーバと VR サーバのバージョン番号は仮想マシンの［サマリ］タブで更新されません。vCenter Server インベントリで VRM サーバまたは VR サーバを選択するときに、VRM サーバが 1.0.1 に更新されても、［サマリ］タブに引き続きバージョン 1.0.0.0 が表示されます。VRM サーバ バージョン 1.0.1 の新しいインストールを実行する場合、［サマリ］タブは正しいバージョン番号を表示します。

    回避策：以下の手順に従って、VRMS 仮想アプライアンス管理インターフェイスのバージョン番号をチェックします。

    1. https:// VRMS_IP_address:8080 にログインします。
    2. 更新 タブを選択します。
    3. Status をクリックします。バージョン番号は 1.0.1.0 です。

    代わりに、vSphere Client の VRM サーバまたは VR サーバのコンソールに正しいバージョン番号が表示されます。

  • vSphere Replication Management Server でサポートされていないデータベースを使用することが可能です

    vSphere Replication Management Server (VRMS) を設定して、サポートされていないデータベースを使用し、VRMS 設定はデータベース サポートに関する警告なしで正常に行うことができます。しかし、サポートされないデータベースを使用することにより、予期しない動作が起こることがあります。以下のデータベースは、VRMS で使用するために完全にテストされサポートされています。

    • SQL Server 2005 SP4 64 ビット版
    • SQL Server 2008 R2 SP1 64 ビット版
    • SQL Server 2008 R2 64 ビット版

  • 一部の 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 を参照してください。

  • SRM 4.1.2 から SRM 5.0.1 へのアップグレード中に、データストアのオブジェクト ID が変更されているため、 srm-migration importConfig コマンドが失敗する

    SRM 5.0.1 のアップグレード プロセスはエラーなしで完了し、vCenter Server が再起動されます。また、ホスト、ゲストおよびストレージはすべて、vCenter Server サービスが停止した時点と同じ状態でオンラインとなります。しかし、SRM の移行中、次のエラーが出て保護グループのインポートに失敗します。

    Skipping VM protection for all VMs in group ( group) due to an error: One or more datastores are either already protected in a different group or not currently replicated.

    SRM exportConfig.xml ファイルにリストされたデータストアのオブジェクト ID が MOB ブラウザに表示される同じデータストアのオブジェクト ID と異なっています。この問題は、 KB 2007404 で説明されている問題に関連するものです。

    回避策：MOB ブラウザからデータストアのオブジェクト ID を使用するよう、 exportConfig.xml を編集し、 srm-migration importConfig コマンドを再度実行します。

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

    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 サービスを再起動してください。

  • 次のメッセージでリカバリまたはテスト ワークフローが仮想マシンで失敗する。 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. 初回同期が終了するのを待ちます。この同期は既存のディスクを使用し、データ整合性を確認します。