VMware のエージェントレス移行の準備をする

この記事では、移行と最新化ツールを使用して、エージェントレス移行> メソッドを使用して VMware VM をAzure<した場合に実行される変更の概要について説明します。

注意事項

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

オンプレミスの VM をAzureに移行する前に、VM をAzureする準備をするためにいくつかの変更が必要になる場合があります。 これらの変更は、移行された VM がAzureで正常に起動し、Azure VM への接続を確立できるようにするために重要です。 Azure Migrateは、Linux と Windows の両方で、次のオペレーティング システム バージョンに対するこれらの構成変更を自動的に処理します。 このプロセスは "ハイドレーション" と呼ばれます。

注

エージェントレス移行でオペレーティング システムのメジャー バージョンがサポートされている場合、すべてのマイナー バージョンとカーネルは自動的にサポートされています。

ハイドレーションでサポートされているオペレーティング システムのバージョン

  • Windows Server 2008 以降
  • Red Hat Enterprise Linux 10.x、9.5、9.x、8.x、7.9、7.8、7.7、7.6、7.5、7.4、7.3、7.2、7.1、7.0、6.x
  • CentOS Stream (セントオーエス ストリーム)
  • SUSE Linux Enterprise Server 15 SP6、15 SP5、15 SP4、15 SP3、15 SP2、15 SP1、15 SP0、12、11 SP4、11 SP3
  • Ubuntu 22.04、21.04、20.04、19.04、19.10、18.04 LTS、16.04 LTS、14.04 LTS
  • Kali Linux (2016、2017、2018、2019、2020、2021、2022)
  • Debian 13、12、11、10、9、8、7
  • Oracle Linux 10、9、8、7.7-CI、7.7、6
  • Alma Linux 10.x、8.x、9.x
  • Rocky Linux 10.x、8.x、9.x

また、この記事を使用して、上記に記載されていないオペレーティング システムのバージョンのAzureへの移行用に VM を手動で準備することもできます。 このような変更には、だいたい次のものがあります。

  • 必要なドライバーの存在を検証する
  • シリアル コンソールを有効にする
  • ネットワーク設定の構成
  • VM ゲスト エージェントをインストールする

ハイドレーション プロセス

移行された VM がAzureで正常に機能するように、移行前に VM 構成にいくつかの変更を加える必要があります。 Azure Migrateは、hydration プロセスを使用して、これらの構成変更を処理します。 ハイドレーション プロセスは、上記でサポートAzureオペレーティング システムのバージョンに対してのみ実行されます。 上の一覧にない他のオペレーティング システムのバージョンについては、移行する前に、必要な変更を手動で実行することが必要な場合があります。 必要な変更を行わずに VM を移行すると、VM が起動しない、または移行された VM に接続できないおそれがあります。 次の図は、Azure Migrateがハイドレーション プロセスを実行することを示しています。

ハイドレーションの手順

ユーザーが Test Migrate または Migrate をトリガーすると、Azure Migrateはハイドレーション プロセスを実行して、オンプレミスの VM を Azure への移行用に準備します。 ハイドレーション プロセスを設定するために、Azure Migrateは一時的なAzure VM を作成し、ソース VM のディスクをアタッチして変更を実行し、ソース VM をAzureの準備にします。 移行プロセス中に作成される一時的なAzure VMは、中間段階のVMであり、最終的な移行先のVMが作成される前に使用されます。 一時 VM は、マーケットプレースの OS イメージのいずれかを使用して、同様の OS の種類 (Windows/Linux) で作成されます。 オンプレミス VM がWindows実行されている場合、変更を実行するために、オンプレミス VM のオペレーティング システム ディスクがデータ ディスクとして一時 VM に接続されます。 Linux サーバーの場合、オンプレミス VM に接続されているすべてのディスクは、一時Azure VM にデータ ディスクとして接続されます。

Azure Migrateは、一時 VM をホストするネットワーク インターフェイス、新しい仮想ネットワーク、サブネット、およびネットワーク セキュリティ グループ (NSG) を作成します。 これらのリソースは、お客様のサブスクリプションに作成されます。 ネットワーク成果物の作成を妨げるポリシーが競合している場合、Azure Migrateは、レプリケーション ターゲット設定オプションの一部として提供される仮想ネットワークとサブネットに一時的なAzure VM の作成を試みます。

