次の方法で共有


評価 - 一般的な質問

この記事では、Azure Migrate での評価に関するよくある質問の回答を示します。 その他の質問については、次のリソースを確認してください。

Azure Migrate を使用した検出と評価は、どの地域でサポートされていますか?

パブリックGovernment クラウドでサポートされている地域を確認してください。

1 つのアプライアンスで検出できるサーバーの数を教えてください

1 つのアプライアンスを使って最大 10,000 までの VMware 環境のサーバー、最大 5,000 までの Hyper-V 環境のサーバー、および最大 1000 までの物理サーバーを検出できます。 多くのサーバーがある場合は、「Hyper-v の評価のスケーリング」、「VMware の評価のスケーリング」、または「物理サーバーの評価のスケーリング」を参照してください。

評価の種類を選択するにはどうすればよいですか?

  • Azure VM への移行のためにオンプレミスの VMware および Hyper-V 環境のサーバー、および物理サーバーを評価する場合は、Azure VM の評価を使用します。 詳細については、こちらを参照してください
  • VMware、Microsoft Hyper-V、物理/ベアメタル環境のオンプレミスの SQL Server を評価する場合、および、Azure VM、Azure SQL Database、または Azure SQL Managed Instance 上の SQL Server に移行するために、AWS、GCP などの他のパブリック クラウドの IaaS サーバーを評価する場合は、評価の種類の Azure SQL を使用します。 詳細については、こちらを参照してください
  • VMware 環境から、IIS Web サーバーで実行されているオンプレミスの ASP.NET Web アプリを評価して、Azure App Service に移行する場合は、評価の種類として Azure App Service を使用します。 詳細については、こちらを参照してください
  • Azure VMware Solution (AVS) の評価を使用するのは、Azure VMware Solution (AVS) への移行のために、この評価の種類を使用してオンプレミスの VMware VM を評価する場合です。 詳細情報 を参照してください。
  • VMware マシンで共通グループを使用できるのは、両方の種類の評価を実行する場合のみです。 Azure Migrate で AVS の評価を初めて実行する場合は、VMware マシンの新しいグループを作成することをお勧めします。

Azure VM や AVS の評価レポートに、一部またはすべてのサーバーに関するパフォーマンス データがないのはなぜですか?

"パフォーマンスベース" の評価では、Azure Migrate アプライアンスでオンプレミスサーバーのパフォーマンス データを収集できない場合、評価レポートのエクスポートに "PercentageOfCoresUtilizedMissing" または "PercentageOfMemoryUtilizedMissing" と表示されます。 Azure Migrate ハブ ページの [問題の解決] ブレードで詳細な問題を確認すること、または以下を手動で確認することができます。

  • 評価を作成している期間にサーバーの電源がオンになっていたかどうか

  • メモリ カウンターのみが欠落しており、Hyper-V 環境内のサーバーを評価しようとしていたかどうか。 このシナリオでは、サーバーで動的メモリを有効にし、評価を "再計算 "して最新の変更内容を反映させます。 アプライアンスは、サーバーで動的メモリが有効になっている場合にのみ、Hyper-V 環境内のサーバーのメモリ使用率値を収集できます。

  • すべてのパフォーマンス カウンターがない場合は、ポート 443 (HTTPS) での発信接続が許可されていることを確認します。

    Note

    いずれかのパフォーマンス カウンターを取得できない場合、Azure Migrate: Server Assessment はオンプレミスの割り当てられたコアまたはメモリにフォールバックし、それに応じて VM サイズが推奨されます。

パフォーマンス データ収集の問題の原因となっているエラーの詳細を把握するにはどうすればよいですか?

Azure VM や Azure VMware Solution の評価におけるパフォーマンス データ収集の問題を解決するために、どのエラーを修復する必要があるかを把握できるようになりました。 次の手順のようにします。

  • [Azure Migrate] >[サーバー、データベース、Web アプリ]>[以降の目標] と移動し、検出および評価のツールで [問題の解決] を選択します。
  • 評価の横の [影響を受けるオブジェクト] を選択し、エラー ID 列でリンクを選択してエラーの詳細と修復アクションを確認します。

評価の作成中に、[評価するサーバーの選択] ステップまたは既存の評価の準備状況タブで、これらのエラーや問題を確認することもできます。 評価にエラーや問題は表示されないが、[問題の解決] ブレードに 0 以外のエラーが表示される場合は、評価を再計算して評価ブレード内の問題を確認します。

