株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

トップ > Hyper-V > ついに出た！　VMware環境の仮想マシンをHyper-Vへ移行する「VM Conversion extension」

ついに出た！　VMware環境の仮想マシンをHyper-Vへ移行する「VM Conversion extension」

Hyper-V Microsoft データ移行

みなさん、こんにちは。ネットワールドでSA（ソリューションアーキテクト）として活動している後藤です。

VMware vSphere環境から他のハイパーバイザーへの移行については、各ベンダー様からいろいろなツールが提供されていますが、Hyper-Vへの移行については、Microsoftの1st Partyソリューションとしては、現在はSystem Center Virtual Machine Manager（SCVMM）しかありませんでした。その昔はMicrosoft Virtual Machine Converterというツールが存在していましたが、今はダウンロードができなくなっています。

変化球としてAzure Migrateで一度Azureに移行して、そこからVHDをダウンロードしてHyper-Vにコピー／仮想マシン作成という技もありますが、手間がかかりすぎるのでお勧めはできません、という感じです。

そのため、Veeam Backup and Replicationなどの3rd Partyツールに頼らざるを得ない状況が続いてきましたが、ついにMicrosoftから待望の1st partyツールがPublic Previewではありますがリリースされました。

それが「VM Conversion extension」です。

Microsoftのドキュメントはこちらになります。

learn.microsoft.com

上記ドキュメントにも記載している通り、Web管理ツールである「Windows Admin Center」（以下WAC）の拡張機能として実装されており、WACにHyper-Vホストを登録し、vCenterを指定して仮想マシンの移行を行う、という動きになります。

どういう構成なの？　どういうオペレーションなの？　どういう動きをするの？　について、以下で詳しく見ていきたいと思います。

1：最初に注意事項と免責事項

本記事で取り扱っている「VM Conversion extension」、執筆時点（2025/10初旬）でパブリックプレビューの機能になります。

執筆時点の情報になりますので、もしかしたら明日には仕様が変更されているかもしれません。最新の情報はMicrosoftの公式ドキュメントをご参照ください。

また、本記事に従って作業を行って発生した問題について、弊社は責任を負いかねますので、自己責任でお願いします。

2：「VM Conversion extension」って？

「VM Conversion extension」はWAC上に拡張機能としてインストールされ、vCenterやHyper-Vホストを操作して、VMware上の仮想マシンをHyper-Vホストへ移行してくれる機能になります。

そもそもWACってなに？　という方は、こちらをご覧ください。

learn.microsoft.com

簡単に言えば、Windows Serverで長らく使用されてきた「サーバーマネージャー」を代替するWebインターフェースの管理ツールで、Windows Server 2019以降でサーバーマネージャーを開くと「こっち使ってみない？」とメッセージを表示して誘導されるツールですね（画面1）。

画面1：サーバーマネージャ起動時に表示されるメッセージ

WACでサーバーを管理する場合、Web管理ツールなので当然ブラウザで接続することになりますが、スタート画面では管理対象のサーバーを選択するところからスタートになります（画面2）。

画面2：WAC起動時の管理対象サーバー選択画面

その中から管理作業を行うサーバーを選択することで、実際の管理画面に遷移します（画面３）。Windows Serverの従来のサーバーマネージャーのような項目で管理することができることがわかるかと思います。

画面3：WACのサーバーマネージャー画面

実際に移行先となるHyper-Vホストを選択し、左のメニューの一番下にある「VMの変換（プレビュー）」をクリックすると、今回のお題であるVMware環境からHyper-Vホストへ仮想マシンの移行作業を行う画面に遷移します（画面4）。

画面4：「VMの変換（プレビュー）」画面

この画面は、WACに拡張機能を導入することで表示される画面となります。

WACは拡張機能をインストールすることで様々な機能を持たせることが可能なツールになりますが、「VM Conversion extension」はエクステンションをインストールすることで拡張された機能の一つになります。

実際にはこの画面から仮想マシン移行を行うわけですが、移行を行うにあたっての環境の確認や事前準備が必要になりますので、次項からそれらを見ていきます。

3：「VM Conversion extension」を使うための前提条件