仮想マシンが作成されると、Azure Migrateは、Azure仮想マシン REST API を使用して一時 VM で Custom スクリプト拡張機能を呼び出します。 カスタム スクリプト拡張機能ユーティリティは、一時Azure VM に接続されているオンプレミスの VM ディスクで、Azure準備に必要な構成を含む準備スクリプトを実行します。 準備スクリプトは、Azure Migrate所有ストレージ アカウントからダウンロードされます。 仮想ネットワークのネットワーク セキュリティ グループ規則は、一時的なAzure VM がスクリプトを呼び出すためにAzure Migrateストレージ アカウントにアクセスできるように構成されます。

移行の手順

注

Hydration VM ディスクはカスタマー マネージド キー (CMK) をサポートしていません。 プラットフォーム マネージド キー (PMK) が既定のオプションです。

ハイドレーション プロセスの間に行われる変更

準備スクリプトにより、移行されるソース VM の OS の種類に基づいて、次の変更が実行されます。 このセクションをガイドとして使用し、ハイドレーションでサポートされていないオペレーティング システムの移行用に VM を手動で準備することもできます。

Windows サーバーで実行された変更

  1. Windows OS ボリュームを検出して準備します

    関連する構成の変更を実行する前に、準備スクリプトによって、正しい OS ディスクが移行用に選択されているかどうかが検証されます。 準備スクリプトにより、システムで認識できるすべてのアタッチされたボリュームが走査され、SYSTEM レジストリ ハイブ ファイル パスが調べられて、ソース OS のボリュームが検索されます。

    このステップでは、次のアクションが実行されます。

    • 一時的な VM にアタッチされている OS ディスク上の各パーティションがマウントされます。

    • パーティションをマウントした後、\Windows\System32\Config\System レジストリ ファイルを探します。

    • ファイルが見つからない場合、そのパーティションはマウント解除され、適切なパーティションで検索が続行されます。

    • ファイルがどのパーティションにも存在しない場合は、正しくない OS ディスクが選択されているか、OS ディスクが破損しているおそれがあることを示します。 Azure Migrateは、適切なエラーで移行プロセスに失敗します。

    注

    移行用にサーバーを手動で準備している場合、このステップは関係ありません。

  2. 起動と接続に関連する変更を行う

    ソース OS ボリューム ファイルが検出されると、準備スクリプトは、一時Azure VM のレジストリ エディターに SYSTEM レジストリ ハイブを読み込み、次の変更を実行して VM の起動と接続を確保します。 OS のバージョンがハイドレーションでサポートされていない場合は、これらの設定を手動で構成する必要があります。

    1. 必要なドライバーの存在を検証する

      必要なドライバーがインストールされていて、ブート開始時に読み込まれるように設定されていることを確認します。 これらのWindows ドライバーを使用すると、サーバーはハードウェアやその他の接続されているデバイスと通信できます。

      • IntelIde.sys
      • Atapi
      • Storflt
      • Storvsc
      • VMbus

    2. 記憶域ネットワーク (SAN) のポリシーを "すべてをオンライン" に設定する

      これにより、Azure VM 内のWindows ボリュームで、オンプレミス VM と同じドライブ文字の割り当てが使用されるようになります。 既定では、Azure VM には、一時ストレージとして使用するドライブ D: が割り当てられます。 このドライブが割り当てられると、アタッチされている他のストレージ ドライブに割り当てられている文字が 1 文字ずつ後ろにずれることになります。 この自動割り当てを防ぎ、Azureが次の空きドライブ文字をその一時ボリュームに割り当てるには、記憶域ネットワーク (SAN) ポリシーを [Online All] に設定します。

      この設定を手動で構成するには:

      • オンプレミスのサーバーで、昇格された特権を使用してコマンド プロンプトを開き、「diskpart」と入力します。

        手動で構成

      • 「SAN」と入力します。 ゲスト オペレーティング システムのドライブ文字が維持されていない場合には、Offline All または Offline Shared が返されます。

      • DISKPART プロンプトで、「SAN Policy=OnlineAll」と入力します。 この設定により、ディスクがオンラインになり、両方のディスクの読み取りと書き込みが可能になります。

        管理者コマンド プロンプトでの diskpart オンライン ポリシー

  3. DHCP の開始の種類を設定する

    準備スクリプトでは、DHCP サービスの開始の種類も "自動" に設定されます。 これにより、移行された VM で、移行後に IP アドレスを取得して接続を確立できるようになります。 DHCP サービスが構成されていて、状態が実行中であることを確認します。

    DHCP の開始の種類の設定

    DHCP スタートアップ設定を手動で編集するには、Windows PowerShell で次の例を実行します。

    Get-Service -Name Dhcp
