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

お問い合わせ

VMware vCenter Site Recovery Manager 5.0.2 | 2012 年 12 月 20 日 | ビルド 919478

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

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

リリース ノートの概要

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

新機能

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

  • vSphere Replication 管理サーバは、MD5 証明書を受け入れます。「 注意と制限」を参照してください。
  • セキュリティの向上のため、OpenSSL 0.9.8m を 0.9.8t にアップグレードしました。これは、 2012 年 1 月の OpenSSL について発行されたセキュリティ報告に対処するものです。
  • 自動生成された証明書は、2048 ビットの RSA キーを使用します。
  • 「 解決した問題」 に記載されているバグ フィックス。

ローカライズ

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

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

互換性

SRM の互換性マトリックス

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

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

サポートされていて互換性のあるストレージ アレイおよび SRA の現在のリストについては、『 VMware 互換性ガイド』を参照してください。

VMware の VSA のサポート

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

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

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

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

SRM 5.0 または 5.0.1 から SRM 5.0.2 へのアップグレード

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

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

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

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

注： Microsoft は、Windows では 1024 ビット未満の RSA キーを使用する証明書が拒否されるようになるというセキュリティ アップデートを発行しています。 http://support.microsoft.com/kb/2661254 を参照してください。この標準は、2013 年末には 2048 ビットに引き上げられます。その結果、SRM 5.0.2 では、2048 ビットの RSA キーを使用する証明書が自動生成されます。SRM 5.0 および 5.0.1 では 512 ビットの RSA キーを使用した証明書が自動生成されます。SRM 5.0 または 5.0.1 から 5.0.2 にアップグレードする場合、SRM は以前のインストールからの証明書を引き継ぎます。つまり、Microsoft セキュリティ アップデートをインストールする場合は、SRM 証明書もアップグレードして、少なくとも 1024 ビット、できれば 2048 ビットの RSA キーが使用されるようにする必要があります。

  • SRM 5.0 または 5.0.1 で自動生成された証明書を使用した場合、SRM 5.0.2 にアップグレードした後、新しい 2048 ビットの証明書を生成するオプションを選択し、SRM 5.0.2 インストーラを変更モードで再度実行することで、証明書をアップグレードできます。
  • SRM 5.0 または 5.0.1 で、認証局が署名した証明書を使用していた場合は、手動で証明書をアップグレードしてインポートする必要があります。この際、少なくとも 1024 ビット、できれば 2048 ビットの RSA キーを使用していることを確認してください。

vSphere Replication 1.0 または 1.0.1 から vSphere Replication 1.0.2 へのアップグレード

SRM 5.0 には vSphere Replication 1.0 を含みます。SRM 5.0.1 は vSphere Replication 1.0.1 を含みます。SRM 5.0.2 は、vSphere Replication 1.0.2 を含みます。SRM 5.0 または 5.0.1 から SRM 5.0.2 へアップグレードしても、vSphere Replication 1.0 または 1.0.1 が vSphere Replication 1.0.2 に自動的にアップグレードされることはありません。vSphere Replication 1.0.2 は機能的には vSphere Replication 1.0 または 1.0.1 と同一ですが、バグ修正が加えられています。vSphere Update Manager を使用して VRM サーバおよび VR サーバをアップデートすることもできます。あるいは、仮想アプライアンスの管理インターフェイス（VAMI）を使用して VRM サーバおよび VR サーバのアップデートを実行することもできます。

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

VAMI を使用して VRM サーバをアップデートするには：

  1. SRM サーバとクライアントを SRM 5.0.2 へアップグレードします。
  2. VRM サーバ設定インターフェイス https:// VRM_server_address:8080 にアクセスします。
  3. VRM サーバ設定インターフェイスにルートとしてログインします。
  4. 更新 タブをクリックします。
  5. 設定 をクリックします。
  6. 指定したリポジトリを使用 を選択し、アップデート URL を リポジトリ URL テキスト ボックスに貼り付けます。
    http://vapp-updates.vmware.com/vai-catalog/valm/vmw/05d561bc-f3c8-4115-bd9d-22baf13f7178/1.0.2.0
  7. Status をクリックします。
  8. 更新のチェック をクリックします。更新チェッカーには、バージョン 1.0.2.0 が利用可能であることが示されます。
    注：VRM サーバ 5.1.0.1 を SRM 5.0.2 と使用することはできません。
  9. [更新の インストール] をクリックし、 [OK] をクリックします。
  10. 更新が終ったら、 VRM タブを選択し、 構成 をクリックし、 再起動 をクリックして VRM サーバを再起動します。
  11. リカバリ サイトで VRM サーバのプロセスを繰り返します。