Azure SQL の評価に、一部またはすべての SQL インスタンスまたはデータベースに関するパフォーマンス データがないのはなぜですか?

パフォーマンス データが収集されるようにするには、次のことを確認してください。

  • 評価を作成している期間中に SQL サーバーの電源がオンになっていたかどうか。
  • Azure Migrate で SQL エージェントの接続状態が [接続済み] であるかどうか、また、最後のハートビートも確認します。
  • 検出された SQL インスタンスのセクションで、すべての SQL インスタンスの Azure Migrate の接続状態が "接続済み" かどうか。
  • すべてのパフォーマンス カウンターがない場合は、ポート 443 (HTTPS) での発信接続が許可されていることを確認します。

いずれかのパフォーマンス カウンターがない場合、Azure SQL 評価はオンプレミスのサイズ設定にフォールバックし、割り当てられたコア、メモリ、およびオンプレミスの合計データベース サイズに基づいて Azure SQL 構成を推奨します。

信頼度評価を Azure App Service 評価に使用できないのはなぜですか?

Azure App Service 評価用のパフォーマンス データはキャプチャされないため、この評価の種類に信頼度レーティングは表示されません。 Azure App Service 評価では、評価計算の実行中に Web アプリの構成データが考慮されます。

評価の信頼度レーティングが低いのはなぜですか?

信頼度評価は、評価を計算するために必要な使用可能データ ポイントの割合に基づいて、"パフォーマンス ベース" の評価に対して計算されます。 評価の信頼度レーティングが低い理由は以下のとおりです。

  • 評価を作成する期間について環境をプロファイルしなかった。 たとえば、パフォーマンス期間を 1 週間に設定した評価を作成する場合は、すべてのデータポイントが収集されるまで、検出を始めてから少なくとも 1 週間待つ必要があります。 その期間待つことができない場合は、パフォーマンス期間をより短い期間に変更し、評価を再計算します。

  • 評価期間内に一部または全部のサーバーのパフォーマンス データを評価で収集できません。 高い信頼度レーティングを得るために、次のことを確認します。

    • 評価期間中、サーバーの電源がオンになっている
    • ポート 443 でのアウトバウンド接続が許可されている
    • Hyper-V サーバーで、動的メモリが有効になっている
    • Azure Migrate のエージェントの接続状態が "接続済み" である、また、最後のハートビートも確認します
    • Azure SQL 評価において、検出された SQL インスタンス セクションで、すべての SQL インスタンスの Azure Migrate の接続状態が "接続済み" である。

    評価を再計算し、信頼性評価に最新の変更を反映します。

  • Azure VM および AVS の評価では、検出の開始後に作成されたサーバーはほとんどありませんでした。 たとえば、過去 1 か月間のパフォーマンス履歴の評価を作成しているのに、ほんの 1 週間前にいくつかのサーバーが環境内に作成されたとします。 この場合、新しいサーバーのパフォーマンス データは期間全体を通しては利用できず、信頼度レーティングが低くなります。 詳細情報 を参照してください。

  • Azure SQL の評価の場合、検出が開始された後で、いくつかの SQL インスタンスまたはデータベースが作成されました。 たとえば、過去 1 か月間のパフォーマンス履歴の評価を作成しているのに、ほんの 1 週間前にいくつかの SQL インスタンスまたはデータベースが環境内に作成されたとします。 この場合、新しいサーバーのパフォーマンス データは期間全体を通しては利用できず、信頼度レーティングが低くなります。 詳細情報 を参照してください。

RAM 使用率が 100% を超えるのはなぜですか?

設計上、プロビジョニングされた最大メモリが VM で必要なメモリよりも小さい場合、Hyper-V では、評価によってメモリ使用率に 100% を超える値が表示されます。

評価には、評価がプロセッサのパラメーターも考慮するようになったというバナーが表示されます。 評価を再計算すると、どのような影響がありますか?

評価では、使用可能なコア数やソケットなどのプロセッサ パラメーターを考慮に入れ、シミュレートされた環境での一定期間にわたる最適なパフォーマンスを計算するようになりました。 この目的は、使用できるプロセッサ情報に基づいてすべてのプロセッサのベンチマークを行うためです。 評価を再計算して、更新された推奨値を確認してください。

プロセッサ ベンチマークの数値は、オンプレミスの VMware サーバー、Hyper-V サーバー、物理サーバーのプロセッサ パフォーマンスと対応するようにリソース使用率と共に考慮され、それに応じてターゲット Azure SKU サイズが推奨されるようになりました。 これは、パフォーマンスのニーズに合わせて評価の推奨事項をさらに改善する方法です。