Where-Object StartType -ne Automatic
Set-Service -StartupType Automatic

  4. VMware Tools を無効にする

    Azure内の VM に必要がないため、"VMware Tools" サービスの開始タイプが存在する場合は無効にします。

    注

    Windows Server 2003 VM に接続するには、Hyper-V Integration Services を Azure VM にインストールする必要があります。 Windows Server 2003 コンピューターでは、既定ではインストールされていません。 こちらの記事を参照し、移行用にインストールして準備します。

  5. Windows Azure ゲスト エージェントをインストールします

    Azure Migrateは、Azure Fabric コントローラーとの仮想マシン (VM) の対話を管理する安全で軽量なプロセスである、Microsoft Azure仮想マシン エージェント (VM エージェント) のインストールを試みます。 VM エージェントには、VM のデプロイ後の構成 (ソフトウェアのインストールや構成など) を有効にする仮想マシン拡張機能Azure有効にして実行する主な役割があります。 Azure Migrateは、Windows VM エージェントを Windows Server 2008 R2 以降のバージョンに自動的にインストールします。

    Windows VM エージェントは、Windows インストーラー パッケージを使用して手動でインストールできます。 Windows VM エージェントを手動でインストールするには、 VM エージェント インストーラーをダウンロードします。 GitHub Windows IaaS VM エージェント リリースで特定のバージョンを検索することもできます。 VM エージェントは、Windows Server 2008 (64 ビット) 以降でサポートされています。

    Azure VM エージェントが正常にインストールされたかどうかを確認するには、Task Manager に移動し、Details タブを選択し、プロセス名 WindowsAzureGuestAgent.exe を探します。 このプロセスの存在は、VM エージェントがインストールされていることを示します。 PowerShell を使用して VM エージェントを検出することもできます。

    Azure VM エージェントの正常なインストール

    上記の変更が行われた後、システム パーティションがアンロードされます。 これで、VM を移行する準備ができました。 Windowsサーバーの変更について詳しく知る