VAMI を使用して VR サーバをアップデートするには：

  1. VRM サーバをアップグレードします。
  2. VR サーバ設定インターフェイス https:// VR_address:5480 にアクセスします。
  3. VR サーバ設定インターフェイスにルートとしてログインします。
  4. 更新 タブをクリックします。
  5. 設定 をクリックします。
  6. 指定したリポジトリを使用 を選択し、アップデート URL を リポジトリ URL テキスト ボックスに貼り付けます。
    http://vapp-updates.vmware.com/vai-catalog/valm/vmw/9f73d994-d8b5-11df-ace9-18a9053dae02/1.0.2.2957
  7. Status をクリックします。
  8. 更新のチェック をクリックします。更新チェッカーには、バージョン 1.0.2 が利用可能であることが示されます。
  9. [更新の インストール] をクリックし、 [OK] をクリックします。
  10. 更新が終ったら、 システム タブを選択し、 情報 をクリックし、 再起動 をクリックして VR サーバを再起動します。
  11. 保護サイトとリカバリ サイトでの両方で すべての VR サーバについてプロセスを繰り返します。

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

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

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

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

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

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

注意と制限

  • vCenter Server 5.0u2 では、ホスト OS として Windows Server 2012 をサポートしています。SRM 5.0.2 は SRM Server のホスト OS として Windows Server 2012 をサポートしていません。

  • Storage vMotion および Storage DRS との相互運用性
    ストレージ移動中の回復機能が制限される、一部の特殊なケースが存在するため、Site Recovery Manager 5.0.2 を Storage vMotion（SVmotion）と組み合わせて使用すること、またデータストア クラスタの使用を含む Storage Distributed Resource Scheduler（SDRS）と組み合わせて使用することはサポートされていません。SVMotion を使用して、保護グループにあるデータストアから保護されていないデータストアに保護された仮想マシンを移動する場合、その仮想マシンの保護を手動で再設定する必要があります。

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

  • vCloud Director との相互運用性
    Site Recovery Manager 5.0.2 は、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) と連動させて使用することはできません。

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

  • メモリ状態スナップショットを持っている仮想マシンの保護とリカバリ
    メモリ状態スナップショットを持っている仮想マシンを保護する場合、保護とリカバリ サイトの 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 管理ガイド』の「 仮想マシンの保護とリカバリにおける制限事項」を参照してください。

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

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

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

  • vSphere Replication 管理サーバでの MD5 証明書の使用
    SRM 5.0.2 および vSphere Replication 1.0.2 では、MD5 証明書を使用するように vSphere Replication 管理サーバを構成できます。ただし、MD5 証明書の署名アルゴリズムには攻撃に対する脆弱性があるため、可能であれば、証明書の署名アルゴリズムとして少なくとも SHA-1 を使用してください。SRM 5.0.2 および vSphere Replication 1.0.2 では MD5 証明書を使用できますが、できるだけ早く、証明書の署名アルゴリズムとして少なくとも SHA-1 を使用するよう、インフラの移行に着手してください。

解決した問題