このため、ターゲット Azure VM のコストは、同じターゲットの以前の評価とは異なる場合があります。 また、ターゲット Azure SKU に割り当てられるコアの数は、ターゲットのプロセッサ パフォーマンスがオンプレミスの VMware サーバー、Hyper-V サーバー、物理サーバーと同等である場合にも変わることがあります。

お客様が "オンプレミスと同等に" を選択するようなシナリオでは、プロセッサ ベンチマークによる影響はありますか?

いいえ。オンプレミスと同等のシナリオと見なさないため、影響はありません。

評価を再計算した後、毎月のコストに増加がみられます。 これは当方にとって最も最適化されたコストですか?

評価設定で "VM シリーズ" で使用可能なすべてのオプションを選択した場合は、VM に対して最も最適化された、コストに関する推奨事項が表示されます。 ただし、VM シリーズで使用可能なオプションの一部のみを選択する場合は、プロセッサのパフォーマンスの数値に合わせながら Azure VM SKU を割り当てるときに、最も最適化されたオプションが推奨事項でスキップされる可能性があります。

Azure VM の評価のプロパティですべての Azure VM ファミリが表示されないのはなぜですか?

これには、次の 2 つの理由が考えられます。

  • 特定のシリーズがサポートされていない Azure リージョンを選択した。 Azure VM の評価のプロパティで表示されるAzure VM ファミリは、選択した Azure の場所、ストレージの種類、予約インスタンスで VM シリーズを使用できるかどうかに基づきます。
  • VM シリーズが評価でサポートされておらず、評価の考慮ロジックに含まれていない。 現在、B シリーズのバースト可能で高速化されたハイ パフォーマンスの SKU シリーズはサポートされていません。 VM シリーズは継続的な更新の努力が続けられており、ここに記載されているシリーズが予定されています。

検出と評価ツールの Azure VM または AVS 評価の数が正しくない

これを修正するには、評価の合計数を選択してすべての評価に移動し、Azure VM または AVS の評価を計算し直します。 その後、検出と評価ツールには、その評価の種類の正しい数が表示されます。

新しい Azure SQL 評価を試してみたい

VMware、Microsoft Hyper-V、物理/ベアメタル環境で実行されている SQL Serverインスタンスとデータベース、および AWS、GCP などの他のパブリック クラウドの IaaS サーバーの検出と評価は、現在プレビュー段階です。 このチュートリアルで作業を開始します。 既存のプロジェクトでこの機能を試す場合は、こちらの記事の前提条件を満たしていることをご確認ください。

新しい Azure App Service 評価を試してみたい

VMware 環境で実行されている.NET Web アプリの検出と評価は、現在プレビュー段階にあります。 このチュートリアルで作業を開始します。 既存のプロジェクトでこの機能を試す場合は、こちらの記事の前提条件を満たしていることをご確認ください。

Azure SQL の評価を作成するときに、一部のサーバーを見ることができません

  • Azure SQL の評価は、SQL インスタンスが検出された場所で実行されているサーバーに対してのみ実行できます。 評価するサーバーと SQL インスタンスが表示されない場合は、検出されるまでしばらく待ってから、評価を作成します。
  • 評価の作成中に以前に作成したグループを表示できない場合は、SQL インスタンスが存在していないすべてのサーバーを、グループから削除します。
  • Azure Migrate で Azure SQL の評価を初めて実行する場合は、サーバーの新しいグループを作成することをお勧めします。

Azure App Service 評価を作成するときに、一部のサーバーを見ることができません

  • Azure App Service 評価は、Web サーバー ロールが検出された実行中のサーバーでのみ行うことができます。 評価したいサーバーが表示されない場合は、検出が完了するまでしばらく待ってから、評価を作成してください。
  • 評価の作成中に以前に作成したグループを表示できない場合は、VMware 以外のサーバーまたは Web アプリが存在していないすべてのサーバーを、そのグループから削除してください。
  • Azure Migrate で Azure App Service の評価を初めて実行する場合は、サーバーの新しいグループを作成することをお勧めします。

インスタンスの対応状態がどのように計算されたかを理解したい

SQL インスタンスの対応性は、対象となる Azure SQL のデプロイの種類 (Azure VM 上の SQL Server、Azure SQL Managed Instance、Azure SQL Database) との機能の互換性チェックが実行された後で計算されます。 詳細情報 を参照してください。

