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

お問い合わせ

VMware vCenter Site Recovery Manager 5.0.3.3a | 2016 年 4 月 7 日

VMware vCenter Site Recovery Manager 5.0.3.3 | 2015 年 10 月 29 日| ビルド 3022051

VMware vCenter Site Recovery Manager 5.0.3.2 | 2014 年 7 月 22 日 | ビルド 1964819

VMware vCenter Site Recovery Manager 5.0.3.1 | 2014 年 5 月 29 日 | ビルド 1848414

VMware vCenter Site Recovery Manager 5.0.3 | 2013 年 10 月 17 日 | ビルド 1344912

最終更新日：2016 年 4 月 7 日

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

Site Recovery Manager 5.0.3.x パッチ リリースの詳細（vSphere Replication の必要なパッチの詳細を含む）については、対応するナレッジ ベースの記事を参照してください。

リリース ノートの概要

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

新機能

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

ローカライズ

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

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

互換性

SRM の互換性マトリックス

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

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

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

VMware の VSA のサポート

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

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

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

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

SRM 5.0.x から SRM 5.0.3 へのアップグレード

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

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

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

  1. 前のバージョンから SRM クライアント プラグインをアンインストールします。
  2. vSphere Client インスタンスにログインして、SRM Server が接続されている vCenter Server に接続します。
  3. プラグイン > プラグインの管理 を選択します。
  4. [ダウンロードとインストール] をクリックして、SRM 5.0.3 クライアント プラグインをインストールします。
  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.3 にアップグレードする場合、SRM は以前のインストールからの証明書を引き継ぎます。つまり、Microsoft セキュリティ アップデートをインストールする場合は、SRM 証明書もアップグレードして、少なくとも 1024 ビット、できれば 2048 ビットの RSA キーが使用されるようにする必要があります。

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

vSphere Replication 1.0.x から vSphere Replication 1.0.3 へのアップグレード

SRM 5.0 ～ 5.0.2 のリリースには、vSphere Replication 1.0 ～ 1.0.2 が含まれます。SRM 5.0.3 には、vSphere Replication 1.0.3 が含まれます。SRM 5.0、5.0.1、または 5.0.2 から SRM 5.0.3 へアップグレードしても、vSphere Replication 1.0、1.0.1、または 1.0.2 は vSphere Replication 1.0.3 に自動的にアップグレードされません。vSphere Replication 1.0.3 は機能的には vSphere Replication 1.0.2 と同一ですが、バグ修正が加えられています。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 Server とクライアントを SRM 5.0.3 へアップグレードします。
  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.3.0
    注： vSphere Replication 1.0.3.x パッチ リリースの VAMI のアップグレード URL を入手するには、対応する Site Recovery Manager 5.0.3.x パッチ リリースのナレッジ ベースの記事を参照してください。
  7. Status をクリックします。
  8. 更新のチェック をクリックします。更新チェッカーには、バージョン 1.0.3.0 が利用可能であることが示されます。
  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.3.4117
    注： vSphere Replication 1.0.3.x パッチ リリースの VAMI のアップグレード URL を入手するには、対応する Site Recovery Manager 5.0.3.x パッチ リリースのナレッジ ベースの記事を参照してください。
  7. Status をクリックします。
  8. 更新のチェック をクリックします。更新チェッカーには、バージョン 1.0.3 が利用可能であることが示されます。
  9. [更新の インストール] をクリックし、 [OK] をクリックします。
  10. 更新が終ったら、 システム タブを選択し、 情報 をクリックし、 再起動 をクリックして VR サーバを再起動します。
  11. 保護サイトとリカバリ サイトでの両方で すべての VR サーバについてプロセスを繰り返します。

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

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

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

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

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

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

