Azure 間の VM レプリケーションに関するエラーのトラブルシューティング

[アーティクル]
03/07/2024

注意

この記事では、間もなくサポート終了 (EOL) 状態になる Linux ディストリビューションである CentOS について説明します。適宜、使用と計画を検討してください。詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。

この記事では、リージョン間で Azure 仮想マシン (VM) のレプリケーションと復旧を行うときに Azure Site Recovery で一般的なエラーをトラブルシューティングする方法について説明します。サポートされる構成の詳細については、Azure VM をレプリケートするためのサポートマトリックスに関するページをご覧ください。

Azure リソースのクォータに関する問題 (エラーコード 150097)

ディザスターリカバリー (DR) リージョンとして使用するターゲットリージョンで Azure VM を作成するには、サブスクリプションが有効であることを確認してください。必要なサイズの VM を作成するには、サブスクリプションに十分なクォータが必要です。既定では、Site Recovery ではソース VM のサイズと同じターゲット VM サイズが選択されます。同じサイズを利用できない場合、Site Recovery では利用可能な最も近いサイズが自動的に選択されます。

ソース VM 構成をサポートするサイズが存在しない場合、次のメッセージが表示されます。

Replication couldn't be enabled for the virtual machine <VmName>.

考えられる原因

ターゲットリージョンの場所で VM を作成するための、サブスクリプション ID が有効になっていません。
ターゲットリージョンの場所で特定の VM サイズを作成するための、サブスクリプション ID が有効になっていないか、十分なクォータが確保されていません。
ターゲットリージョンの場所のサブスクリプション ID について、ソース VM のネットワークインターフェイスカード (NIC) の数 (2) と一致する適切なターゲットVM サイズが見つかりません。

問題の解決

Azure 課金のサポートに連絡して、サブスクリプションで、必要なサイズの VM をターゲットの場所に作成できるようにします。その後、失敗した操作をやり直してください。

ターゲットの場所に容量の制約がある場合は、その場所へのレプリケーションを無効にします。次に、必要なサイズの VM を作成できるだけのクォータがサブスクリプションに確保されている別の場所へのレプリケーションを有効にします。

信頼されたルート証明書 (エラーコード 151066)

最新の信頼されたルート証明書の一部が VM にない場合、Site Recovery のレプリケーションを有効にするジョブが失敗することがあります。これらの証明書がないと、VM からの Site Recovery サービス呼び出しの認証と承認が失敗します。

レプリケーションを有効にするジョブが失敗すると、次のメッセージが表示されます。

Site Recovery configuration failed.

考えられる原因

承認と認証に必要な信頼されたルート証明書が仮想マシンに存在しません。

問題の解決

Windows

Windows オペレーティングシステムを実行中の VM の場合、最新 Windows 更新プログラムをインストールし、すべての信頼されたルート証明書が VM に存在するようにします。組織の一般的な Windows 更新管理プロセスまたは証明書更新管理プロセスに従って、VM で最新のルート証明書と更新済み証明書失効リストを取得します。

接続されていない環境の場合は、組織の標準の Windows 更新プロセスに従って、証明書を取得してください。
VM に必要な証明書がない場合は、セキュリティ上の理由から、Site Recovery サービスへの呼び出しが失敗します。

問題が解決されたことを確認するには、VM のブラウザーから login.microsoftonline.com にアクセスします。

詳細については、「信頼されたルートおよび許可されない証明書を構成する」を参照してください。

Linux

お使いの Linux オペレーティングシステムバージョンのディストリビューターから提供されるガイダンスに従って、VM で最新の信頼されたルート証明書と最新の証明書失効リストを取得します。

SUSE Linux ではシンボリックリンク (symlink) を使用して証明書リストを保持しているため、次の手順に従います。