Web アプリの対応状態がどのように計算されたかを理解したい

Web アプリの対応状態は、Web アプリが Azure App Service で正常に実行されるかどうかを判断するための一連の技術チェックを実行して計算されます。 これらのチェックについては、こちらに記載されています。

Azure App Service 評価で、Web アプリが [条件付きで準備できています] または [準備ができていません] とマークされているのはなぜですか?

これは、特定の Web アプリに対して 1 つ以上の技術チェックが失敗した場合に発生する可能性があります。 Web アプリの準備状態を選択して、失敗したチェックの詳細と修復を確認できます。

すべての SQL インスタンスの対応状態が不明とマークされているのはなぜですか?

検出が最近開始され、まだ進行中の場合は、一部またはすべての SQL インスタンスの対応状態が不明と表示されることがあります。 アプライアンスによって環境のプロファイリングが行われるまでしばらく待ってから、評価を再計算することをお勧めします。 SQL の検出は 24 時間ごとに 1 回実行され、最新の構成変更が反映されるまで最大で 1 日待つ必要がある場合があります。

一部の SQL インスタンスの対応状態が不明とマークされているのはなぜですか?

これは、次の場合に発生する可能性があります。

  • 検出がまだ進行中です。 アプライアンスによって環境のプロファイリングが行われるまでしばらく待ってから、評価を再計算することをお勧めします。
  • 検出には、[エラーと通知] で修正する必要がある問題がいくつかあります。

SQL の検出は 24 時間ごとに 1 回実行され、最新の構成変更が反映されるまで最大で 1 日待つ必要がある場合があります。

評価が期限切れ状態になっています

Azure VM または AVS の評価

評価されたグループ内のサーバーに対してオンプレミスでの変更があった場合、その評価は古い評価としてマークされます。 次のプロパティに 1 つ以上の変更があるため、評価は "古い" としてマークされている可能性があります。

  • プロセッサ コアの数
  • 割り当て済みメモリ
  • ブートの種類またはファームウェア
  • オペレーティング システムの名前、バージョン、アーキテクチャ
  • ディスクの数
  • ネットワーク アダプターの数
  • ディスク サイズの変更 (割り当てられた GB)
  • NIC プロパティの更新。 例: MAC アドレスの変更、IP アドレスの追加など。

評価を再計算し、評価に最新の変更を反映してください。

Azure SQL の評価

評価されたグループに含まれるオンプレミスの SQL インスタンスおよびデータベースに変更があった場合、その評価は期限切れとマークされます。

  • SQL インスタンスがサーバーに追加された、またはサーバーから削除された
  • SQL データベースが SQL インスタンスに追加された、または削除された
  • SQL インスタンスのデータベースの合計サイズが、20% より大きく変化した
  • プロセッサ コア数や割り当てられたメモリの変更

評価を再計算し、評価に最新の変更を反映してください。

Azure Migrate により、SQL インスタンスと互換性のある特定の Azure SQL のデプロイの種類が推奨されます。 Microsoft によって推奨されるターゲットに移行すると、移行の全体的な作業量が減ります。 この Azure SQL 構成 (SKU) は、SQL インスタンスと、それによって管理されるデータベースの、パフォーマンス特性を考慮した後で推奨されます。 該当する Azure SQL 構成が複数ある場合は、最もコスト効率の高いものを使用することをお勧めします。 詳細情報 を参照してください。

SQL インスタンスが Azure SQL DB と Azure SQL MI に対応している場合、どのデプロイ ターゲットを選択する必要がありますか?

インスタンスが Azure SQL DB と Azure SQL MI の両方に対応している場合は、Azure SQL 構成の推定コストが低い方のターゲットのデプロイの種類を使用することをお勧めします。

インスタンスが評価の一部であるにもかかわらず、評価に一部のデータベースが表示されません

Azure SQL の評価には、オンライン状態のデータベースのみが含まれます。 それ以外の状態になっているデータベースの対応状態、サイズ設定、コスト計算は無視されます。 そのようなデータベースを評価する場合は、データベースの状態を変更し、しばらくしてから評価を再計算してください。

Azure VM で SQL インスタンスを実行した場合のコストを、Azure SQL Database または Azure SQL Managed Instance での場合と比較したい

