ESXi環境からHyper-V環境へ仮想マシンを移行してみる
世の中、ESXiユーザーは非常に多いですが、昨今のBroadcomのドタバタを受けて仮想化環境をESXiではなく、NutanixやHyper-V環境に移行する話が増えているように感じます。また、これを機にパブリッククラウドに移行するケースもかなり多いのではないかと思います。
身近でESXiからHyper-Vに移行しようと思うけど、、、という話をよく聞くので、折角だから移行の検証をしてみようと思い、実際に試した内容を書いていこうと思います。
移行にあたってはバックアップソフトウェアであるVeeamを使っています。他にもやり方はありますが、Veeamユーザーはかなり多い印象があり、私も検証用途でよく使っているので取っつきやすいのではないかと思い、今回はVeeamをベースに検証しています。
で、単にVeeamを使うだけはなぁと思って、ちょうどHyper-V環境に展開したバックアップデータを格納する専用ストレージであるData Domainの仮想アプライアンス（通称DDVE）があるので、 Veeamのバックアップリポジトリとして、このDDVEを活用したいと思います。
このDDVEのセットアップの仕方について知りたい方は以下をご覧ください。
環境
以下を準備済みです。
移行元のホストとしてESXi環境およびESXi上の仮想マシン
移行先のホストとしてHyper-V環境
Veeam Backup & Replicationをインストールしたサーバー
移行先となるHyper-V環境はWindows Server 2025ベースでStorage Spaces Directを有効化した、いわゆるAzure Stack HCI環境を用意しています。
Hyper-V環境およびVeeamについて、これらの構築手順についてはここでは記載しません。すでにこれら環境が準備できていることを前提としています。
※多少、準備となる設定については記載します。
手順
DDVEをVeeamに登録する
バックアップ先としてDDVEを指定したいと思います。移行作業とは直接関係ないので、この設定は必要のないなと思う場合は飛ばしてください。
Veeamの管理画面を開き、左下のリンクからBackup Infrastructureを押して以下のような画面を出します。
画面の余白で右クリックしてレポジトリとして追加をします。
DDVEを含むData Domainは重複排除が効く専用ストレージとして分類されているため、重複排除ストレージアプライアンスを選択します。
Data Domainというのが確認できますね。こちらを選択します。
ウィザード形式で設定を進めます。まずレポジトリの名前を付けます。
DDVEのホスト名を入力します。
VeeamがDDVEに接続するため認証情報を入力します。
DDVEには接続しますが、DDVE全体を管理・操作するわけではなく、あくまでDDVEがバックアップサーバー用に用意した論理的なスペース（Storage Unit）に対してアクセスをすることになるため、ここではこのStorage Unitに対するアクセス権を持ったユーザーを指定することになります。
以下のような形でCredentialsが入力できれば問題ありません。
前の操作で問題なく認証が通れば、以下のようにStorage Unitの設定を行う画面に進みます。
表示されたStorageUnitを選択します。
もしも利用しようとしているStorage Unitが表示されてこない場合は、DD System Managerを開き、Mtree設定でStorage Unitの情報を確認したり、作成したUserを確認してみるとよいかと思います。
以下のような状態であることを確認して、先に進みます。
ファイル レベルおよびアプリケーションアイテムの復元に使用するマウント サーバーの設定をします。バックアップレポジトリ取得されたバックアップファイルから仮想マシンのディスクをこのマウントサーバーにマウントするための設定となります。
バックアップリポジトリの設定とバックアップ リポジトリ サーバーにインストールされるコンポーネントのリストが表示されます。
チェックがすべて通ったことを確認します。
以下のようにSummaryが表示されれば完了となります。
以下のようにRepositoryにDDVEが登録されればOKです。
Veeam上にHyper-V環境を登録する
Veeamの管理画面上にHyper-Vホストを登録します。上でも記載しましたが、今回登録するHyper-VホストはWindows ServerベースのAzure Stack HCI環境になります。
Veeamの管理画面で、画面左下のメニューからBackup Infrastractureを選択し以下の画面を表示します。
ツリーの中にあるManaged Servers - Hyper-Vを表示します。
Azure Stack HCI環境なのでクラスタ名を入力します。Standaloneホストであれば、ホスト名を入力します。
TypeではHyper-Vクラスタを選択します。
クラスタを登録するための認証情報を入力します。
クラスタ環境下のHyper-Vホストが表示されます。以下の通り、この環境は２ノード構成となります。
数分待ちます。この間、各ホストにHyper-V用のパッケージがインストールされます。
サマリーが表示されます。
以下のようにクラスタが登録されました。
今回移行元となるESXiサーバーのVeeam上への登録手順については記載しておりませんが、Veeamの画面上でManaged ServersのVMware vSphereの箇所から上記と同じ手順で登録をすれば登録できます。
バックアップを取得する
移行元であるESXi上で移行対象の仮想マシンを選び、フルバックアップを取得します。
移行元のマシンとしてUbuntuが入った仮想マシンを選びました。
こちらです。
フルバックアップを取得した後、移行する前までは日次、週次、月次といった頻度で差分のバックアップを取得していると思いますが、いよいよ移行するタイミングでは最後の差分バックアップを手動で取得しましょう。
なお、ここではバックアップジョブの作成については触れませんので、ジョブの作成について知りたい方はVeeamさんのページを見てみてください。
では、バックアップジョブを表示して、手動で実行します。
ジョブが正常終了するまでにしばらく待ちます。
ジョブが完了しました。
インスタントリカバリーでバックアップデータをHyper-V環境にリストアする
次にバックアップデータを元にHyper-V上に仮想マシンのリストア操作を行う形でHyper-V環境に仮想マシンを移行します。
左のツリーメニューからBackups - Diskを参照してバックアップ済みの仮想マシンを参照します。
右クリックメニューを開いて、Hyper-V環境にインスタントリカバリーを行います。
バックアップ済みの仮想マシンが表示されます。
バックアップ済みの仮想マシンをリストアする先のHyper-Vホストやクラスタを指定します。
対象のホストを選択します。今回はAzure Stack HCI環境のHyperV01というホストを指定したいと思います。
リストア先が指定されました。
仮想マシンの収容先となるディスクを選択します。Azure Stack HCI環境の共有ディスク上に仮想マシンを収容したいのでパスを変更します。
あらかじめAzure Stack HCI環境上で作成したボリューム（以下のVolume01）に収容したいので、これを選択します。
以下のように指定しました。
リストア後に仮想マシンがどのHyper-V上のどのネットワークに接続するかを指定します。
以下のようにHyper-V上で定義済みのネットワークを指定します。
以下のようになりました。
Hyper-V上に登録される名前を指定します。UUIDは変更しないでこのままにします。
Linuxベースの仮想マシンをリストアする際にはヘルパーアプライアンスという小さなLinuxが起動します。移行を補助する仮想マシンだそうですが、このヘルパーが接続するネットワークを指定します。
特に変更しないので、そのままにします。
Reasonは復元する理由を書いておくメモのようなものなります。Migrationと書いておきました。
サマリーが表示されます。
リストア後に仮想マシンを起動するかどうかのチェックがありますが、リストア後に手動操作が必要な箇所があり、ここで最終的に移行して切り替えるかどうかの判断と操作を行うこととなります。リストアする仮想マシンとは別に、移行元の仮想マシンは起動状態のままなので、ここで移行して切り替える場合には移行元の仮想マシンを停止した上で切り替えを行う必要があります。仮にこのチェックボックスを付けたまま先に進んで切り替え操作をし、移行元の仮想マシンも起動したままの状態にしてしまうと、同一ホスト名・IPアドレスの仮想マシンが同時起動してしまう状態になるので、事故につながりかねません。このような操作ミスを防ぐためにはこのチェックボックスを外しておいた方がいいかと思います。（今回はテスト環境なのでそのままにしておきました）
Finishを押してからしばらく待つと、Wating for user action…というユーザーによる操作を待っている旨のログが出力されてきます。ここでリストアした仮想マシンに切り替えるかどうかの作業が必要になりますが、切り替え作業をする場合、操作前に移行元の仮想マシンは停止しておくことになります。
※modify disksの箇所は特に何も手を加えていませんでしたが、Failedになってしまっていました。ですが、警告扱いであったため、このまま移行を進められるので先に進めています。
Instant Recoveryの箇所にRunning状態のタスクがあることが分かります。
仮想マシンの名前の箇所を右クリックして、リストアした仮想マシンに切り替え（移行）を行います。
Restore completed successfullyと表示されて、移行が完了しました。
起動確認
正常に移行ができているかを確認しましょう。
まずはHyper-V Managerを開いて、仮想マシンが動作しているかを見てみましょう。
以下の通り、仮想マシンの状態が実行中となり、動作していることが分かります。
コンソールを開いてみましたが、問題なく仮想マシンは動作しています。
各種設定やサービスの状態に問題がないかを確認し、問題がなければHyper-V環境への移行は完了と判断してよいでしょう。
なお、今回移行した仮想マシンのOSはUbuntuでしたが、Windows Server 2022の仮想マシンを用意して、上記と同様の手順でESXiからHyper-V環境へ移行作業をしてみましたが、こちらも問題なく移行ができました。
Ubuntuの仮想マシンの時はmodify disksで警告が出ていましたが、Windowsサーバーの場合は何も警告が出ることもなく、正常に完了しました。
おわりに
ESXi環境からHyper-V環境への移行にはVeeam以外にも方法はありますが、個人的な感想としてはVeeamを使うのが一番簡単かなという印象です。移行先がAzure Stack HCI環境であれば、Azure Migrateを使う方法もありますが、こちらはこの記事を書いている時点ではプレビュー版なので何ともいえませんが、Azure Migrateが正式リリースされたら試してまた記事にしてみようかなと思います。
今回は操作画面をたくさん貼ったので、記事がだいぶ長くなってしまいましたが、これで終わろうと思います。