こんにちは、クララ クラウドソリューション事業部です。BroadcomによるVMware買収以降、ライセンス体系の変更やOEMライセンスの扱いの見直しを受けて、多くの企業が仮想化基盤の乗り換えを検討しています。その有力な移行先のひとつが、Nutanixの仮想化基盤(AHV)です。
今回は、VMware環境からNutanixへの移行ツール「Nutanix Move」について、クララのインフラエンジニアが実際に手を動かした経験をもとに、「本当に簡単なのか?」「どんなトラブルが起きるのか?」を包み隠さずお伝えします。
この記事でわかること
- Nutanix Moveとは何か、どんな環境を移行できるのか
- スムーズに移行するための2つの前提条件
- 現場で実際に起きたVMware Tools関連のトラブルと解決策(5事例)
- クララの移行成功率と、事前準備で押さえるべきポイント
▶ VMware移行を検討し始めた方へ|まずは資料で全体像を
VMware移行やプライベートクラウド選定の考え方をまとめた資料をご用意しています。社内での比較検討・稟議の参考情報としてぜひご活用ください。
Nutanix Moveとは
Nutanix Moveは、VMware ESXi・Microsoft Hyper-V・AWS EC2などの環境から、Nutanix AHVへ仮想マシンを移行するための無償ツールです。移行元VMのディスクデータを同期し、最終的なカットオーバー(切り替え)を最小限のダウンタイムで実施できるのが特長です。
近年のアップデートでは、VMware NSXのセキュリティポリシーをNutanix Flow Network Securityへ移行する機能や、アプライアンスの状態を可視化する「View Metrics」ダッシュボードなどが追加されています。導入はNutanixポータルからのダウンロード、またはPrism Marketplaceからのデプロイが可能です(バージョン・対応状況は要確認)。
どんな環境を移行してきたのか
クララでこれまでNutanix Moveを使って移行してきた対象には、以下のようなケースがあります。
- 物理サーバーからP2V(Physical to Virtual)したもの
- P2VしたものをさらにV2V(Virtual to Virtual)したもの
- お客様環境からP2Vしたもの
- AzureからV2Vしたもの
- ESXi 4.1やESXi 6.5といった古いバージョンで作成されたVM
VMのバージョンが古いと、ドライバやVMware Toolsのバージョンも古く、移行時にトラブルが発生しがちです。しかし適切に対応すれば、かなり古い仮想マシンでも移行できました。
スムーズに移行するための2つの条件
条件1:VMware Tools(またはopen-vm-tools)がインストールされていること
これがないとMoveがゲストOSを正しく認識できません。ただし、バージョンが古すぎると認識できない場合があります。
条件2:管理ネットワーク同士が通信できること
移行元VMware側の管理ネットワークと、Nutanix側の管理ネットワークが疎通できる必要があります。ネットワークが分かれている場合は、ルーター経由にするなどの対応が必要です。
この2点がクリアできていれば、移行はかなりスムーズに進みます。
現場で起きたVMware Tools関連のトラブルと解決策
課題1:ESXi 4.1で作成されたVMがMoveで移行できない
事象:VMware Toolsは入っていたが、Moveが認識せず移行できなかった。
原因:VMware Toolsのバージョンが古すぎて、Moveが認識できなかった。
対応策:新しいVMware Toolsを入れ直して解決。ただし全ケースで解決できたわけではない。
課題2:VMware Toolsを削除して新しいものを入れられない
事象:古いVMware Toolsをアンインストールしようとしても、途中で失敗し新しいバージョンを入れ直せなかった。
原因:OS側の依存関係やレジストリ・パッケージ管理の不整合が影響していた。
対応策:手動でのアンインストール処理や関連ファイルの削除を行った上で再インストールし、解決した。
課題3:open-vm-toolsがインストールできない
事象:Linux系OSでopen-vm-toolsをパッケージマネージャからインストールしようとしたが失敗した。
原因:OSのバージョンが古く、標準リポジトリに対応パッケージが存在しなかった。Open VMware Tools のベースリポジトリには存在しないため、EPEL(追加リポジトリ)の有効化が必要だった。
対応策:リポジトリの追加設定やパッケージの手動取得により対応した。
※しかし、それでもインストールできない VM も存在した。
課題4:手動でのパッケージインストールが必要だった
事象:すべての対応を試みても、Open VMware Tools をインストールできない VM が存在した。
原因:明確な原因は特定できず。手作業で回避できるため、詳細な調査を行わなかった。
対応策:RPM を使用し、依存関係を含めて 1 つずつ手作業でパッケージをインストールすることで解決。
課題5:インストールできても正常に動作しない
事象:VMware Toolsのインストール自体は完了したが、Moveがゲスト情報を正しく取得できなかった。
原因:Open VMware Tools と競合するパッケージが存在していた。物理サーバ時代に使用されていたDell の管理ツール(Server Administrator)が競合していたため、正常に動作しなかった。
対応策:競合しているパッケージを削除し、再インストールすることで解決した。
▶「うちの古い環境、移行できるだろうか?」と不安な方へ
ESXi 4.1/6.5世代のVMやP2V済みサーバーなど、古い環境ほど移行時のトラブルは起きやすいものです。クララはVMwareからNutanixへの移行実績が豊富で、事前アセスメントで移行可否とリスクを見極めます。
Nutanix Moveの移行成功率と作業負担
クララで実施した移行の成功率は、おおむね次のような結果でした。
- 50%以上:VMware Toolsがそのまま使え、ほぼトラブルなく移行完了。
- 約25%:VMware Toolsの入れ直しなど一部調整が必要。
- 残り約25%:詳細調査や手作業での対応が必要。それでも移行は可能だった。
担当エンジニアは「作業自体はそれほど難しくなかった」と話しますが、これはNutanixの運用経験が豊富なエンジニアが対応したからという側面もあります。ログ解析やパッケージ競合の回避など、専門的な知見が求められる場面も少なくありませんでした。すべての企業が同じように対応できるとは限らないのが実情です。
一方で、以下の事前準備をしっかり行えば、作業負担は大きく軽減できます。
- VMware Tools(open-vm-tools)のバージョン確認と互換性チェック
- 管理ネットワークの疎通確認
- 古いVM環境への対策の事前検討
これらを押さえておけば、カットオーバー(最終移行)がワンクリックで完了するケースも多く、手作業移行に比べてミスのリスクも大幅に減らせます。
まとめ:事前準備がNutanix Move移行成功のカギ
Nutanix Moveは、事前準備さえ整っていればスムーズな移行を実現できる優秀なツールです。ポイントは次の3点です。
- 移行前にVMware Tools(open-vm-tools)のバージョンを確認する
- 管理ネットワークの疎通をチェックする
- 古いVMは手作業対応も想定しておく
とはいえ、古い環境や特殊な構成では専門的な判断が必要になる場面もあります。「自社だけで進められるか不安」という場合は、移行実績のあるパートナーに相談するのが安全です。