注意と制限

  • ESXi Server 5.0 は、Windows 8 または Windows Server 2012 を実行する仮想マシンのゲスト OS のカスタマイズをサポートしていない
    Windows 8 および Windows Server 2012 仮想マシンでのゲスト OS のカスタマイズのサポートは ESXi Server 5.0 u2 以降で使用できます。ESXi Server 5.0.x を保護サイトで実行し、ESXi Server 5.0 をリカバリ サイトで実行する場合、リカバリ サイトの ESXi Server 5.0 が Windows 8 または Windows Server 2012 の起動プロセスを完了できないため、テスト リカバリおよび実際のリカバリは失敗します。リカバリ サイトの仮想マシンでは Windows のログイン画面が表示されません。VM Tools がパワーオン中にタイムアウトしたことを知らせるリカバリ手順のエラー メッセージが、IP カスタマイズの手順の前に SRM に表示されます。

    回避策：リカバリ サイトの ESXi Server をバージョン 5.0 u2 以降にアップグレードします。

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

  • ネットワーク アドレス変換 (NAT) は SRM Server または vSphere Replication サーバでサポートされない
    SRM を構成するときに、SRM Server を、ペアとなる対応する SRM Server で認識される IP アドレスで構成する必要があります。「 NAT is not a supported configuration in SRM」を参照してください。

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

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

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

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

  • メモリ状態スナップショットを持っている仮想マシンの保護とリカバリ
    メモリ状態スナップショットを持っている仮想マシンを保護する場合、保護とリカバリ サイトの 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 5.0.x の操作の限界については、『 Site Recovery Manager 管理ガイド』を参照してください。

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

  • デフォルトの vCenter Server 証明書の署名アルゴリズムは、SHA256RSA です。Windows Server 2003 は SHA256RSA をサポートしていません。Windows Server 2003 に SRM 5.0.3 をインストールするには、次の手順のいずれか 1 つを実行する必要があります。

    • 次の Microsoft のホット フィックスのうち、いずれか 1 つをインストールします。
    • SRM Server のホストのオペレーティング システムを Windows Server 2008 以降にアップグレードします。
    • vCenter Server の証明書に SHA1RSA を使用していることを確認します。vCenter Server 証明書に SHA1RSA を使用しない場合は、証明書をアップグレードするか、vCenter Server および SRM をバージョン 5.5 にアップグレードする必要があります。