SRM 5.0.2 では、次の問題が解決されています。

  • ゲスト OS の構成中に NIC プロパティ設定が適用されない

    任意の MAC アドレスに対して 2 つのアダプタが存在するときに、テストまたは実際のリカバリを実行し、NIC プロパティを構成すると、リカバリされた仮想マシンの NIC プロパティが更新されません。この問題が発生するのは、主に、任意の MAC アドレスをもつ NIC に、物理アダプタだけでなくアンチウイルス ミニポート アダプタがある場合です。この問題は修正されました。

  • vCenter サービス ステータスに、VR 管理サービスの赤色のアラートが表示される

    vSphere Replication 管理サーバ（VRM サーバ）が vCenter Server に正常に登録された後、 ホーム > vCenter サービス ステータス ビューに、vCenter Server が VRM サーバから健全性情報を取得できないというエラー メッセージ付きで、VR 管理サービスについて赤色のアラートが表示されます。この問題は修正されました。

  • ストレージの構成中にリカバリ テストが失敗する場合がある

    珍しいケースですが、SRM がストレージを構成しているときにリカバリ テストが失敗する場合があります。テスト プランには、リカバリが中断されたことが示されますが、テスト プランをキャンセルまたは削除することができません。この問題は、 KB 2020532 で説明されているように、複数の共有 raw ディスク マッピング（RDM）がある場合に発生する可能性があります。この問題は修正されました。

  • 複数のデータストアを含む保護グループの削除中に SRM が失敗する

    複数の保護グループを順次削除すると、SRM が失敗する場合があります。SRM の再起動後、同じ場所で SRM が再び失敗します。ログには、 Panic: Assert Failed: "1 == count" @ <path> /datastoreGroupData.cpp:398 というメッセージが表示されます。この問題は修正されました。

  • 保護サイト上での移行のために仮想マシンを準備している間に SRM がリカバリ中で失敗する

    保護された仮想マシンが、複数のホストで共有しているデータストア上にある場合、これらのホストが異なるデータセンター内にあると、リカバリ中の 保護サイトの仮想マシンの移行準備 のところで SRM が失敗する場合があります。ログには、 SRM Panic: Assert Failed: "ok" @ path/deactivateStorage.cpp:1170 というメッセージが表示されます。この問題は修正されました。

  • ゲスト OS で、SRM がパワーオン後のスクリプトを実行するためのリカバリされた仮想マシンへの接続を無期限に待機する

    これまでは、パワーオン後、仮想マシンのゲスト OS において SRM がスクリプトの実行を試みるためにリカバリされた仮想マシンへ接続できない場合、SRM は無期限に待機状態となっていました。今回、SRM は、リカバリされた仮想マシンへの接続を無期限に待機することはなくなりました。要求は、デフォルトで 20 秒後にタイムアウトします。このタイムアウト期間により、リカバリ テストが失敗し、 Operation timed out: 20 seconds というエラーが表示された場合、このタイムアウト期間を延ばすことができます。

    1. テキスト エディタで C:\Program Files\VMware\VMware Site Recovery Manager\config\vmware-dr.xml ファイルを開きます。
    2. 新しいタイムアウト期間を秒数で示した vixOpenVmTimeout ノードを追加します。例： 
      <connections>
<vixOpenVmTimeout>30</vixOpenVmTimeout>
</connections>
    3. SRM サービスを再起動します。
    4. 別のサイトで、SRM サーバの構成を繰り返します。

  • 初期インストール時に SRM サーバに IPv6 アドレスが使用されている場合、SRM インストールを変更できない。

    SRM サーバのインストール時に IPv6 アドレスを使用し、その後 SRM インストーラを変更モードで実行してインストールの変更を試みると、変更が失敗し、 VMware vCenter Site Recovery Manager Setup Error というエラーが表示されます。この問題は修正されました。

既知の問題

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

  • 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 管理サーバ（VRM サーバ）アプライアンスの既存のインストールをバージョン 1.0 からバージョン 1.0.1 にアップグレードする場合、VRM サーバと VR サーバのバージョン番号は仮想マシンの ［サマリ］ タブで更新されません。vCenter Server インベントリで VRM サーバまたは VR サーバを選択するときに、VRM サーバが 1.0.1 に更新されても、［サマリ］ タブに引き続きバージョン 1.0.0.0 が表示されます。VRM サーバ バージョン 1.0.1 の新しいインストールを実行する場合、［サマリ］ タブは正しいバージョン番号を表示します。

    回避策：次の手順にしたがって、VRM サーバ仮想アプライアンス管理インターフェイスのバージョン番号を確認します。

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

    あるいは、vSphere Client の VRM サーバまたは VR サーバのコンソールで、正しいバージョン番号を確認することができます。

  • vSphere Replication 管理サーバでサポートされていないデータベースを使用することができる

    vSphere Replication 管理サーバ（VRM サーバ）を設定して、サポートされていないデータベースを使用し、VRM サーバ設定はデータベース サポートに関する警告なしで正常に行うことができます。しかし、サポートされないデータベースを使用することにより、予期しない動作が起こることがあります。次のデータベースは、VRM サーバで使用するために完全にテストされサポートされています。

    • 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.2 へのアップグレード中に、データストアのオブジェクト ID が変更されているため、 srm-migration importConfig コマンドが失敗する

    SRM 5.0.2 のアップグレード プロセスはエラーなしで完了し、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 サービスを再起動してください。

  • SRM UI の [アレイ マネージャ] ビューの [デバイス] タブに重複するボリュームが表示される

    この問題は、LUN のターゲット番号が別の LUN のソース番号と同じ場合に発生します。これは、UI の問題であり、テストまたは実際のリカバリには影響はありません。

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