ルート ユーザーとしてサインインします。ハッシュ記号 (#) は、既定のコマンドプロンプトです。
ディレクトリを変更するには、次のコマンドを実行します。

cd /etc/ssl/certs
Symantec ルート CA 証明書が存在するかどうかを確認します。

ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
- Symantec ルート CA 証明書が見つからない場合は、次のコマンドを実行してファイルをダウンロードします。エラーがないか確認し、ネットワーク障害に対する推奨アクションに従います。
  
  wget https://docs.broadcom.com/docs-and-downloads/content/dam/symantec/docs/other-resources/verisign-class-3-public-primary-certification-authority-g5-en.pem -O VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
Baltimore ルート CA 証明書が存在するかどうかを確認します。

ls Baltimore_CyberTrust_Root.pem
- Baltimore ルート CA 証明書が見つからない場合は、次のコマンドを実行して証明書をダウンロードします。
  
  wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem -O Baltimore_CyberTrust_Root.pem
DigiCert_Global_Root_CA 証明書が存在するかどうかを確認します。

ls DigiCert_Global_Root_CA.pem
- DigiCert_Global_Root_CA が見つからない場合は、次のコマンドを実行して証明書をダウンロードします。
```
wget http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt

openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCert_Global_Root_CA.pem
```
新たにダウンロードした証明書のサブジェクトハッシュを更新するには、再ハッシュスクリプトを実行します。

c_rehash

シンボリックリンクとしてのサブジェクトハッシュが証明書に対して作成されているかどうかを確認するには、次のコマンドを実行します。

ls -l | grep Baltimore

lrwxrwxrwx 1 root root   29 Jan  8 09:48 3ad48a91.0 -> Baltimore_CyberTrust_Root.pem

-rw-r--r-- 1 root root 1303 Jun  5  2014 Baltimore_CyberTrust_Root.pem

ls -l | grep VeriSign_Class_3_Public_Primary_Certification_Authority_G5

-rw-r--r-- 1 root root 1774 Jun  5  2014 VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

lrwxrwxrwx 1 root root   62 Jan  8 09:48 facacbc6.0 -> VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

ls -l | grep DigiCert_Global_Root

lrwxrwxrwx 1 root root   27 Jan  8 09:48 399e7759.0 -> DigiCert_Global_Root_CA.pem

-rw-r--r-- 1 root root 1380 Jun  5  2014 DigiCert_Global_Root_CA.pem

ファイル VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem のコピーを b204d74a.0 というファイル名で作成します。

cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0
ファイル Baltimore_CyberTrust_Root.pem のコピーを 653b494a.0 というファイル名で作成します。

cp Baltimore_CyberTrust_Root.pem 653b494a.0
ファイル DigiCert_Global_Root_CA.pem のコピーを 3513523f.0 というファイル名で作成します。

cp DigiCert_Global_Root_CA.pem 3513523f.0

これらのファイルが存在するかどうかを確認します。

ls -l 653b494a.0 b204d74a.0 3513523f.0

-rw-r--r-- 1 root root 1774 Jan  8 09:52 3513523f.0

-rw-r--r-- 1 root root 1303 Jan  8 09:52 653b494a.0

-rw-r--r-- 1 root root 1774 Jan  8 09:52 b204d74a.0

送信 URL または IP 範囲 (エラーコード 151037 または 151072)

Site Recovery レプリケーションを動作させるには、VM から特定の URL への送信接続が必要です。 VM がファイアウォールの内側にあるか、ネットワークセキュリティグループ (NSG) ルールを使用して送信接続を制御している場合は、次のいずれかの問題に直面することがあります。 URL を介した送信アクセスについては引き続きサポートされていますが、IP 範囲の許可リストを使用することはサポートされなくなりました。

考えられる原因

ドメインネームシステム (DNS) を解決できないため、Site Recovery エンドポイントとの接続を確立できません。
この問題が頻繁に発生するのは、仮想マシンをフェールオーバーして再保護を行っているときに、ディザスターリカバリー (DR) リージョンから DNS サーバーに到達できない場合です。

問題の解決

カスタム DNS を使っている場合は、ディザスターリカバリーリージョンから DNS サーバーにアクセスできることを確認します。

VM がカスタム DNS 設定を使用するかどうかを確認するには、次を実行します。

[仮想マシン] を開いて、VM を選択します。
VM の [設定] に移動し、 [ネットワーク] を選択します。
[仮想ネットワーク/サブネット] で、仮想ネットワークのリソースページを開くためのリンクを選択します。
[設定] に移動して、 [DNS サーバー] を選択します。

仮想マシンから DNS サーバーにアクセスを試みます。 DNS サーバーにアクセスできない場合は、DNS サーバーをフェールオーバーするか、または DR ネットワークと DNS の間にサイトのラインを作成して、アクセスできるようにします。

Note

プライベートエンドポイントを使用する場合は、確実に VM によるプライベート DNS レコードの解決が可能であるようにします。

com-error。

問題 2:Site Recovery の構成に失敗しました (151196)

考えられる原因

Microsoft 365 認証と ID IP4 エンドポイントへの接続を確立できません。

問題の解決

Azure Site Recovery では、認証のために Microsoft 365 の IP 範囲にアクセスする必要がありました。 Azure ネットワークセキュリティグループ (NSG) 規則またはファイアウォールプロキシを使用して VM 上で発信ネットワーク接続を制御している場合、Microsoft Entra ID へのアクセスを許可するには Microsoft Entra サービスタグに基づく NSG 規則を確実に使用してください。 IP アドレスベースの NSG 規則はサポートしなくなりました。

問題 3:Site Recovery の構成に失敗しました (151197)

考えられる原因

Azure Site Recovery サービスエンドポイントへの接続を確立できません。

問題の解決

VM での発信ネットワーク接続の制御に Azure ネットワークセキュリティグループ (NSG) 規則またはファイアウォールプロキシを使用している場合は、確実にサービスタグを使用してください。 Azure Site Recovery の NSG を介して IP アドレスの許可リストを使用することはサポートされなくなりました。

問題 4:ネットワークトラフィックでオンプレミスのプロキシサーバーが使用されるとレプリケーションが失敗する (151072)

考えられる原因

カスタムプロキシ設定が無効であり、Mobility Service エージェントが Internet Explorer (IE) からプロキシ設定を自動検出しませんでした。

問題の解決

Mobility Service エージェントは、Windows では IE から、Linux では /etc/environment からプロキシ設定を検出します。
プロキシを Mobility Service にのみ設定する場合は、次の場所にある ProxyInfo.conf 内にプロキシの詳細を指定できます。
- Linux: /usr/local/InMage/config/
- Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config
ProxyInfo.conf 内のプロキシ設定は、次の INI 形式になっている必要があります。
```
[proxy]
Address=http://1.2.3.4
Port=567
```

Note

Mobility Service エージェントは、認証されていないプロキシのみをサポートします。

詳細情報

必要な URL または必要な IP 範囲を指定するには、「Azure から Azure へのレプリケーションのネットワークについて」のガイダンスに従ってください。

VM でディスクが見つからない (エラーコード 150039)

VM に接続された新しいディスクを初期化する必要があります。ディスクが見つからない場合は、次のメッセージが表示されます。

Azure data disk <DiskName> <DiskURI> with logical unit number <LUN> <LUNValue> was not mapped to a corresponding disk being reported from within the VM that has the same LUN value.

考えられる原因

新しいデータディスクが VM に接続されているが、初期化されませんでした。
VM 内部のデータディスクは、そのディスクが VM に接続されている論理ユニット番号 (LUN) 値を正しく報告していません。

問題の解決

データディスクが初期化されていることを確認し、操作を再試行します。

Windows:新しいディスクを接続し、初期化する。
Linux:Linux で新しいデータディスクを初期化する。

問題が解決しない場合は、サポートにお問い合わせください。

複数のディスクで保護が使用可能である (エラーコード 153039)

考えられる原因

保護の後に、1 つまたは複数のディスクが最近仮想マシンに追加された。
仮想マシンの保護の後に、1 つまたは複数のディスクが初期化された。

問題の解決

VM のレプリケーション状態をもう一度正常にするには、ディスクを保護するか、警告を無視します。

ディスクを保護するには、次の手順に従います。

[レプリケートされたアイテム]>[VM 名]>[ディスク] にアクセスします。
保護されていないディスクを選択し、 [レプリケーションを有効にする] を選択します。

警告を無視するには、次の手順に従います。

[レプリケートされたアイテム]>[VM 名] に移動します。
[概要] セクションで警告を選択し、 [OK] を選択します。

VM がコンテナーから削除され、完了時に情報が表示された (エラーコード 150225)

Site Recovery によって仮想マシンが保護されると、ソース仮想マシンにリンクが作成されます。保護を削除するか、レプリケーションを無効にすると、Site Recovery によるクリーンアップジョブの一環として、これらのリンクが削除されます。仮想マシンにリソースロックが設定されている場合、クリーンアップジョブが完了するときに情報が表示されます。その情報には、仮想マシンが Recovery Services コンテナーから削除されたが、ソースマシンから古いリンクの一部をクリーンアップできなかったことが表示されます。

この仮想マシンを保護する予定がない場合、この警告は無視してもかまいません。ただし、後でこの仮想マシンを保護する必要がある場合は、このセクションの手順に従ってリンクをクリーンアップしてください。

警告

クリーンアップしないと、次のような事態が発生します。

Recovery Services コンテナーを使用してレプリケーションを有効にしたときに、仮想マシンが表示されません。
[仮想マシン]>[設定]>[ディザスターリカバリー] を使用して VM を保護しようとすると、"VM の既存のリソースリンクが古いため、レプリケーションを有効にすることはできません" というエラーメッセージが表示されて操作が失敗します。

問題の解決

Note

以下の手順の実行中は、Site Recovery でソース仮想マシンを削除することも、何らかの方法で影響を与えることもできません。

VM または VM リソースグループから、ロックを削除します。たとえば次の図で、MoveDemo という名前の VM のリソースロックを削除する必要があります。
古い Site Recovery 構成を削除するためのスクリプトをダウンロードします。
Cleanup-stale-asr-config-Azure-VM.ps1 スクリプトを実行します。パラメーターとして、サブスクリプション ID、VM リソースグループ、および VM 名を指定します。
Azure 資格情報の入力を求められたら、それを指定します。次に、スクリプトがエラーを出さずに実行されることを確認します。

古いリソースを含む VM でレプリケーションが有効にならない (エラーコード 150226)

考えられる原因

仮想マシンに、以前の Site Recovery 保護の古い構成が残されている。

Site Recovery を使用して Azure VM のレプリケーションを有効にした後、次のことを行った場合、Azure VM で古い構成が残る可能性があります。

レプリケーションを無効にしたが、ソース VM にリソースロックがある。
VM でレプリケーションを明示的に無効にせずに、Site Recovery コンテナーを削除した。
VM でレプリケーションを明示的に無効にせずに、Site Recovery コンテナーを含むリソースグループを削除した。

問題の解決

Note

以下の手順の実行中は、Site Recovery でソース仮想マシンを削除することも、何らかの方法で影響を与えることもできません。

VM または VM リソースグループから、ロックを削除します。たとえば次の図で、MoveDemo という名前の VM のリソースロックを削除する必要があります。
古い Site Recovery 構成を削除するためのスクリプトをダウンロードします。
Cleanup-stale-asr-config-Azure-VM.ps1 スクリプトを実行します。パラメーターとして、サブスクリプション ID、VM リソースグループ、および VM 名を指定します。
Azure 資格情報の入力を求められたら、それを指定します。次に、スクリプトがエラーを出さずに実行されることを確認します。

レプリケーションの有効化ジョブで VM またはリソースグループを選択できない

問題 1:リソースグループとソース VM が別の場所にある

Site Recovery では現在、ソースリージョンのリソースグループと仮想マシンが同じ場所にあることが必須となっています。そうでない場合、保護を適用しようとするときに、仮想マシンもリソースグループも見つけることができません。

回避策として、Recovery Services コンテナーではなく、VM からレプリケーションを有効にします。 [ソース VM]>[プロパティ]>[ディザスターリカバリー] に移動し、レプリケーションを有効にします。

問題 2:このリソースグループが、選択されたサブスクリプションの一部でない

リソースグループが選択されたサブスクリプションの一部ではない場合、保護されたときにリソースグループを見つけられない可能性があります。リソースグループが、使用中のサブスクリプションに属していることを確認します。

問題 3:構成が古い

Azure VM 上に古い Site Recovery 構成が存在する場合、レプリケーションを有効にする VM が表示されない可能性があります。 Site Recovery を使用して Azure VM のレプリケーションを有効にした後、次のことを行った場合、この状態が発生する可能性があります。

VM でレプリケーションを明示的に無効にせずに、Site Recovery コンテナーを削除した。
VM でレプリケーションを明示的に無効にせずに、Site Recovery コンテナーを含むリソースグループを削除した。
レプリケーションを無効にしたが、ソース VM にリソースロックがある。

問題の解決

Note

このセクションで説明するスクリプトを使用する前に、AzureRM.Resources モジュールを必ず更新するようにしてください。以下の手順の実行中は、Site Recovery でソース仮想マシンを削除することも、何らかの方法で影響を与えることもできません。

VM または VM リソースグループにロックが設定されている場合、ロックを削除します。たとえば次の図で、MoveDemo という名前の VM のリソースロックを削除する必要があります。
古い Site Recovery 構成を削除するためのスクリプトをダウンロードします。
Cleanup-stale-asr-config-Azure-VM.ps1 スクリプトを実行します。パラメーターとして、サブスクリプション ID、VM リソースグループ、および VM 名を指定します。
Azure 資格情報の入力を求められたら、それを指定します。次に、スクリプトがエラーを出さずに実行されることを確認します。

保護のために VM を選択できない

考えられる原因

仮想マシンの拡張機能のインストールが失敗したかまたは応答しない状態にある

問題の解決

[仮想マシン]>[設定]>[拡張機能] の順に進み、拡張機能のいずれかが失敗した状態になっていないか確認します。失敗したすべての拡張機能をアンインストールしてから、仮想マシンの保護を再試行してください。

VM のプロビジョニング状態が有効でない (エラーコード 150019)

VM でレプリケーションを有効にするには、プロビジョニングの状態が [成功] になっている必要があります。プロビジョニングの状態を確認するには、次の手順を実行します。

Azure portal の [すべてのサービス] から [リソースエクスプローラー] を選択します。
[サブスクリプション] 一覧を展開して、自分のサブスクリプションを選択します。
[ResourceGroups] 一覧を展開して、VM のリソースグループを選択します。
[リソース] 一覧を展開して、お使いの VM を選択します。
右側にあるインスタンスビューで、 [provisioningState] フィールドを確認します。

問題の解決

[provisioningState] が [失敗] になっている場合は、サポートに詳細を問い合わせてトラブルシューティングします。
[provisioningState] が [更新中] になっている場合は、別の拡張機能がデプロイされている可能性があります。 VM 上に何らかの進行中の操作があるかを確認し、それらが完了するまで待機してから、レプリケーションを有効にする、失敗した Site Recovery ジョブを再試行します。

ターゲット VM を選択できない

問題 1:既にターゲットネットワークにマップされているネットワークに VM が接続されている

ディザスターリカバリー構成中に、ソース VM が仮想ネットワークの一部であり、かつ同じ仮想ネットワークの別の VM が既にターゲットリソースグループ内のネットワークにマップされている場合は、既定で [ネットワークの選択] ドロップダウンリストボックスを使用できません (淡色表示されます)。

ネットワーク選択リストを使用できない。

問題 2:以前に VM を保護した後、レプリケーションを無効にした

VM のレプリケーションを無効にしても、ネットワークマッピングは削除されません。 VM が保護されていた Recovery Service コンテナーからマッピングを削除する必要があります。 [Recovery Services コンテナー] を選択し、 [管理]>[Site Recovery インフラストラクチャ]>[For Azure virtual machines] (Azure 仮想マシンの場合)>[ネットワークマッピング] に移動します。

ネットワークマッピングの削除。

ディザスターリカバリーのセットアップ中に構成されたターゲットネットワークが、初期セットアップ後で、かつ VM が保護された後に変更される場合があります。 ネットワークマッピングを変更するには、ネットワーク名を選択します。

ネットワークマッピングの変更。

COM+ または VSS (エラーコード 151025)

COM+ またはボリュームシャドウコピーサービス (VSS) エラーが発生すると、次のメッセージが表示されます。

Site Recovery extension failed to install.

考えられる原因

COM+ システムアプリケーションサービスが無効になっています。
ボリュームシャドウコピーサービスが無効になっています。

問題の解決

COM+ システムアプリケーションとボリュームシャドウコピーサービスを、自動または手動スタートアップモードに設定します。

Windows の "サービス" コンソールを開きます。
COM+ システムアプリケーションとボリュームシャドウコピーサービスの [スタートアップの種類] が [無効] に設定されていないことを確認します。

サポートされていないマネージドディスクのサイズ (エラーコード 150172)

このエラーが発生すると、次のメッセージが表示されます。

Protection couldn't be enabled for the virtual machine as it has <DiskName> with size <DiskSize> that is lesser than the minimum supported size 1024 MB.

考えられる原因

ディスクが、サポートされているサイズの 1024 MB を下回っています。

問題の解決

ディスクサイズがサポートされているサイズの範囲内にあることを確認し、操作を再試行してください。

GRUB でデバイス名を使用するときに保護が有効にならない (エラーコード 151126)

考えられる原因

Linux Grand Unified Bootloader (GRUB) 構成ファイル ( /boot/grub/menu.lst、 /boot/grub/grub.cfg、 /boot/grub2/grub.cfg、または /etc/default/grub) に、root と resume パラメーターに対してユニバーサル一意識別子 (UUID) の値ではなく実際のデバイス名が指定されている可能性があります。デバイス名は変更できるため、Site Recovery には UUID が必要です。再起動時のフェールオーバー時に VM が同じ名前で表示されず、問題が発生する可能性があります。

次の例は、必要な UUID ではなくデバイス名が表示される、GRUB ファイルの行です。

ファイル: /boot/grub2/grub.cfg

linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts
ファイル: /boot/grub/menu.lst

kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314

問題の解決

各デバイス名を対応する UUID に置き換えます。

コマンド blkid <device name> を実行して、デバイスの UUID を検出します。次に例を示します。

blkid /dev/sda1
/dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
blkid /dev/sda2
/dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"

root=UUID=<UUID> および resume=UUID=<UUID> の形式で、デバイス名を UUID に置き換えます。たとえば、 /boot/grub/menu.lst の行は置換後に次の行のようになります。

kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314
保護を再試行してください。

GRUB デバイスが存在しないため保護に失敗した (エラーコード 151124)

考えられる原因

GRUB 構成ファイル ( /boot/grub/menu.lst、 /boot/grub/grub.cfg、 /boot/grub2/grub.cfg、または /etc/default/grub) に、rd.lvm.lv または rd_LVM_LV というパラメーターが含まれている可能性があります。これらのパラメーターは、起動時に検出される論理ボリュームマネージャ (LVM) デバイスを識別します。これらの LVM デバイスが存在しない場合、保護されたシステム自体は起動せず、起動プロセスでスタックします。フェールオーバー VM にも同じ問題が確認されます。次に例をいくつか示します。

ファイル: /boot/grub2/grub.cfg (RHEL7 の場合):

linux16 /vmlinuz-3.10.0-957.el7.x86_64 root=/dev/mapper/rhel_mup--rhel7u6-root ro crashkernel=128M\@64M rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet LANG=en_US.UTF-8
ファイル: /etc/default/grub (RHEL7 の場合):

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet
ファイル: /boot/grub/menu.lst (RHEL6 の場合):

kernel /vmlinuz-2.6.32-754.el6.x86_64 ro root=UUID=36dd8b45-e90d-40d6-81ac-ad0d0725d69e rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=rootvg/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=rootvg/lv_swap rd_NO_DM rhgb quiet

それぞれの例で、GRUB はボリュームグループ rootvg から root および swap という名前の 2 つの LVM デバイスを検出する必要があります。

問題の解決

LVM デバイスが存在しない場合は、このデバイスを作成するか、GRUB 構成ファイルから対応するパラメーターを削除します。次に、再び保護を有効にしてください。

Mobility Service の更新が完了し、警告が表示された (エラーコード 151083)

Site Recovery Mobility Service には多数のコンポーネントがありますが、そのうちの 1 つに、フィルタードライバーと呼ばれるものがあります。フィルタードライバーは、システムの再起動時にのみ、システムメモリ内に読み込まれます。 Mobility Service の更新にフィルタードライバーの変更が含まれている場合、マシンは更新されますが、一部の修正プログラムで再起動が必要であることを示す警告が表示されます。この警告が表示される理由は、フィルタードライバーの修正は、新しいフィルタードライバーが読み込まれたときにのみ有効になるためであり、これは再起動中にのみ発生します。

Note

これはただの警告です。既存のレプリケーションは、新しいエージェントが更新された後も引き続き機能します。再起動は、新しいフィルタードライバーの利点を活用したい任意のタイミングで実行できますが、再起動しない場合は古いフィルタードライバーが動作し続けます。

フィルタードライバーを除く、Mobility Service の更新におけるその他の機能強化や修正の利点は、再起動を必要とせずに有効になります。

レプリカマネージドディスクが存在する場合は保護が有効にならない

このエラーは、レプリカマネージドディスクが (予測されるタグなしで) ターゲットリソースグループに既に存在する場合に発生します。

考えられる原因

この問題は、仮想マシンが以前に保護されていて、レプリケーションを無効にしたときにレプリカディスクが削除されていない場合に発生する可能性があります。

問題の解決

エラーメッセージに示されているレプリカディスクを削除し、失敗した保護ジョブを再度開始します。

インストーラーがルートディスクを検出できないため、保護の有効化に失敗した (エラーコード 151137)

このエラーは、Azure Disk Encryption (ADE) を使用して OS ディスクが暗号化されている Linux マシンで発生します。これは、エージェントバージョン 9.35 でのみ有効な問題です。

考えられる原因

インストーラーは、ルートファイルシステムをホストしているルートディスクを検出できません。

問題の解決

この問題を解決するには、次の手順を実行します。

次のコマンドを使用して、RHEL および CentOS マシンのディレクトリ /var/lib/waagent の下にあるエージェントファイルを検索します。

# find /var/lib/ -name Micro\*.gz

予想される出力:

/var/lib/waagent/Microsoft.Azure.RecoveryServices.SiteRecovery.LinuxRHEL7-1.0.0.9139/UnifiedAgent/Microsoft-ASR_UA_9.35.0.0_RHEL7-64_GA_30Jun2020_release.tar.gz
新しいディレクトリを作成し、ディレクトリをこの新しいディレクトリに変更します。
次のコマンドを使用して、最初の手順で見つかったエージェントファイルを抽出します。

tar -xf <Tar Ball File>
prereq_check_installer.json ファイルを開き、次の行を削除します。その後、ファイルを保存します。
```
   {
      "CheckName": "SystemDiskAvailable",
      "CheckType": "MobilityService"
   },
```
次のコマンドを使用して、インストーラーを起動します。

./install -d /usr/local/ASR -r MS -q -v Azure
インストーラーが正常に完了したら、レプリケーションの有効化ジョブを再試行します。

レプリケートされたサーバーでの時間の変更に対するトラブルシューティングと処理

このエラーは、変更を修正するために、ソースマシンの時間が進み、その後短時間で戻る場合に発生します。時間が非常に迅速に修正されるため、変更に気付かないことがあります。

解決方法: この問題を解決するには、システム時間がずれている未来時間を超えるまで待ちます。もう 1 つの選択肢は、レプリケーションを無効化し、もう一度有効化することです。これは、フォワードレプリケーション (データがプライマリリージョンからセカンダリリージョンにレプリケートされる) の場合のみ実行でき、リバースレプリケーション (データがセカンダリリージョンからプライマリリージョンにレプリケートされる) には適用できません。

次のステップ

Azure VM を別の Azure リージョンにレプリケートします。

Azure 間の VM レプリケーションに関するエラーのトラブルシューティング

Azure リソースのクォータに関する問題 (エラー コード 150097)

考えられる原因

問題の解決

信頼されたルート証明書 (エラー コード 151066)

考えられる原因

問題の解決

Windows

Linux

送信 URL または IP 範囲 (エラー コード 151037 または 151072)

考えられる原因

問題の解決

問題 2:Site Recovery の構成に失敗しました (151196)

考えられる原因

問題の解決

問題 3:Site Recovery の構成に失敗しました (151197)

考えられる原因

問題の解決

問題 4:ネットワーク トラフィックでオンプレミスのプロキシ サーバーが使用されるとレプリケーションが失敗する (151072)

考えられる原因

問題の解決

詳細情報

VM でディスクが見つからない (エラー コード 150039)

考えられる原因

問題の解決

複数のディスクで保護が使用可能である (エラー コード 153039)

考えられる原因

問題の解決

ディスクを保護するには、次の手順に従います。

警告を無視するには、次の手順に従います。

VM がコンテナーから削除され、完了時に情報が表示された (エラー コード 150225)

問題の解決

古いリソースを含む VM でレプリケーションが有効にならない (エラー コード 150226)

考えられる原因

問題の解決

レプリケーションの有効化ジョブで VM またはリソース グループを選択できない

問題 1:リソース グループとソース VM が別の場所にある

問題 2:このリソース グループが、選択されたサブスクリプションの一部でない

問題 3:構成が古い

問題の解決

保護のために VM を選択できない

考えられる原因

問題の解決

VM のプロビジョニング状態が有効でない (エラー コード 150019)

問題の解決

ターゲット VM を選択できない

問題 1:既にターゲット ネットワークにマップされているネットワークに VM が接続されている

問題 2:以前に VM を保護した後、レプリケーションを無効にした

COM+ または VSS (エラー コード 151025)

考えられる原因

問題の解決

サポートされていないマネージド ディスクのサイズ (エラー コード 150172)

考えられる原因

問題の解決

GRUB でデバイス名を使用するときに保護が有効にならない (エラー コード 151126)

考えられる原因

問題の解決

GRUB デバイスが存在しないため保護に失敗した (エラー コード 151124)

考えられる原因

問題の解決

Mobility Service の更新が完了し、警告が表示された (エラー コード 151083)

レプリカ マネージド ディスクが存在する場合は保護が有効にならない

考えられる原因

問題の解決

インストーラーがルート ディスクを検出できないため、保護の有効化に失敗した (エラー コード 151137)

考えられる原因

問題の解決

レプリケートされたサーバーでの時間の変更に対するトラブルシューティングと処理

次のステップ

その他のリソース

Azure リソースのクォータに関する問題 (エラーコード 150097)

信頼されたルート証明書 (エラーコード 151066)

送信 URL または IP 範囲 (エラーコード 151037 または 151072)

問題 4:ネットワークトラフィックでオンプレミスのプロキシサーバーが使用されるとレプリケーションが失敗する (151072)

VM でディスクが見つからない (エラーコード 150039)

複数のディスクで保護が使用可能である (エラーコード 153039)

VM がコンテナーから削除され、完了時に情報が表示された (エラーコード 150225)

古いリソースを含む VM でレプリケーションが有効にならない (エラーコード 150226)

レプリケーションの有効化ジョブで VM またはリソースグループを選択できない

問題 1:リソースグループとソース VM が別の場所にある

問題 2:このリソースグループが、選択されたサブスクリプションの一部でない

VM のプロビジョニング状態が有効でない (エラーコード 150019)

問題 1:既にターゲットネットワークにマップされているネットワークに VM が接続されている

COM+ または VSS (エラーコード 151025)

サポートされていないマネージドディスクのサイズ (エラーコード 150172)

GRUB でデバイス名を使用するときに保護が有効にならない (エラーコード 151126)

GRUB デバイスが存在しないため保護に失敗した (エラーコード 151124)

Mobility Service の更新が完了し、警告が表示された (エラーコード 151083)

レプリカマネージドディスクが存在する場合は保護が有効にならない

インストーラーがルートディスクを検出できないため、保護の有効化に失敗した (エラーコード 151137)