Windows Server 2016の製品ライフサイクルとサポート終了日（End of LifeCycle《EOL》、End of Support《EOS》）である2027年1月12日までのカウントダウンが進んでいます。この連載シリーズのテーマの1つはAzureへの移行です。今回から、前回紹介した「Azure Migrate」を使用したオンプレミスのHyper-V仮想マシン（VM）のAzure VMへの移行を実際に行ってみます。

まずはアプライアンスを使用しないシンプルな移行から

検証環境: 移行元のHyper-Vホストと移行対象のVM

　今回は、Windows Server 2016のHyper-Vホスト上で動作する2台の第2世代VMを移行対象にします。それぞれ、Windows Server 2016 Server CoreとUbuntu 24.04 LTSがゲストOSとしてインストールされているVMです（画面1）。ちなみに、Azure Migrateは、Windows Server 2012 R2以降のHyper-Vホスト上にあるVMの移行をサポートしています。

　Azure VMの第2世代VMでサポートされる、WindowsおよびLinuxゲストについては、以下のドキュメントで確認できます。

Azure での第 2 世代 VM のサポート｜Azure（Microsoft Learn）

画面1　Azure Migrateを使用してAzure VMに移行するWindows Server 2016 Hyper-V上の2台のVM

　移行対象としてWindows Server 2016のVMを対象としたのには理由があります。Azure VMに移行することで、2027年1月12日のサポート終了後も、追加の設定やコストなしで最大3年間、セキュリティ更新プログラムを受け取ることができる、Windows Server 2016向けの「拡張セキュリティ更新プログラム（Extended Security Update《ESU》」の対象になるはずだからです（まだ公式の発表はありません）。Azure VMに移行することで、最大3年間、さらに時間的猶予を得ることができるのです。

　Ubuntu 24.04 LTSのVMを対象とした理由は、Linux VMの移行の一般的な手順を、まだ試したことのない私自身が確認したかったからです。

ハードウェア依存の排除（TPMとディスク暗号化の無効化）

　Azure Migrateに限らず、Hyper-V VMの（仮想）ハードウェアそのままをAzure VMにそのまま移行することはできません。Hyper-VとAzure IaaSは高い互換性はあるものの同じものではないからです。そのため、Hyper-Vホスト間でVMを移行するのとは全く異なります。VMの器である（仮想）ハードウェアが完全に変更になるため、ハードウェア依存のデバイスやその設定は移行できません。Hyper-V VMのハードウェア依存のハードウェアには、vTPMとも呼ばれるVMのトラステッドプラットフォームモジュールがあります。

　以下の連載記事や先月開催のセミナーで紹介したように、Hyper-Vホスト間であれば、vTPMが有効なVMを別ホストに移行することは可能です。Azure VMではvTPMデバイス（およびセキュアブート）を、トラステッド起動をサポートする第2世代VMのサイズファミリでサポートしていますが、それはAzure Iaasが提供する別のハードウェアであるため、既存のHyper-V VMのvTPMの設定とその内容をAzure VMに移行することはできないのです。

vol.155　Hyper-V環境の移行: 移行VMのvTPMエラー問題｜Windows Server 2016 EOSまであと421日
【アーカイブ】セイテク・シス管道場　第6回　最新Hyper-V環境へのVM移行とHyper-Vホストに迫る2026年問題｜かつて山市良とよばれていたおじさんの定期セミナー

　Windows VMでvTPMを使用したBitLockerによるOSディスクの暗号化が有効になっている場合は、暗号化保護を解除したうえで、vTPMをオフにしておきます（画面2）。Linux VMの場合は、LUKS（Linux Unified Key Setup）などによる、OSディスクの暗号化をオフにしてください。トラステッド起動をサポートする第2世代VMでは、vTPMを使用できるので、BitLockerやLUKSによる暗号化を移行後にセットアップすることは可能ですが、Azureのマネージドディスクでは「サーバー側暗号化（Server-Side Encryption《SSE》」が既定で有効になり、Azureが等価的に暗号化/復号を行うため、通常、VMのゲスト側で暗号化する必要性はありません。なお、AzureではSSEの他に、BitLocker技術を用いる「Azure Disk Encryption（ADE）」を提供していますが、ADEは2028年9月15日に廃止される予定です。

画面2　移行元のHyper-V VMでBitLockerが有効になっている場合は、保護を解除し、TPMをオフにしておく

ネットワーク設定はDHCPによる自動割り当てに

　Azureの仮想ネットワーク（vNET）のサブネットに接続されるAzure VMは、動的または静的にプライベートIPアドレス（オプションでパブリックIPアドレス）を割り当てることができます。しかし、どちらの場合もIPアドレスの割り当てはAzure DHCPサーバーを使用してAzureによって管理されます。静的なIPアドレスの割り当てを行うには、Azure VMのゲストOSで行わず、Azureポータル、Azure PowerShell（Set-AzNetworkInterfaceIpConfig）、またはAzure CLI（az network nic ip-config）を使用する必要があります。

　Azure VMに移行するWindows、Linux VMのネットワークは、DHCPを使用してネットワーク設定（IPアドレス、サブネットマスク、デフォルトゲートウェイ、優先/代替DNSサーバー）を自動取得するように構成しておく必要があります。

リモート管理用接続手段を確保する

　Azure VMには、ローカルコンソールにアクセスする手段が提供されません。そのため、ローカルコンソールへの対話ログオンやWindows回復環境（Windows Recovery Environment《WinRM》）との対話、BIOS/UEFI画面へのアクセスはできません。*1
*1　ブート診断によるローカルコンソール表示およびシリアルコンソールによる対話操作は可能。シリアルコンソール経由でWindows VMははEMS（緊急管理サービス）のSAC（Serial Administration Consol）に接続、Linux VMはttyS0ローカルコンソールに接続可能。

　Azure VMに移行するとローカルコンソールは利用できなくなるため、移行前にWindows VMの場合はリモートデスクトップ接続またはSSH接続（Windows Server 2019移行はOpenSSH Serverを標準搭載）、Linux VMはSSH接続などの管理用リモート接続手段を有効にしておきます（画面3）。なお、SSH接続はセキュリティを強化するために、パスワード認証ではなく、公開鍵認証にしてください。

画面3　ネットワークはDHCP設定にし、リモートデスクトップ（RDP）接続やSSH接続などを有効化し、管理用のリモート接続手段を確保しておく

参考情報として

　Azure VMで最適に実行するためのWindowsやLinuxゲストの構成については、Azureへのアップロード用にカスタムイメージを準備する手順を説明した以下のドキュメントも参考になります。ただし、この手順は汎用イメージをアップロードしてAzure VMとしてデプロイするためのものであり、Azure Migrateでの移行に必要な手順では全くありません。リモートデスクトップ設定（レジストリによる有効化、キープアライブ設定や再接続オプションなど）、Windowsファイアウォール規則、Linux VMにはcloud-initが必要なこと（Ubuntuには標準搭載）、Linuxディストリビューション固有の要件などを確認しておくと、Azure Migrateによる移行時のトラブル解決の糸口になるかもしれないという意味で紹介したまでです。

Azure にアップロードする Windows VHD または VHDX を準備する｜Azure（Microsoft Learn）
Azure でのイメージング用に Linux を準備する｜Azure（Microsoft Learn）
Azure での仮想マシンに対する cloud-init のサポート｜Azure（Microsoft Learn）

シーズン1目次｜Windows Server 2016 EOSまであとX日 シーズン2（1）｜(2)｜(3)｜(4)｜(5)｜(6)｜(7)｜(8)｜(9)