「VM Conversion extension」を使用して仮想マシン移行を行える環境は、以下のような環境になります。前述のドキュメントにも前提条件が記載されていますが、一部間違っていると思われる記述もあるので、整理して記載します。

  • 管理ツールとしてのWAC
    • インストールの種類としては「ゲートウェイサーバー」なので、Windows Server上にインストールが必要
    • インストールするWACは現行バージョンの「バージョン2410　ビルド2.4.2.1」
    • WACのほか、以下のコンポーネントのインストールもしくはコピーが必要
      • Microsoft Visual C++ 再頒布可能パッケージ
      • Visual Studio 2013 用 Visual C++ 再頒布可能パッケージ
      • PowerCLI モジュール
      • VMware Virtual Disk Development Kit (VDDK) バージョン 8.0.3
  • 移行元としてのVMware vSphere環境
    • vCenter Server 6.x もしくは 7.x、8.x（8.xは「VM Conversion extension」のバージョンが「1.8.0」以降でサポート）
    • 移行対象の仮想マシンをホストするESXiサーバーは、vCenter配下にいること
    • WACをインストールしたサーバーからネットワーク到達性があること
  • 移行先としてのHyper-Vホスト/クラスター
    • Windows Server Hyper-V。Windows Serverのバージョンには指定なし（サポート期間中のバージョンであれば問題なさそう）
    • WACをインストールしたサーバーからネットワーク到達性があること
    • ファイルコピーが実行されるので、Windows Firewallのインバウンドルールで「ファイルとプリンターの共有」を有効化
    • Azure Localは移行先としては非サポート

条件としてはこんな感じですね。

ドキュメントに、WACをインストールするサーバーで「Hyper-V ロールがインストールされていること」とありますが、Hyper-VロールというかHyper-V用のPowerShellモジュールが導入されていると、重要なPowerCLIをインストールするときにエラーが出るだけでなく、実際の移行作業時にエラーが発生するという報告もありますので、こちらの条件は満たす必要はない（むしろドキュメントの間違い）と考えています。本記事ではWACをインストールするサーバーには、Hyper-VロールおよびHyper-V用のPowerShellモジュールはインストールしていません。

また、ドキュメントで指定されているWACのバージョンは「バージョン2410　ビルド2.4.12.10」ですが、いろいろと探してましたがそのバージョンは存在しないので、おそらくは記述ミスではないかと思います。継続して探してみます。

WACのインストールの種類がわからん、という方はこちらのドキュメントを参照してください。

learn.microsoft.com

また、移行作業時はHyper-Vホストに対するファイルコピーが発生します。これはVMware環境から仮想マシンの仮想ハードディスクをHyper-Vホストに移行するために使用されます。そのため、Windows Firewallのインバウンドルールでファイル共有を許可する必要がありますので、Windows Firewallの設定を忘れずに実施してください。

なお、コピー時のHyper-VホストからみたソースはWACになります。後掲するスクリーンショット（画面17）でもご確認ください。

移行可能な仮想マシンとしては以下のドキュメントに記載のあるものになります。

learn.microsoft.com

基本的なものはサポートされていますね。

Linuxについては、Hyper-Vドライバーが組み込まれているかを確認すると幸せになれるかと思います。現在のディストリビューションの多くは組み込まれていると思いますので、問題が発生することはないと考えます。

4：今回の評価構成

ざっくりとした構成は図1のとおりです。

同じネットワークにHyper-VホストとWAC、vCenterとESXiサーバーが並べていますが、リソースの問題でNested ESXiで実装しています。

図1：本記事の検証環境構成

vCenter Server 6.xのサポートは延長サポートを考えても2024/10/15で終了していますし、7.x系列も2025/10/02で終了です（契約が残っていれば2027年までテクニカルガイダンスは続くようですが……）。ほとんどの環境は8.xに移行していると考えますので、ここは実環境に合わせて8.xを使用しました。

次項から、実際の準備作業です。

5：前提条件の準備と「VM Conversion extension」の導入

ここでは、以下の作業を実施します。WACの導入やVisual C++ 再頒布可能パッケージのインストールは割愛します。

まず、PowerCLIの導入です。

PowerCLIはVMware（Brodecom）のサイトからダウンロード可能ですが、PowerShellのInstall-Moduleコマンドレットを使用してPSGalleryからダウンロードすることも可能です。

Install-Moduleコマンドレットを使用する場合は、以下のコマンドレットでインストールできます（画面5）。

Install-Module -Name VMware.PowerCLI

画面5：Install-ModuleコマンドレットでPowerCLIをインストールした

前述のようにHyper-V用のPowerShellモジュールがインストールされている環境だと、画面6のようなエラーが発生してインストールすることができません。

画面6：Hyper-V用のPowerShellモジュールがインストールされている環境ではエラーが発生する