VMware、Microsoft Hyper-V、物理またはベアメタル環境全体の目的の SQL サーバーと、AWS、GCP などの他のパブリック クラウドの IaaS サーバーで構成される単一の Azure SQL 評価を作成できます。1 つの評価で、Azure で使用可能なすべての SQL 移行ターゲット (Azure SQL Managed Instance、Azure SQL Database、Azure VM 上の SQL Server) の準備状況、SKU、推定コスト、移行の阻害要因をカバーできます。 その後で、目的のターゲットの評価出力を比較できます。 詳細情報

Azure SQL の評価でストレージ コストが 0 です

Azure SQL Managed Instance では、最初の 32 GB/インスタンス/月のストレージについてはストレージ コストの追加はなく、ストレージが 32 GB 増加するとストレージ コストが追加されます。 詳細については、こちらを参照してください

Azure VMware Solution (AVS) の評価を作成しているときに一部のグループが表示されません

  • AVS の評価は、VMware マシンのみが含まれるグループに対して実行できます。 AVS の評価を実行する場合は、VMware 以外のマシンをグループから削除してください。
  • Azure Migrate で AVS の評価を初めて実行する場合は、VMware マシンの新しいグループを作成することをお勧めします。

Ultra Disk に関するクエリ

Azure Migrate を使用してディスクを Ultra Disk に移行できますか?

不正解です。 現時点では、Azure Migrate と Azure Site Recovery の両方で、Ultra Disk への移行はサポートされていません。 Ultra Disk をデプロイする手順については、こちらを参照してください

Ultra Disk でプロビジョニングされた IOPS とスループットがオンプレミスの IOPS とスループットを超えるのはなぜですか?

Ultra Disk は、公式価格のページに従い、プロビジョニングされたサイズ、プロビジョニングされた IOPS、プロビジョニングされたスループットに基づいて課金されます。 次に例を示します。

200 GiB、20,000 IOPS、1,000 MB/秒の Ultra Disk をプロビジョニングし、20 時間後に削除した場合、256 GiB のディスク サイズ プランにマップされ、20 時間分の 256 GiB、20,000 IOPS、1,000 MB/秒に対して課金されます。

プロビジョニングされる IOPS = (検出されたスループット) * 1024/256

Ultra Disk の推奨事項では待機時間が考慮されますか?

いいえ。現時点では、サイズ設定とコスト計算には、ディスク サイズ、合計スループット、合計 IOPS が使用されます。

Ultra Disk をサポートするすべての VM のサイズが、Ultra Disk でサポートされているすべてのリージョンに存在とは限らないため、このようになる可能性があります。 ターゲット評価リージョンを変更して、このサーバーの VM サイズを取得します。

Azure Government に一部の VM の種類およびサイズが表示されない

評価と移行がサポートされている VM の種類およびサイズは、Azure Government の場所で使用できるかどうかによって異なります。 Azure Government の VM の種類を確認および比較できます。

サーバーのサイズが変更しました。 評価を再実行できますか?

Azure Migrate アプライアンスは、オンプレミス環境の情報を継続的に収集します。 評価はオンプレミス サーバーのポイントインタイム スナップショットです。 評価するサーバーの設定を変更する場合は、[再計算] オプションを使って最新の変更で評価を更新してください。

マルチテナント環境でサーバーを検出する方法はありますか?

  • VMware: 環境がテナント間で共有されている場合、あるテナントのサーバーが別のテナントのサブスクリプションで検出されないようにするには、検出したいサーバーだけにアクセスできる VMware vCenter Server 資格情報を作成します。 次に、Azure Migrate アプライアンスで検出を開始するときに、これらの資格情報を使用します。
  • Hyper-V: 検出には Hyper-V ホストの資格情報が使用されます。 サーバーが同じ Hyper-V ホストを共有している場合、現在、検出を分離する方法はありません。

vCenter Server は必要ですか?

はい。VMware 環境で検出を実行するには、Azure Migrate に vCenter Server が必要です。 vCenter Server で管理されていない ESXi ホストの検出は、Azure Migrate でサポートされていません。

Azure VM の評価にはどのようなサイズ設定オプションがありますか?

オンプレミスに合わせたサイズ設定では、Azure Migrate がサーバーのパフォーマンス データを考慮せずに評価を行います。 Azure Migrate は、オンプレミスの構成に基づいて VM のサイズを評価します。 パフォーマンスベースのサイズ設定では、使用率データに基づいてサイズが設定されます。

たとえば、50% の CPU 使用率と 50% のメモリ使用率で 4 コアと 8 GB のメモリを備えたオンプレミスのサーバーの場合は、次のようになります。

  • オンプレミスのサイズ設定では、4 コアで 8 GB のメモリを備えた Azure VM SKU が推奨されます。
  • パフォーマンスベースのサイズ設定では、使用率が考慮されるため、2 コアで 4 GB のメモリを備えた VM SKU が推奨されます。