解決した問題

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

  • New: Site Recovery Manager 5.0.3.3a Patch Release でリモート コードの実行が許可される glibc の脆弱性問題が解決される

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

    Site Recovery Manager 5.0.3.3a Patch Release のインストール方法については、 http://kb.vmware.com/kb/2144832 を参照してください。

  • SRM Server インストールを変更または修正する場合、ユーザーが管理者であるか、または UAC を無効にする必要がある。

    管理者グループのメンバーではあるが管理者ではない場合、Windows のユーザー アカウント制御 (UAC) を無効にしてから、Windows のコントロール パネルから SRM Server のインストールを変更または修正する必要があります。Windows Server 2012 のホストに SRM Server をインストールしている場合、レジストリを変更して UAC を無効にします。この問題は修正されました。

  • ホストが切断されている場合に計画移行を実行すると、SRM サービスが予期せず停止する。

    ESXi ホストが vCenter Server から切断されている場合に計画移行を実行すると、SRM サービスがリカバリ プランの Set volume as read-only 手順で予期せず停止することがあります。この問題は修正されました。

  • 「Cannot find replicated datastore due to timeout of HBA rescan operation」というエラーでタイムアウトが発生する。

    この問題は修正され、エラーの検出およびホスト再スキャン操作中のタイムアウトのエラー メッセージが改善されました。

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

    この問題は、LUN のターゲット番号が別の LUN のソース番号と同じ場合に発生します。この UI の問題は修正されています。

  • Windows Server 2012 ドメイン コントローラ (DC) の仮想マシンをリカバリすると、DC の保護メカニズムが破損する。

    アレイベース レプリケーションまたは vSphere Replication を使用することで、Windows Server 2012 DC 仮想マシンのリカバリが可能です。ただし、このような仮想マシンでリカバリ操作を実行すると、Windows Server 2012 DC の保護メカニズムの障害につながる可能性があります。この問題は修正されました。

  • リカバリまたはテスト リカバリ中に IP カスタマイズが失敗する。

    リカバリ プランのリカバリまたはテスト リカバリの実行時に、一部またはすべての仮想マシンに対する IP カスタマイズが次のいずれかの理由で失敗します。

    • 一時フォルダのパスを変更した一部の Windows 仮想マシンでは、IP カスタマイズが間違っている結果ログの場所を参照してしまいます。詳細は、 KB 2021083 を参照してください。この問題は修正されました。
    • Windows 仮想マシンの IP カスタマイズの実行中、中間結果ログにアクセスできない場合は、カスタマイズは正常に終了しますが、レポートには次のエラーが記録されます。 Error - Cannot complete customization, possibly due to a scripting runtime error or invalid script parameters (Error code: -1).IP settings may have been partially applied。この問題は修正されました。IP カスタマイズは正常終了を正しく報告するようになりました。
  • リカバリ サイトでデータストアを再スキャンすると、ストレージ デバイスの準備ができていないために失敗する。

    SRA は、リカバリ サイトの昇格ストレージ デバイスが ESXi ホストに対して利用可能な状態となる前に、応答を SRM に送信できます。SRM は、SRA から応答を受信すると、ストレージ デバイスの再スキャンを実行します。ストレージ デバイスの準備がまだ完了していない場合、ESXi Server ではそれらが検出されず、SRM では再スキャンを実行したときにレプリケートされたデバイスが見つかりません。データストアは作成されず、リカバリされた仮想マシンは見つかりません。

    回避策：データストアが利用できないことで問題がある場合は、SRM 5.0.3 により新しい設定が提供され、SRA がストレージ デバイスを昇格させた後の再スキャンの開始を遅延させることができます。

    1. SRM サイトを右クリックし、[ 詳細設定] を選択します。
    2. storageProvider をクリックします。
    3. storageProvider.hostRescanDelaySec パラメータを設定し、秒単位でストレージの再スキャンの開始を遅延させます。適切な値は 20 から 180 です。
    4. SRM サービスを再起動します。

    注: 前のリリースでは、 storageProvider.hostRescanRepeatCnt パラメータを使用してリカバリの遅延を設定していた可能性があります。その代りに、新しい storageProvider.hostRescanDelaySec パラメータを使用してください。

  • カスタマイズしたリカバリ手順では、仮想マシンが停止されず、IP のカスタマイズの前にパワーオンされる。

    テスト リカバリで「書き込み可能なストレージのスナップショットを作成」手順の後に、または実際のリカバリで「リカバリ サイトのストレージを書き込み可能に変更」手順の後にカスタマイズしたリカバリ手順を挿入した場合、および仮想マシンの IP がカスタマイズされるように構成した場合、リカバリ プランはカスタム リカバリ手順が完了するのを待たずに仮想マシンをパワーオンします。この問題は修正されました。

  • SRM が Already Mounted というエラーを表示して VMFS ボリュームのマウントに失敗する。

    SRM が vCenter Server からの情報の取得に失敗すると、SRM は仮想マシンを含むボリュームがマウントされていないと表示します。しかし、同時に ESXi Server はボリュームを正常にマウントしています。SRM は vCenter Server からの以前の情報に基づいてマウントを試み、ボリュームが無効な状態にあると表示し、すでにマウントされていると警告します。この問題は修正されました。

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

    リカバリ プランを継続できなくなった場合、ユーザーはリカバリ プランの再実行を選択することができます。まれな例ですが、リカバリ プランを再実行すると、SRM Server が予期せず停止することがあります。SRM Server を再起動すると、リカバリ プランが継続し、サーバが予期せず停止します。ログは、SRM Server が停止する直前に変更した仮想マシンを、ログ エントリ IP customization succeeded for VM VM Nameで示します。この問題は修正されました。

  • 仮想マシンの保護中、ライセンス マネージャを確認した後に SRM サービスが停止する。

    仮想マシンの保護を構成すると、SRM Server が予期せずに停止します。ログには次のようなエラーが含まれます。 Panic: Assert Failed: "found == _reservations.get<by::vm>().end() (There is already a Reservation for VM [vim.VirtualMachine: virtual_machine]）".この問題は修正されました。

  • VCVA でカスタム証明書を使用すると、SRM Server のペアリングに失敗する。

    SRM Server 用のカスタム証明書および vCenter Server 仮想アプライアンス を使用して SRM Server をペアリングすると、エラー Permission to perform this operation was denied で失敗します。この問題は修正されました。

  • Windows Server 2012 に SRM 5.0.2 をインストールできない。

    SRM Server 5.0.2 を Windows Server 2012 にインストールできませんでした。この問題は修正され、SRM 5.0.3 は SRM Server のホスト OS として Windows Server 2012 をサポートします。

  • 仮想マシンが vApp の一部である場合、SRM は RDM ディスクを 1 つ以上持つ仮想マシンを保護できない。

    仮想マシンが vApp の一部で、RDM ディスクを使用している場合、保護を構成すると、保護ステータスに Device Not found: Hard Disk X というエラーが表示されます。このエラーで、 Hard Disk X は仮想マシンに接続された RDM ディスクです。この問題は修正されました。

  • テスト クリーンアップ中に SRM Server が予期せず停止する。

    まれな状況ですが、テスト クリーンアップ中に SRM Server が「 Panic: Assert Failed: .../srm/src/replication/providers/storageProvider/data/groupPostFailoverInfoData.cpp:108」のエラーで予期せず停止することがあります。この問題は修正されました。

  • ローカライズされた Windows ゲスト OS が SRM Server にメッセージを送信すると SRM が予期せず停止する。

    この問題は、SRM Server が日本語、韓国語、中国語ロケールの Windows オペレーティング システムで実行され、vCenter Server が英語のロケールで実行されている場合に発生します。たとえば、パワーオン後のスクリプトが日本語の文字でエラーを返すコマンドを実行していると、vCenter Server はこのメッセージを適切なエンコーディングで変換しません。SRM は無効な例外を受信し、予期せずに停止します。この問題は修正されました。

  • Windows 2003 ゲスト OS で DR IP Customizer ツールが通知を送信することなく予期せず停止をする。

    Windows 2003 ゲスト OS で、DR IP Customizer ツールが予期せず停止します。通知は送信されませんが、SRM ログには次のエラーが表示されます。 C:\WINDOWS\TEMP\vmware-SYSTEM\netshIPv6.vbs(279, 4) Microsoft VBScript runtime error: Object doesn't support this property or method: 'GUID'.この問題は、存在しない GUID プロパティにアクセスを試みるときに発生した未処理のエラーによって引き起こされます。この問題は修正されました。

  • ゲスト OS の静止オプションが Windows Server 2012 を実行する仮想マシンに使用できない。

    vSphere Replication を Windows Server 2012 ゲスト OS の仮想マシンに構成すると、ゲスト OS の静止を有効化するオプションが使用できません。この問題は修正されました。

  • vSphere Replication は、ファイルが複製したディスク ファイルと同じ名前の場合、複製されていない仮想マシンのディスク ファイルをターゲット サイトから削除します。

    レプリケーションの構成ウィザードの [終了] ボタンをクリックする直前に、複製したディスクと同じ名前のディスクがターゲット データストアの場所に表示されている場合、レプリケーションの構成タスクは失敗します。その理由は、vSphere Replication がそこでディスクが見つかることを想定せず、このタスクによって作成されなかったディスクを誤って削除するからです。この問題は修正されました。

  • テスト フェイルオーバー、計画移行、またはディザスタ リカバリが、エラー「 Error creating ... image ...NullPointerException"」で失敗する。

    VRMS がディザスタ リカバリ ワークフローの特定の段階で、VR サーバからの応答の受信に失敗することがあります。そのディザスタ リカバリ操作は失敗します。操作を再実行しようとすると、エラー「 Error creating ... image ...NullPointerException"」で常に失敗します。この問題は修正され、操作の再実行の試行は正常に行われます。

  • 以前に除外されていたディスクを含めるようにレプリケーションを再構成し、レプリケーション シードをこのディスクに使用すると、vSphere Replication が誤ってレプリケーション シードを削除する。

    ディスクを除外してレプリケーションを構成し、後でそのディスクを含めるように再構成して、手動でディスク ファイルをコピーしてレプリケーション シードとして使用すると、vSphere Replication によって作成されたものではない初期のコピーであることは無視され、vSphere Replication がコピーされた .vmdk ファイルを削除します。このため、.vmdk ファイルをターゲット サイトに再度コピーする必要があります。この問題は修正されました。

  • vSphere Replication で、テスト クリーンアップ中に RevertSwap が失敗すると、テスト仮想マシンが削除される。

    テスト クリーンアップ中に RevertSwap が失敗すると、vSphere Replication がセカンダリ サイトに作成するテスト仮想マシンが削除されます。これにより親ディスクも削除されるため、実際のリカバリを実行する前に、完全同期を実行する必要があります。この問題は修正され、テスト仮想マシンは vSphere Replication によって削除されるのではなく、登録解除されるようになったため、ディスクは削除されません。