画面6ではInstall-Moduleコマンドレット実行前にGet-VMコマンドレットを実行してHyper-Vホスト上の仮想マシンの一覧を取得できていることから、Hyper-V用のPowerShellモジュールが導入されていることがわかりますが、PowerCLIでもGet-VMコマンドレットが存在しているので、「コマンドレットがかぶっているのでインストールできません」と表示されてしまうわけです。

強制的にインストールすることもできますが、Hyper-V用のPowerShellモジュールが入っていない環境のほうが無難です。

PowerCLIをインストールしたら、次はVDDKです。VDDKはVMware（Brodecom）のサイトからダウンロードしてきますが、バージョンは8.0.3のみのサポートになっているので、バージョンを間違えずに8.0.3をダウンロードします。

ダウンロードしてきたらファイルを解凍し、解凍後のVDDKのファイルを「C:\Program Files\WindowsAdminCenter\Service\VDDK」に丸ごとコピーします（画面7）。

画面7：VDDKを所定のフォルダーにコピーした

ここまでできたら、次はWACに「VM Conversion extension」を導入します。

WACの拡張機能のインストールは非常に簡単で、WACサインイン後、右上の歯車アイコンをクリックして設定画面に遷移します。

そこから左メニューの「拡張」をクリックして拡張機能の画面に移動します（画面8）。

「利用可能な拡張機能」のなかに「VM Conversion（Preview）」を見つけることができるかと思います。

2025年10月3日（日付はドキュメントの更新日）に最新版がリリースされた模様で、記事執筆時点の最新バージョンは「1.8.0」になります。それ以前のバージョンは「1.6.0」です。

画面8：VM Conversion (Preview)拡張機能

「VM Conversion（Preview）」を選択し、バージョンが「1.8.0」であることを確認して「インストール」ボタンをクリックするとインストールが開始されます（画面9）。

画面9：VM Conversion拡張機能のインストール

インストール完了後は「インストール済みの拡張機能」の中に「VM Conversion（Preview）」が表示されているはずです（画面10）。

画面10：インストール完了後のVM Conversion拡張機能

以上で準備が整ったので、実際の移行作業を実施してみたいと思います。

なお、「1.8.0」では「1.6.0」の不具合が修正されているバージョンなので、アップデート必須です。自動更新の設定がされている場合は問題ないですが、自動更新をOFFにしている場合は「1.8.0」にバージョンアップしてください。

6：「VM Conversion (Preview)」による実際の移行作業

WACのサーバー選択画面で移行先のHyper-Vホスト（本例ではHVHost21）を選択し、左メニューから「VMの変換（プレビュー）」を選択、画面4にもある通り、右ペインで「vCenterに接続する」をクリックします。

そうすると、vCenterのホスト名や接続のためのユーザーIDとパスワードの入力画面が表示されるので、諸情報を入力して「送信」をクリックします（画面11）。

画面11：WACからvCenterへの接続設定

接続が完了すると、vCenter上で認識している仮想マシンの一覧が表示されます（画面12）。

画面12：vCenterへの接続が完了すると、vCenterで認識している仮想マシンの一覧が表示される

これで移行作業の前準備が完了しました。

では実際に移行作業を実施してみます。

移行するためには、まずVMware環境の仮想マシンをHyper-Vホストへ同期するところからスタートなので、画面13のように移行する仮想マシン（本例ではVMware-VM01。ゲストOSはWindows Server 2022）を選択し、「同期」ボタンをクリックします。

画面13：移行する仮想マシンの同期設定

右側に同期された仮想ディスクを置くフォルダの設定ウィンドウが表示されます。Hyper-Vホスト上での同期先のフォルダを指定します（画面14）。

ここで指定したフォルダの下に仮想マシン名のフォルダが作成され、その下に「Virtual Hard Disks」フォルダが作成されて仮想ディスクがコピーされます。

複数の仮想マシンを指定した場合も、すべて同じように仮想マシン名のフォルダを作成して仮想ディスクを格納することになるので、すべての仮想ディスクが単一フォルダ配下に配置されることはありません。

画面14：移行する仮想マシンの仮想ディスク同期先フォルダの指定

パスの設定が完了したら「同期」ボタンをクリックします。

同期ジョブが開始前にプレチェックのジョブが実行されますので、しばらく待機します。プレチェックのステータスについては「状態」欄に表示されます（画面15）し、万が一エラーが発生した場合も「状態」欄の情報アイコンを参照することでエラー内容が確認できます。

画面15：同期ジョブのステータス表示

