なぜExport OVFではなくvCenter Converterを使うべきなのか？
多くのインフラ移行プロジェクトを経験して学んだ教訓があります。それは、異なるプラットフォーム間でのExport/Import OVFを完全に信用してはいけないということです。VirtualBoxからVMwareへ通常のエクスポートで移行する場合、ディスクドライバの競合によるブルースクリーン（BSOD）の発生率は70%にも達します。
VMware vCenter Converter Standaloneは単なるデータのコピーではありません。カーネルとドライバの「再構成（reconfiguration）」という非常にインテリジェントな処理を行います。これにより、新しい環境でも仮想マシンをスムーズに起動させることができます。
私がこのツールを常に選ぶ理由は以下のメリットにあります：
- ホットミグレーション: ソースマシンを稼働させたまま移行でき、ダウンタイムが不要。
- 柔軟なリサイズ: 変換中にディスクの縮小（Shrink）や拡張（Expand）が可能。
- HALの処理: WindowsのHardware Abstraction Layerを自動調整し、起動エラーを防止。
- 完全無料: 現在はダウンロードに Broadcomのアカウントが必要ですが、無料で利用できます。
実行前の準備
現在のバージョン6.4または6.6は、Windows 11や最新のLinuxを良好にサポートしています。注意点として、Converterは管理用の中間マシンにインストールすることをお勧めします。リソースの占有や不要なドライバの競合を避けるため、移行元（ソース）マシンに直接インストールするのは避けましょう。
途中で失敗しないための必須チェックリスト：
- Guest Additions (VirtualBox) または Integration Services (Hyper-V) を完全に削除する: これが最も重要なステップです。古いドライバが残っていると、移行後のシステムクラッシュの主な原因になります。
- サービスポートの開放: Converterをインストールしたマシンが、ソースマシンに対してポート445 (SMB)、902、443で通信できることを確認してください。
- ファイアウォール/アンチウイルスの無効化: ツールはソースマシンに小さなエージェントをデプロイします。ファイアウォールが有効だと、最初の接続ステップで止まってしまいます。
# Windowsソースマシンのポート445を素早くチェック
test-netconnection -computername 192.168.1.50 -port 445V2V（Virtual-to-Virtual）プロセスの詳細設定
移行元のプラットフォームによって、アプローチが異なります。
ケース1：Hyper-VからESXiへの移行
ConverterはHyper-V Serverへの直接接続をサポートしています。サーバーのIPとAdministratorアカウントを入力するだけです。ただし、データの完全性を期すため、Hyper-V仮想マシンはPowered Off（電源オフ）の状態にしておくことをお勧めします。
ケース2：VirtualBoxからVMwareへの移行
VirtualBoxにはConverterが直接接続できるオープンなAPIがありません。ここでのコツは、VirtualBoxの仮想マシンを「物理マシン（Physical Machine）」として扱うことです。
- VirtualBox側の仮想マシンを起動します。
- Converterで、Source Typeとして「Powered on machine」を選択します。
- VirtualBox仮想マシンのIPを入力し、ツールがエージェントをデプロイできるようにします。
移行先（Destination）の設定：
個人で利用するためにファイルとして保存したい場合は、VMware Workstationを選択してください。一方、ESXiホストや集中管理サーバー群に直接送る場合は、VMware Infrastructureを選択します。
ディスク容量の最適化：
Data to copyタブで、「Select volumes to copy」を選択します。Thick（実容量を確保）ではなく、Thin provisionedを選択しましょう。例えば、ソースディスクが1TBであっても実際には100GBしか使用していない場合、Thinを選択することで、新しいストレージ上の容量を900GB節約できます。
98%でのエラー処理と事後確認ステップ
プロセスが98%に達したときに、構成エラーの通知が表示されることがあります。しかし、あまり心配しないでください。
実際には、この時点でデータのコピーは100%完了しています。Converterはブートローダーの再構成（特にLinuxで多い）の段階で苦戦しているだけです。そのまま仮想マシンを起動してみてください。Windowsの場合、通常は自動修復が行われ、起動できます。Linuxの場合は、Live CDを使用してGRUBを再構築するだけで完了します。
仮想マシンの「稼働開始」直後に行うべきこと：
- VMware Toolsのインストール: 画面ドライバ、マウス、ネットワークカードのパフォーマンスを最適化するための最優先事項です。
- IPアドレスの再設定: 新しいネットワークカードは古いものとは異なるIDを持ちます。固定IPを使用している場合は、最初から設定し直す必要があります。
- 非表示ドライバのクリーンアップ:
デバイス マネージャーを開き、「非表示のデバイスの表示」を選択して、薄く表示されているドライバ（VirtualBox/Hyper-Vの残骸）を削除します。
実体験として、KubernetesノードをVirtualBoxからESXiに移行した際、ネットワーク遅延が15〜20%明らかに減少しました。これはVMwareのvmxnet3ドライバが仮想化環境に非常によく最適化されているためです。
準備を丁寧に行えば、仮想マシンの移行は難しくありません。移行が成功し、ブルースクリーンに悩まされる夜がなくなることを願っています！
