次の方法で共有

VMware VM または物理マシンから Azure へのフェールオーバー時のエラーをトラブルシューティングする

仮想マシンから Azure へフェールオーバーを実行中に、次のいずれかのエラーを受け取る可能性があります。 トラブルシューティングするには、各エラー条件に説明されている手順に従います。

エラー ID 28031 でフェールオーバーが失敗している

Site Recovery は、フェールオーバーした仮想マシンを Azure に作成できませんでした。 次のような原因が考えられます。

  • 仮想マシンの作成に使用できる十分なクォータがありません。[サブスクリプション] -> [使用量 + クォータ] の順に移動して、使用可能なクォータを確認できます。 新しいサポート要求を開いて、クォータを増やすことができます。

  • 同じ可用性セットに異なるサイズ ファミリの仮想マシンをフェールオーバーしようとしています。 同じ可用性セットにあるすべての仮想マシンに対しては、必ず同じサイズ ファミリを選択してください。 仮想マシンの [コンピューティング] 設定に移動してサイズを変更し、フェールオーバーを再試行してください。

  • サブスクリプションに、仮想マシンの作成を禁止しているポリシーがあります。 仮想マシンの作成を許可するようにポリシーを変更して、フェールオーバーを再試行してください。

エラー ID 28092 でフェールオーバーが失敗している

Site Recovery は、フェールオーバーした仮想マシンのネットワーク インターフェイスを作成できませんでした。 サブスクリプションでネットワーク インターフェイスを作成するために使用できる十分なクォータがあることを確認してください。 [サブスクリプション] -> [使用量 + クォータ] の順に移動して、使用可能なクォータを確認できます。 新しいサポート要求を開いて、クォータを増やすことができます。 十分なクォータがある場合、この現象は一時的に発生している可能性があります。もう一度、操作をやり直してください。 再試行しても問題が続く場合、この文書の最後にコメントを残してください。

エラー ID 70038 でフェールオーバーが失敗している

Site Recovery は、フェールオーバーした従来の仮想マシンを Azure に作成できませんでした。 次のような原因が考えられます。

  • 仮想ネットワークなど、仮想マシンの作成に必要ないずれかのリソースが存在しない。 仮想マシンの [ネットワーク] 設定に指定されているように仮想ネットワークを作成するか、既に存在している仮想ネットワークの設定を変更して、フェールオーバーを再試行してください。

エラー ID 170010 でフェールオーバーが失敗している

Site Recovery は、フェールオーバーした仮想マシンを Azure に作成できませんでした。 これは、オンプレミスの仮想マシンでハイドレーションの内部アクティビティが失敗したために発生します。

Azure でマシンを起動するには、Azure 環境で、いくつかのドライバーがブート開始状態であり、DHCP などのサービスが自動開始状態である必要があります。 そのため、ハイドレーション アクティビティは、フェールオーバーの時点で、atapi、intelide、storflt、vmbus、および storvsc ドライバーのスタートアップの種類をブート開始に変換します。 また、DHCP などのいくつかのサービスのスタートアップの種類も自動開始に変換します。 このアクティビティは、環境固有の問題が原因で失敗する可能性があります。

Windows Guest OS 用のドライバーのスタートアップの種類を手動で変更するには、次の手順に従ってください。

  1. 次のように、no-hydration スクリプトをダウンロードして実行します。 このスクリプトは、VM にハイドレーションが必要かどうかを確認します。

    .\Script-no-hydration.ps1

    ハイドレーションが必要な場合は、次の結果を示します。

    REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0

This system doesn't meet no-hydration requirement.

    VM がハイドレーションなしの要件を満たしている場合、スクリプトは「このシステムはハイドレーションなしの要件を満たしている」という結果を示します。 この場合、すべてのドライバーとサービスは Azure で必要とされている状態にあり、VM にハイドレーションは必要ありません。

  2. VM がハイドレーションなしの要件を満たしていない場合は、次のように no-hydration-set スクリプトを実行します。

    .\Script-no-hydration.ps1 -set

    こうするとドライバーのスタートアップの種類が変換され、次のような結果が示されます。

    REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0