プレチェックが完了すると、実際に同期ジョブが実行されます（画面16）。

画面16：仮想ディスクの同期ジョブ開始

この同期は、WACからESXiホストにアクセスして移行対象の仮想ディスクを取り込み、Hyper-Vホストに共有フォルダを使用してコピーする、という作業が行われます。

同期中にWACのネットワークの状態を確認すると、ESXiホストとHyper-Vホストに対してセッションを張り、それらのセッションでトラフィックが発生していることがわかります（画面17）。

画面17：同期ジョブ実行中のWACのネットワークの状態

WACが仲介してESXiホスト上の仮想ディスクをHyper-VホストへVMDKからVHDXに変換を行いながらファイルコピーを行うのが同期ジョブになりますが、同期が完了すると「状態」欄に同期完了が表示されます（画面18）。

画面18：同期完了表示

同期が完了したら、次は実際の移行作業になります。

移行はWAC上の「移行」タブをクリックし、移行可能な仮想マシンを表示します。そこに表示されている移行可能な仮想マシンを選択、「移行」ボタンをクリックすることで実行可能です（画面19）。

画面19：移行準備が完了した仮想マシンの移行ジョブを実行する

右側に移行確認ウィンドウが表示されますので、問題なければ「移行」ボタンをクリックします（画面20）。

画面20：移行ジョブ開始

今回選択した仮想マシンはあらかじめVMware Toolsをアンインストールした状態で同期／移行を実行しています。

VMware Toolsがインストールされている場合の移行については、次の項にて解説します。

「移行」ボタンをクリックすると、「移行」ジョブが開始されます。

いくつかのステップが実行されますが、最終フェーズでESXiホスト上の仮想マシンが停止されます。その際、画面21のようなメッセージが表示されますのでわかりやすいかと思います。

画面21：最終移行作業開始のメッセージ

最終フェーズが完了すると、仮想マシンの移行が完了した旨のメッセージが表示され、移行完了となります（画面22）。非常に簡単に移行が完了できます。

画面22：仮想マシンの移行完了

この状態でWACのメニューから「仮想マシン」を選択すると、移行された仮想マシンが電源オンの状態で正常に動いていることを見ることができます。コンソール接続もOKでした（画面23）。

画面23：移行完了した仮想マシンに対してWACから接続した

非常に簡単なステップで仮想マシンが移行できることがお分かりいただけたかと思います。

7：VMware Toolsがインストールされている仮想マシンを移行する場合

VMware Toolsがインストールされている仮想マシンだとWACが認識した場合、移行確認画面が画面24のようになります。

画面24：VMware Toolsがインストールされている仮想マシンを選択した場合

VMware Toolsのアンインストールや、仮想マシンに設定されている静的IPをそのまま移行するかの設定が表示されますので、実行したい付帯処理を選択します。

VMware Toolsは、VMware基盤以外に移行した場合アンインストーラーを使用して削除することができず、レジストリを直接変更する必要があります。できれば移行前にアンインストーラーで削除したいです。

静的IPアドレスについては、VMXNET3などのVMwareのネットワークアダプターで静的IPアドレスを設定していた場合に、同じIPアドレスをHyper-Vホスト上に移行した後に自動設定してくれる機能になります。

この機能は、以前紹介したAzure MigrateによるAzure Local上への仮想マシン移行の際にも同じ機能があり、それと同じスクリプトを利用して実装されています。

blogs.networld.co.jp

スクリプトの詳細な動きは上記ブログをご確認ください。

Azure Migrateの時との大きな違いは「スクリプトを自動的にコピーしてタスクスケジューラーも設定してくれる」点で、事前にスクリプトを仮想マシン内にコピーして、準備スクリプトを手動実行する必要がありません。

なお、静的IPアドレス移行を実行する場合、スクリプトを仮想マシンに送り込む必要があるため、画面25にあるとおりVMware Toolsが必須になります。

画面25：静的IPアドレス移行を使用する場合は、VMware Toolsが必須

静的IPアドレス設定を行った後にVMware Toolsが自動アンインストールされれば、移行作業が楽になりますね。

ということで、両チェックボックスをオンにしてみましょう。

そうすると、「ソースVMの資格情報」を入力する欄が表示されます（画面26）。

画面26：ソースVMの資格情報の入力

情報マークをマウスオーバーすると表示される情報の通り、両設定を実行する場合には、仮想マシンの適切な権限を持ったユーザーアカウントが必要になります。