同様に、ディスクのサイズ設定は、サイズ設定基準とストレージの種類に依存します。

  • サイズ設定基準が "パフォーマンスベース" で、ストレージの種類が自動の場合、Azure Migrate では、ターゲット ディスクの種類 (Standard、Premium または Ultra Disk) を識別するときに、ディスクの IOPS とスループットの値が考慮されます。
  • サイズ設定基準が "オンプレミス" でストレージの種類が Premium の場合、Azure Migrate ではオンプレミスのディスクのサイズに基づき、Premium ディスク SKU が推奨されます。 オンプレミスに合わせたサイズ設定で、ストレージの種類が Standard、Premium または Ultra Disk である場合は、ディスクのサイズ設定に同じロジックが適用されます。

パフォーマンス履歴と使用率は、Azure VM の評価のサイズ設定に影響しますか?

はい。パフォーマンス履歴および使用率は Azure VM の評価でのサイズ設定に影響します。

パフォーマンス履歴

Azure Migrate では、パフォーマンスベースのサイズ変更の場合にのみ、オンプレミス マシンのパフォーマンス履歴が収集され、それを使用して Azure での VM のサイズとディスクの種類が推奨されます。

  1. アプライアンスによりオンプレミス環境が継続的にプロファイルされて、20 秒ごとにリアルタイムの使用率データが収集されます
  2. このアプライアンスでは、収集された 20 秒のサンプルがロールアップされ、それを使用して 15 分ごとに 1 つのデータ ポイントが作成されます。
  3. データ ポイントを作成するために、アプライアンスではすべての 20 秒のサンプルからピーク値が選択されます。
  4. データ ポイントは、アプライアンスから Azure に送信されます。

稼働率

Azure で評価を作成する場合は、設定されているパフォーマンスの期間とパフォーマンス履歴の百分位値に応じて、Azure Migrate で有効な使用率値が計算され、その値がサイズ設定に使用されます。

たとえば、パフォーマンスの期間を 1 日に設定し、百分位値を第 95 百分位値に設定すると、Azure Migrate は、過去 1 日間にコレクターから送信された 15 分のサンプル ポイントを昇順で並べ替えます。 第 95 百分位値を有効な使用率として選択します。

第 95 百分位値を使用すると、外れ値が無視されます。 Azure Migrate で第 99 百分位を使用している場合は、外れ値が含まれる可能性があります。 期間中のピーク使用率を選択し、外れ値を見逃さないようにするには、第 99 百分位を使用するように Azure Migrate を設定する必要があります。

インポートベースの評価は、探索ソースをアプライアンスとした評価とどのように異なりますか?

インポートベースの Azure VM の評価は、CSV ファイルを使用して Azure Migrate にインポートされたマシンで作成された評価です。 インポートする必要があるフィールドは、サーバー名、コア、メモリ、オペレーティング システムの 4 つのみです。 以下のことに注目してみてください。

  • ブートの種類のパラメーターについてのインポートベースの評価では、準備基準はあまり厳格ではありません。 ブートの種類が指定されていない場合は、マシンのブートの種類は BIOS であると見なされ、マシンは条件付き対応としてマークされません。 検出ソースをアプライアンスとした評価では、ブートの種類が見つからない場合、準備は条件付き対応としてマークされます。 この準備状況の計算の違いは、インポートベースの評価が行われるときに、移行計画の初期段階でユーザーがマシンに関するすべての情報を持っていない可能性があるためです。
  • パフォーマンスベースのインポート評価では、ユーザーから与えられた使用率の値を使用して、適切なサイズ計算を行います。 使用率の値はユーザーが指定するので、パフォーマンス履歴百分位の使用率のオプションは、評価プロパティで無効になっています。 検出ソースをアプライアンスとした評価では、選択した百分位値はアプライアンスによって収集されたパフォーマンス データから取得されます。

インポートベースの AVS の評価で、推奨される移行ツールが不明とマークされるのはなぜですか?

CSV ファイルを介してインポートされたマシンの場合、AVS の評価の既定の移行ツールは不明です。 ただし VMware マシンの場合は、VMware Hybrid Cloud Extension (HCX) ソリューションを使用することをお勧めします。 詳細については、こちらを参照してください

次のステップ

Azure Migrate の概要を確認します。