Updating registry:  REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc   start =  0

This system is now no-hydration compatible.

仮想マシンのネットワーク アダプターのレプリカ IP アドレスが無効であることを示すエラーで、フェールオーバーに失敗しました

前のテスト フェールオーバー操作が適切にクリーンアップされなかった場合、[One or more replica IP addresses for the network adapter of virtual machine is invalid] (仮想マシンのネットワーク アダプターの 1 つ以上のレプリカ IP アドレスが無効です) というエラーが表示され、マシンのテスト フェールオーバー操作またはフェールオーバー操作が失敗するおそれがあります。 このために、テスト マシンが引き続き Azure 環境に存在し、同じ IP アドレスを使用している可能性があります。 これが原因で、仮想マシンのターゲット構成がクリティカルな状態になります。

この問題を解決するには、テスト フェールオーバーのクリーンアップが完全に行われていることを確認して、フェールオーバー操作またはテスト フェールオーバー操作が成功するようにします。

仮想マシンで [接続] ボタンが灰色表示されているために、/RDP/SSH をフェールオーバーされた仮想マシンに接続できない

RDP の問題に関する詳細なトラブルシューティング手順については、こちらのドキュメントを参照してください。

SSH の問題に関する詳細なトラブルシューティング手順については、こちらのドキュメントを参照してください。

Azure でフェールオーバーされた VM の [接続] ボタンが淡色表示されていて、Express Route またはサイト間 VPN 接続を使用して Azure に接続されない場合は、次の操作を実行します。

  1. [仮想マシン]>[ネットワーク] に移動し、必要なネットワーク インターフェイスの名前をクリックします。 仮想マシンのネットワーク ページを示すスクリーンショット。ネットワーク インターフェイス名が選ばれています。
  2. [IP 構成] に移動し、必要な IP 構成の名前フィールドを選択します。 ネットワーク インターフェイスの IP 構成ページを示すスクリーンショット。IP 構成名が選ばれています。
  3. パブリック IP アドレスを有効にするには、[有効にする] をクリックします。 IP の有効化
  4. [必要な設定の構成]>[新規作成] をクリックします。 新規作成
  5. パブリック アドレスの名前を入力し、[SKU] と [割り当て] の既定のオプションを選択し、[OK] を選択します。
  6. 次に、[保存] を選択して、行った変更を保存します。
  7. パネルを閉じ、仮想マシンの [概要] セクションに移動して、/RDP に接続します。

接続/RDP/SSH ができない - VMConnect ボタンは使用可能

Azure でフェールオーバーされた VM で [接続] ボタンが使用できる (淡色表示されていない) 場合は、仮想マシンで [Boot diagnostics]\(ブート診断) を調べ、この記事に記載されているエラーがないかチェックします。

  1. 仮想マシンが起動されていない場合は、前の復旧ポイントにフェールオーバーしてみます。

  2. 仮想マシン内のアプリケーションが開始されていない場合は、アプリケーションと整合性がとれた復旧ポイントにフェールオーバーしてみます。

  3. 仮想マシンがドメインに参加している場合は、ドメイン コントローラーが適切に機能していることを確認します。 そのためには、以下の手順に従います。

    ある。 同じネットワークに新しい仮想マシンを作成します。

    b。 フェールオーバーされた仮想マシンが開始されるはずになっているものと、同じドメインに参加できることを確認します。

    c. ドメイン コントローラーが適切に機能していない場合は、ローカル管理者アカウントを使用して、フェールオーバーされた仮想マシンにログインしてみます。

  4. カスタム DNS サーバーを使用している場合は、そのサーバーにアクセスできることを確認します。 そのためには、以下の手順に従います。

    ある。 同じネットワークに新しい仮想マシンを作成します

    b。 カスタムの DNS サーバーを使用して仮想マシンが名前を解決できるかどうかを確認します

注

ブート診断以外の設定を有効にした場合は、フェールオーバーの前に Azure VM エージェントを仮想マシンにインストールする必要があります。

UEFI ベースのマシンを Azure にフェールオーバーした後、シリアル コンソールを開くことができない