ここではローカルAdministratorのアカウントとパスワードを指定して「続行」をクリックします。

そうすると移行作業が開始され、差分同期の初期フェーズが完了すると同時に静的IPアドレスの移行設定が開始されます（画面27）。

画面27：差分同期初期フェーズ完了ののちに静的IPアドレス移行設定の開始される

これが完了すると、VMware Toolsのアンインストールが実行されます（画面28）。

画面28：静的IP移行設定完了ののちにVMware Toolsのアンインストールが実施される

VMware Toolsのアンインストール処理が完了すると、画面29のメッセージが表示されます。

画面29：VMware Toolsのアンインストール処理完了

この後に仮想マシンのシャットダウンされ、最終同期を経て、Hyper-Vホストに仮想マシンが移行されます。

移行後の仮想マシンを確認すると、Hyper-Vのネットワークアダプターに静的IPが設定され、またVMware Toolsはアインストールされていることが確認できます（画面30）。

画面30：Hyper-Vホスト上にIPアドレス設定が維持され、VMware Toolsがアンインストールされて移行された

ここまで自動的にやってくれるのであれば、移行作業の工数はかなり削減できますね。

このように、設定を行えばVMware Toolsのアンインストールを自動実行してくれるにもかかわらず、ドキュメントの「よくある質問」の中の「制限事項」に「VMware Tools は移行後に自動的にアンインストールされません。」との記述があります。ちょっとドキュメントの意図がわかりかねるのですが、移行後にはアンインストールは手動実行（レジストリ削除）になるよ！　だから移行前にアンインストールしておこうね、なんですかね。

learn.microsoft.com

8：「VM Conversion extension」の現時点の課題

今回の検証を通じて、いくつかの課題も確認できました。

  1. 同期ジョブや移行ジョブがエラーとなった場合、リカバリー手段が現時点では「WACの状態保持ファイルを削除し、いろいろ削除して、最初からやり直し」しかない
  2. 最終同期前の仮想マシンのシャットダウンがダーティーシャットダウンになっている（Hyper-Vホスト上の仮想マシンにサインインすると、予期しない電源断のウィンドウが上がってくる）。
    最終同期のシャットダウンが「ゲストOSのシャットダウン」ではなく「仮想マシンのパワーオフ」で実行されているからと思われる。
  3. 移行はバックグラウンドで行われないので、ブラウザーセッションを維持する必要がある。

この辺りが初期評価での問題点ですかね。

例えば、VMware Toolsを「アンインストールせず」に移行した仮想マシンで、Hyper-Vホスト上での最初のサインインの際は、画面31のようにダーティーシャットダウンされた痕跡を見ることができ、またVMware Toolsが正常に動いていないことを示すウィンドウが表示されます。

画面31：ダーティーシャッドダウンされた痕跡と、VMware Toolsのメッセージ

1番については、ドキュメントにも記載がありますが、以下の2つのファイルを削除することで、ジョブの情報等を消すことができます。

 

C:\Program Files\Windows Admin Center\Service\migrationStatus.json
C:\Program Files\Windows Admin Center\Service\syncStatus.json

 

同じ仮想マシンをテストで何回も移行する際は、上記ファイルの削除が必要です。

他にもHyper-Vホスト上の仮想マシン／仮想ディスクを消したり、VMware側のスナップショットを消したり（残っている場合）、消さなければいけないものはありますが、WAC側は上記2ファイルでOKです。

2番については、データベース等動いているサーバーを移行する場合にはサービスを停止して静止点を作成する、等の対応が必要かもしれません。もしくは仮想マシン停止状態での移行を実行するか、でしょうか（その際はVMware Toolsのアンインストールや静的IP移行が不可になりますが）。

3番については、WACというツールの現在の仕様なので、受容するしかないですね。

プレビューも始まったばかりのツールですので、今後のバージョンアップでさらなる機能強化が図られると思いますので、バージョンアップなどの動きがあり次第、また確認したいと思います。

 

書いた人：後藤 諭史（Satoshi GOTO）

ソリューションアーキテクト部所属。

専門はWindows Server Hyper-VやAzure LocalといったMicrosoft仮想化技術。Microsoft SDN（Hyper-V Network Virtualization）などのWindows Server ネットワーク技術も。
Microsoft オンプレ技術以外にも、エンタープライズネットワークとかMicrosoft Azureとか、運用とか。
ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。

Microsoft MVP for Cloud and Datacenter Management（2012-2026）
Microsoft MVP for Microsoft Azure（2024-2026）