既知の問題

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

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

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

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

    SRM 5.0.3 のアップグレード プロセスはエラーなしで完了し、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. 初回同期が終了するのを待ちます。この同期は既存のディスクを使用し、データ整合性を確認します。

  • 保護サイトにある切断されたホストを削除した後で、再保護に失敗する。

    リカバリ操作の後に保護サイトから切断されたホストを削除し、再保護を実行すると、再保護操作がエラー「 Internal error: std::exception 'class Vmacore::Exception"」で失敗することがあります。

    回避策： [強制クリーンアップ] オプションを選択した状態で再保護を再実行してください。

  • SRM で起動時および不定期にパニックが発生する。

    vCenter Server の問題により、SRM Server がエラー「 panic 'Default' opID=7b0e972e] Duplicate key 'key-vim.host.ScsiDisk-020002000050002ac0000f0c70565620202020' in linkable vim.host.ScsiDisk referenced by field scsiLun (wsdl name scsiLun)」で予期せず停止することがあります。これは http://kb.vmware.com/kb/2033163 に記載されている vCenter Server のエラーにより発生します。

    回避策： vCenter Server インベントリからホストを削除した後、そのホストを再度追加します。

  • Windows Server 2012 にインストール後、初めて SRM インターフェイスにログインしようとすると失敗する。

    Windows Server 2012 に SRM Server をインストールすると、初めて SRM インターフェイスにログインしようとしたときに、リモート サーバの応答時間が長すぎるというエラー メッセージが出て、ログインに失敗します。この問題は、Windows Server 2012 に SRM をインストールした後、初めて SRM にログインするときにだけ発生します。

    回避策： vSphere Client を閉じてから再度開いて、もう一度 SRM にログインします。