RDP を使用してマシンに接続できても、シリアル コンソールを開くことができない場合は、下記の手順に従います。

  • マシンの OS が Red Hat または Oracle Linux 7.*/8.0 の場合は、ルート アクセス許可を使用してフェールオーバー Azure VM で次のコマンドを実行します。 コマンドを実行した後に VM を再起動します。

    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

予期しないシャット ダウンのメッセージ (イベント ID 6008)

フェールオーバー後の Windows VM 起動時に、復旧した VM で、予期しないシャット ダウンのメッセージを受信した場合は、フェールオーバーに使用された復旧ポイントで、VM のシャット ダウン状態がキャプチャされなかったことを示しています。 これは、VM が完全にはシャット ダウンされていないときのポイントに復旧すると発生します。

これは一般に懸念の原因にはならないため、計画外のフェールオーバーであれば通常は無視できます。 フェールオーバーが計画されている場合は、フェールオーバーの前に VM が正しくシャット ダウンされるようにして、オンプレミスの保留中のレプリケーション データが Azure に送信されるのに十分な時間を確保します。 次に、フェールオーバー画面の [Lateset]\(最新) オプションを使用して、Azure 上の保留中データがすべて処理されて復旧ポイントに入れられるようにします。それが後で、VM のフェールオーバーに使用されます。

データストアを選択できない

この問題は、フェールオーバーが発生した仮想マシンを再保護しようとした際に、Azure portal でデータストアが表示されない状況を示しています。 これは、マスター ターゲットが、Azure Site Recovery に追加された vCenter の仮想マシンとして認識されていないためです。

仮想マシンの再保護の詳細については、「Azure へのフェールオーバー後に、マシンを再保護し、オンプレミス サイトにフェールバックする」を参照してください。

この問題を解決するには:

ソース マシンを管理する vCenter 内にマスター ターゲットを手動で作成します。 データストアを利用できるのは、次の vCenter の検出および更新ファブリック操作の後です。

注

検出および更新のファブリック操作は完了までに最大 30 分かかります。

Linux マスター ターゲット登録が TLS エラー 35 CS で失敗する

認証済みプロキシがマスター ターゲットで有効になっているため、構成サーバーでの Azure Site Recovery マスター ターゲット登録が失敗します。

このエラーは、インストール ログ内の次の文字列で示されます。

RegisterHostStaticInfo encountered exception config/talwrapper.cpp(107)[post] CurlWrapper Post failed : server : 10.38.229.221, port : 443, phpUrl : request_handler.php, secure : true, ignoreCurlPartialError : false with error: [at curlwrapperlib/curlwrapper.cpp:processCurlResponse:231]   failed to post request: (35) - SSL connect error.

この問題を解決するには:

  1. 構成サーバーの VM でコマンド プロンプトを開き、次のコマンドを使用してプロキシ設定を確認します。

    cat /etc/environment echo $http_proxy echo $https_proxy

  2. http_proxy または https_proxy のどちらかの設定が定義されていることが前のコマンドの出力で示されている場合は、次のいずれかの方法を使用して構成サーバーとマスター ターゲットの間の通信のブロックを解除します。

    • PsExec ツール をダウンロードします。

    • このツールを使用して、システム ユーザーのコンテキストにアクセスし、プロキシ アドレスが構成されているかどうかを判断します。

    • プロキシが構成されている場合は、PsExec ツールを使用してシステム ユーザーのコンテキストで Internet Explorer を開きます。

      psexec -s -i "%programfiles%\Internet Explorer\iexplore.exe"

    • マスター ターゲット サーバーが構成サーバーと必ず通信できるようにするには

      • プロキシ経由でマスター ターゲット サーバーの IP アドレスをバイパスするよう、Internet Explorer のプロキシ設定を変更します。
        または
      • マスター ターゲット サーバーでプロキシを無効にします。

次のステップ

さらにサポートが必要な場合は、Site Recovery に関する Microsoft Q&A 質問ページにクエリを投稿するか、この文書の最後にコメントを残してください。 ユーザー支援を可能にするために必要なアクティブ コミュニティを設置しています。