Linux サーバーで行われる変更

  1. Linux OS パーティションを検出してマウントする

    関連する構成の変更を実行する前に、準備スクリプトによって、正しい OS ディスクが移行用に選択されているかどうかが検証されます。 スクリプトにより、すべてのパーティション、その UUID、マウント ポイントに関する情報が収集されます。 スクリプトによって、認識されるすべてのパーティションが走査され、/boot および /root パーティションが見つけられます。

    このステップでは、次のアクションが実行されます。

    • /root パーティションを検出する:
      • 認識される各パーティションがマウントされて、etc/fstab が検索されます。
      • fstab ファイルが見つからない場合、そのパーティションはマウント解除され、適切なパーティションで検索が続行されます。
      • fstab ファイルが見つかった場合は、fstab の内容が読み取られて、ルート デバイスが特定され、ベース マウント ポイントとしてマウントされます。
    • /boot と他のシステム パーティションを検出する:
      • fstab の内容を使用して、/boot が別のパーティションであるかどうかが判断されます。 別のパーティションの場合は、fstab の内容からブート パーティションのデバイス名が取得されるか、ブート フラグを持つパーティションが検索されます。
      • 次に、スクリプトによって、/boot と、chroot jail に必要なルート ファイルシステム ツリーを構築するために必要な "/mnt/azure_sms_root" 上の他のパーティションが、検出されてマウントされます。 他の必要なパーティションとしては、/boot/grub/menu.lst、/boot/grub/grub.conf、/boot/grub2/grub.cfg、/boot/grub/grub.cfg、/boot/efi (UEFI ブート用)、/var、/lib、/etc、/usr などがあります。

  2. OS のバージョンを検出する

    ルート パーティションが検出された後、スクリプトにより、以下のファイルを使用して、Linux オペレーティング システムのディストリビューションとバージョンが特定されます。

    • RHEL: etc/redhat-release
    • OL: etc/oracle-release
    • SLES: etc/SuSE-release
    • Ubuntu: etc/lsb-release
    • Debian: etc/debian_version

  3. Linux Integration Services Hyper-Vインストールし、カーネル イメージを再生成します

    次の手順では、初期 ramdisk に必要なHyper-V ドライバー (hv_vmbus、hv_storvsc、hv_netvsc) が含まれるように、カーネル イメージを検査し、Linux init イメージを再構築します。 init イメージを再構築すると、VM がAzureで起動します。

    Azureは、Hyper-V ハイパーバイザーで実行されます。 そのため、Linux では、Azureで実行する特定のカーネル モジュールが必要です。 Linux イメージを準備するには、少なくとも hv_vmbus と hv_storvsc のカーネル モジュールを初期 RAM ディスクで使用できるように、initrd をリビルドする必要があります。 initrd または initramfs イメージの再構築のためのメカニズムは、ディストリビューションによって異なる場合があります。 適切な手順については、使用しているディストリビューションのドキュメントまたはサポートを参照してください。 一例として、mkinitrd ユーティリティを使用した initrd のリビルドを次に示します。

    1. システムにインストールされているカーネルの一覧を検索します (/lib/modules)

    2. モジュールごとに、Hyper-V ドライバーが既に含まれているかどうかを調べます。

    3. いずれかのドライバーがない場合は、必要なドライバーを追加し、対応するカーネル バージョンのイメージを再生成します。

      注

      Hyper-V ドライバーは既定で組み込まれているため、この手順は Ubuntu および Debian VM には適用されない場合があります。 変更に関する詳細については、こちらを参照してください。

      Initrd のリビルドに関して説明する例

      • 既存の initrd イメージをバックアップします
       cd /boot
 sudo cp initrd-`uname -r`.img  initrd-`uname -r`.img.bak
      • hv_vmbus と hv_storvsc のカーネル モジュールを使用して initrd を再構築します。
         sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f initrd-`uname -r`.img `uname -r`

    Linux ディストリビューションの新しいバージョンには、ほとんどの場合、既定でこれが含まれています。 示したものを除くすべてのバージョンについて、これが含まれていない場合は、前述の手順を使用して手動でインストールします。

  4. Azure シリアル コンソールのログを有効化する

    その後、スクリプトはAzureシリアルコンソールのログ記録を有効にするために変更を加えます。 コンソール ログを有効にすると、Azure VM での問題のトラブルシューティングに役立ちます。 Linux 用 Azure シリアル コンソールの詳細については Azure Linux 用シリアル コンソール - Virtual Machines | Microsoft Docs。

    GRUB または GRUB2 のカーネル ブート ラインを変更して次のパラメーターを含め、すべてのコンソール メッセージが最初のシリアル ポートに送信されるようにします。 これらのメッセージは、問題のデバッグにAzureサポートを役立てることができます。

     console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300

    また、次のパラメーターがある場合、それらを削除することをお勧めします。

    rhgb quiet crashkernel=auto

    具体的な変更については、こちらの記事を参照してください。

  5. 接続に関するネットワークの変更

    OS のバージョンに基づいて、スクリプトにより、移行された VM への接続に必要なネットワークの変更が行われます。 それらの変更を次に示します。

    1. udev ルールを移動 (または削除) して、イーサネット インターフェイスの静的ルールが生成されないようにします。 これらのルールは、Azureで仮想マシンを複製するときに問題を引き起こします。

      RedHat サーバーの例

         sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules
   sudo rm -f /etc/udev/rules.d/70-persistent-net.rules

    2. 必要に応じて、ネットワーク マネージャーを削除します。 ネットワーク マネージャーは、いくつかの OS バージョンの Azure Linux エージェントに干渉する可能性があります。 RedHat および Ubuntu のディストリビューションを実行しているサーバーでは、これらの変更を行うことをお勧めします。

    3. 次のコマンドを実行して、このパッケージをアンインストールします。

      RedHat サーバーの例

         sudo rpm -e --nodeps NetworkManager

    4. 既存の NIC の設定をバックアップし、DHCP の設定を使用して eth0 NIC 構成ファイルを作成します。 これを行うため、スクリプトによって /etc/sysconfig/network-scripts/ifcfg-eth0 ファイルが作成または編集されて、次のテキストが追加されます。

      RedHat サーバーの例

         DEVICE=eth0
   ONBOOT=yes
   BOOTPROTO=dhcp
   TYPE=Ethernet
   USERCTL=no
   PEERDNS=yes
   IPV6INIT=no
   PERSISTENT_DHCLIENT=yes
   NM_CONTROLLED=yes

    5. 次のように、/sysconfig/network ファイルをリセットします。

      RedHat サーバーの例

         NETWORKING=yes
   HOSTNAME=localhost.localdomain

  6. fstab の検証

    Azure Migrateは fstab ファイルのエントリを検証し、fstab エントリを永続ボリューム識別子 (UUID) に置き換えます。 これにより、アタッチされているシステムに関係なく、ドライブおよびパーティションの名前が一定に維持されます。

    • デバイス名が標準的なデバイス名 (/dev/sdb1 など) の場合は、次のようになります。
      • ルート パーティションまたはブート パーティションの場合は、UUID に置き換えられます。
      • パーティションが、同じディスク上の標準パーティションとしてのルート パーティションまたはブート パーティションと共存している場合は、それが UUID に置き換えられます。
    • デバイス名が UUID/LABEL/LV の場合は、変更は行われません。
    • ネットワーク デバイス (nfs、cifs、smbfs など) の場合は、スクリプトによってエントリがコメント化されます。 それにアクセスするには、同じコメントを解除し、Azure VM を再起動します。

  7. Linux Azure ゲスト エージェントをインストールします

    Azure Migrate は、セキュアで軽量なプロセスとして Linux と FreeBSD のプロビジョニングや Azure Fabric コントローラーとの VM の対話を管理する Microsoft Azure Linux エージェント (waagent) をインストールしようとします。 Linux エージェントにより Linux と FreeBSD IaaS のデプロイで有効になる機能の詳細については、こちらを参照してください。

    Linux VM エージェントをインストールするために必要なパッケージの一覧を確認します。 Azure Migrateは、RHEL 10.x、9.x、8.x/7.x/6.x、Ubuntu 14.04/16.04/18.04/19.04/19.10/20.04 用に Linux VM エージェントを自動的にインストールします。 VMware 移行のエージェントレス方式を使用する場合は、SUSE 15 SP0/15 SP1/12、Debian 13/12/11/10/9/8/7、Oracle 10/9/8/7/6。 他の OS バージョンについては、Linux エージェントの手動インストール手順に従ってください。

    このコマンドを使用して、Azure Linux エージェントのサービスの状態を確認して、実行されていることを確認できます。 サービス名は walinuxagent や waagent のようになります。 ハイドレーションの変更が完了すると、スクリプトによって、マウントされているすべてのパーティションのマウントが解除され、ボリューム グループが非アクティブ化された後、デバイスがフラッシュされます。

       sudo vgchange -an <vg-name>
   sudo lockdev –flushbufs <disk-device-name>

    Linux サーバーの変更に関する詳細を参照してください。

一時的な VM をクリーンアップする

必要な変更が実行されると、Azure Migrateは一時 VM をスピンダウンし、接続されている OS ディスク (およびデータ ディスク) を解放します。 これにより、"ハイドレーション プロセス" の終了がマークされます。

その後、変更された OS ディスクと、レプリケートされたデータを含むデータ ディスクが複製されます。 ターゲット リージョンに新しい仮想マシンが作成され、仮想ネットワーク、サブネット、複製されたディスクが仮想マシンにアタッチされます。 これにより、移行プロセスの完了がマークされます。

詳細情報

  • Azure.
  • Last updated on