Posted inVirtualization

virt-v2v利用ガイド：VMware、Hyper-VからKVMへの仮想マシン変換が簡単に

Virtualization tutorial - IT technology blog
Virtualization tutorial - IT technology blog

はじめに：仮想マシンの「引っ越し」に伴う共通の悩み

今日のIT業界では、多様な仮想化プラットフォームを管理することが日常的になっています。VMware vSphereを擁する企業環境を管理している方もいるかもしれませんが、Linuxサーバー上でKVMの柔軟性とオープンソースの利点を活用したいと考えているかもしれません。

あるいはもっと単純に、私のように、Proxmox VEで数十台のVMとコンテナを管理するホームラボを持っているかもしれません。これは、本番環境に導入する前にあらゆるものをテストするのに理想的なプレイグラウンドです。プラットフォーム間で仮想マシンを移行することは日常茶飯事ですが、常にスムーズにいくとは限りません。

多くの人が直面する最大の問題は、VMware ESXiやHyper-Vで稼働している仮想マシン（VM）をKVM環境（またはKVMベースのプラットフォームであるProxmox VE）に移行する方法です。データを破損させたり、設定を失ったり、最初から再インストールしたりせずに、どのように実行すればよいのでしょうか？システムが複雑な場合、この作業には数時間、場合によっては数日を要し、不要なエラー発生のリスクも伴います。

なぜ仮想マシンの変換は複雑なのか？

あるプラットフォームから別のプラットフォームへ仮想マシンを直接移行することは、まるで日本（100V電源を使用）の電子機器を変換アダプターなしでベトナム（220V電源を使用）のコンセントに差し込もうとするようなものです。動作しないか、最悪の場合、損傷を引き起こします。主な原因は、アーキテクチャの根本的な違いと、各ハイパーバイザーが仮想マシンを管理する方法にあります。

  • 仮想ディスクフォーマット： VMwareはVMDKを、Hyper-VはVHD/VHDXを使用しますが、KVMは通常QCOW2またはRAWを使用します。これらのフォーマットには直接的な互換性がありません。
  • 仮想化デバイス (Virtual Hardware)： 各ハイパーバイザーは異なる仮想ハードウェアデバイスをエミュレートします。VMware仮想マシンはE1000またはVMXNET3ネットワークカードを認識するかもしれませんが、KVMは高いパフォーマンスを達成するためにVirtIOの使用を優先します。
  • ゲストOS内のドライバー (Guest OS)： 仮想マシン内のオペレーティングシステムは、通常、それが実行されている仮想化環境に特化したドライバー（例：VMwareの場合はVMware Tools、Hyper-Vの場合はHyper-V Integration Services）をインストールします。新しいプラットフォームに移行すると、これらのドライバーは役に立たなくなったり、競合を引き起こしたりして、VMが起動しなくなったり、非効率的に動作したりする可能性があります。
  • ブートローダー構成： 仮想ハードウェアに関するいくつかの変更は、ゲストオペレーティングシステムの起動プロセスに影響を与える可能性があります。

これらの違いがあるため、仮想マシンを新しいプラットフォームに「そのまま」持ち込むことは不可能であるか、非常に多くの手動調整が必要になります。

既存の仮想マシン移行オプション

最適なソリューションにたどり着く前に、他の一般的なアプローチとその制約をいくつか見てみましょう。

1. ゼロからの再構築 (Recreate from Scratch)

これは理論上最も単純な方法です。KVMプラットフォーム上に新しい仮想マシンを作成します。その後、オペレーティングシステム、すべてのアプリケーションと構成を再インストールし、古いVMからデータを移行します。

  • 長所： システムがクリーンであることを保証し、新しいKVM環境に完全に最適化されます。
  • 短所： 特に、複雑な設定、多数のソフトウェア、または特定のシステム設定を維持する必要がある仮想マシンの場合、非常に時間と労力がかかります。このプロセスは、数十時間の作業を消費し、エラーのリスクが非常に高くなる可能性があります。

2. qemu-img convertによる手動ディスク変換

qemu-img convertツールは、仮想ディスクファイルのフォーマットを変更するのに非常に役立ちます。例えば、.vmdk（VMware）ファイルを.qcow2（KVM）に変換するには次のようにします。


qemu-img convert -f vmdk -O qcow2 /path/to/source_vm.vmdk /path/to/destination_vm.qcow2
  • 長所： ディスクフォーマットの変更が簡単かつ迅速に行えます。
  • 短所： これは問題の半分にすぎません！qemu-img convertはディスクファイルフォーマットのみを処理し、ゲストOS内の古いドライバーの削除や新しいドライバーの挿入には関与しません。新しいディスクファイルを入手した後でも、KVM上にVMを手動で作成し、ディスクをアタッチし、VMが起動して安定して動作するように、ドライバーやブートローダーの問題と格闘する必要があります。

3. プロプライエタリツール (Proprietary Tools)

一部のベンダーは独自の変換ツールを提供しており、例えばVMware vCenter Converter Standaloneなどがあります。このツールは、VMwareエコシステム内でP2V（物理から仮想）またはV2V（仮想から仮想）変換をかなりうまく実行します。

  • 長所： 同一ベンダー製品間での変換には非常に効果的です。
  • 短所： 別のプラットフォーム（例：VMwareからKVM）に移行したい場合、多くの場合制限があり、「ベンダーロックイン」を引き起こす可能性があります。

virt-v2v：仮想マシン移行のための最適なソリューション

ハイパーバイザー間での仮想マシン移行の複雑さに直面したとき、virt-v2vは救世主として登場します。これは私がProxmox環境にVMを導入する前に、頻繁に使用するツールです。

virt-v2vとは？

virt-v2vは、Red Hatのlibguestfsプロジェクトに属する強力なオープンソースツールです。その主な目的は、他のハイパーバイザー（VMware ESXi、Hyper-V、Xenなど）からKVM/libvirtと互換性のある形式に仮想マシンを変換することです。virt-v2vの特筆すべき点は、単にディスクフォーマットを変換するだけでなく、ゲストOSに「介入」して賢く以下を実行することです。

  • 古いハイパーバイザーに固有のドライバーやツール（例：VMware Tools、Hyper-V Integration Services）を削除する。
  • 新しいKVM環境に必要なドライバー、特にI/Oとネットワークパフォーマンスを最適化するためのVirtIOドライバーを挿入（インジェクト）する。
  • 変換後すぐにVMが起動し、ネットワークに接続できるように、ブートローダーとネットワーク設定を調整する。

この機能により、virt-v2vは手動の方法と比較して、移行プロセスをはるかにスムーズで高度に自動化されたものにします。

virt-v2vを使用すべき理由

  • 高い自動化： ディスク変換後の手動作業を大幅に削減し、手動で行う場合と比較して最大80%の時間を節約できます。
  • エラーの削減： ドライバーとゲストOS構成を処理する能力により、多くの起動および運用エラーを回避できます。
  • 多様なサポート： 複数のソース（VMware、Hyper-V、Xen）からKVMへの変換をサポートします。
  • オープンソース： コミュニティによって開発および維持されており、信頼性が高く柔軟性があります。

「出発」前の準備

スムーズな変換プロセスを行うためには、いくつかの準備が必要です。

システム要件

  • KVM/libvirtがインストールされており、新しい仮想マシンを収容するのに十分なリソース（RAM、CPU、ディスク容量）を持つLinuxサーバー（CentOS/RHEL/Ubuntu Serverを推奨）。
  • ソースVMへのネットワーク接続が確保されていること（ソースVMがESXiまたは別のサーバー上のHyper-Vにある場合）。

virt-v2vのインストール

virt-v2vは通常、libguestfs-tools-c（またはlibguestfs-tools）パッケージに含まれています。

CentOS/RHEL/Fedoraの場合：

sudo yum install libguestfs-tools-c -y
# またはFedora/CentOS 8+の場合：
sudo dnf install libguestfs-tools-c -y
Ubuntu/Debianの場合：

sudo apt update
sudo apt install libguestfs-tools -y

インストールが成功したことを確認するためにバージョンをチェックします。


virt-v2v --version

ソース仮想マシンの準備 (source VM)

これは、変換後のエラーを避けるために非常に重要なステップです。

  1. 古いドライバーの削除： VMware VMの場合はVMware Toolsを、Hyper-V VMの場合はHyper-V Integration Servicesを削除します。（Linuxでは、完全に削除する必要はなく、競合を引き起こさないことを確認するだけで十分な場合があります）。
  2. OSの更新： ゲストOSが最新のパッチで完全に更新されていることを確認します。
  3. ネットワーク設定： 可能であれば、ゲストOSのネットワーク設定をDHCPに切り替え、KVM環境で新しいIPアドレスを簡単に取得できるようにします。そうでない場合は、静的IP設定を覚えておき、後で再設定します。
  4. 仮想マシンの完全シャットダウン： ソース仮想マシンがサスペンドではなく、シャットダウンされていることを確認します。
  5. データのバックアップ： いかなる変換操作を実行する前にも、仮想マシンの重要なデータを必ずバックアップしてください。

virt-v2vでの仮想マシン変換を実践

それでは、本題である仮想マシンの変換を実際に行うためのコマンドを見ていきましょう。

シナリオ1：VMware ESXiからKVMへの変換

このシナリオでは、virt-v2vはESXiサーバーに直接接続してVMデータを取得します。


# パフォーマンス向上のため、バックエンドを直接設定することを推奨します
export LIBGUESTFS_BACKEND=direct

# ESXiからの変換
sudo virt-v2v -ic esx://esxi_user@esxi_host/VM_NAME \ 
             -o libvirt -os /var/lib/libvirt/images/ \ 
             -of qcow2 --network bridge_name \ 
             NEW_VM_NAME

各パラメータの説明：

  • -ic esx://esxi_user@esxi_host/VM_NAME: ソースがESXi上のVMware仮想マシンであることを指定します。esxi_userをアクセス権を持つユーザー名（例：root）に、esxi_hostをESXiのIPアドレスまたはホスト名に、VM_NAMEをESXi上の仮想マシンの正確な名前に置き換えます。コマンド実行時にESXiのパスワードを求められます。
  • -o libvirt: 出力をlibvirt（KVM管理システム）にインポートすることを指定します。
  • -os /var/lib/libvirt/images/: KVM仮想ディスクファイルを格納するディレクトリへのパス。
  • -of qcow2: 出力仮想ディスクファイルのフォーマットをQCOW2（KVMの柔軟で一般的なフォーマット）に指定します。
  • --network bridge_name: 新しいVMの仮想ネットワークカードを、KVMホスト上の特定のネットワークブリッジ（例：virbr0、br0）にアタッチします。指定しない場合、libvirtはデフォルトのブリッジを使用します。
  • NEW_VM_NAME: KVMへの変換後に仮想マシンに割り当てたい新しい名前。

VMDKファイルが既にある場合： VMware仮想マシンを.vmdkファイルにエクスポート済みの場合（例：VMware Workstationから、またはESXiデータストアからコピー済みの場合）、そのファイルから直接変換できます。


export LIBGUESTFS_BACKEND=direct
sudo virt-v2v -i vmw /path/to/source_vm.vmdk \ 
             -o libvirt -os /var/lib/libvirt/images/ \ 
             -of qcow2 --network bridge_name \ 
             NEW_VM_NAME
  • -i vmw /path/to/source_vm.vmdk: ソースがVMDKファイルであることを指定します。

シナリオ2：Hyper-VからKVMへの変換

Hyper-Vの場合、最良の方法はHyper-V Managerから仮想マシンを事前にディレクトリにエクスポートすることです。その後、virt-v2vはエクスポートされた.vhdxファイルを処理します。


export LIBGUESTFS_BACKEND=direct
sudo virt-v2v -i hyperv /path/to/exported/hyperv_vm/Virtual\ Hard\ Disks/source_vm.vhdx \ 
             -o libvirt -os /var/lib/libvirt/images/ \ 
             -of qcow2 --network bridge_name \ 
             NEW_VM_NAME
  • -i hyperv /path/to/exported/hyperv_vm/Virtual\ Hard\ Disks/source_vm.vhdx: ソースがHyper-VのエクスポートディレクトリからのVHDXファイルであることを指定します。VHDXファイルへのパスが正しいことを確認してください。

いくつかの便利な高度なオプション

virt-v2vは、変換プロセスを微調整するための非常に多くのオプションを提供します。いくつか例を挙げます。

  • --disk DISK_PATH: VMに複数のディスクがあり、特定のディスクのみを変換したい場合。
  • --cpu TYPE: 新しいVMの仮想CPUタイプを指定します。
  • --memory AMOUNT: RAM容量を指定します（例：4GBの場合は--memory 4096）。
  • --mac MAC_ADDRESS: ネットワークカードに特定のMACアドレスを割り当てます。
  • --dry-run: 実際に何も変更せずに、virt-v2vが何をするかを確認するためにコマンドを試行実行します。事前にチェックするのに非常に役立ちます。

高度な例として、8GB RAMを持つESXiからVMを変換し、br0ブリッジにアタッチする場合：


export LIBGUESTFS_BACKEND=direct
sudo virt-v2v -ic esx://esxi_user@esxi_host/VM_NAME \ 
             -o libvirt -os /var/lib/libvirt/images/ \ 
             -of qcow2 --network br0 --memory 8192 \ 
             NEW_VM_NAME

変換後に必要な作業 (Post-conversion steps)

virt-v2vが完了すると、新しいKVM仮想マシンが作成されます。しかし、すべてが完璧に機能することを確認するために、いくつかの最終チェックと微調整が必要です。

  1. 新しい仮想マシンの起動と確認：

    virt-manager（GUI）またはvirsh（コマンドライン）を使用して、VMを起動しアクセスします。virshの例：

    
virsh list --all              # 全てのVMをリスト表示
virsh start NEW_VM_NAME       # 新しいVMを起動
virsh console NEW_VM_NAME     # VMのコンソールにアクセス (ゲストOSでシリアルコンソール設定が必要)

    起動プロセスを観察し、画面に表示されるエラーを確認します。

  2. VirtIOドライバーのインストール（Windows VMの場合）：

    Windows仮想マシンを変換した場合、virt-v2vが基本的なVirtIOドライバーを挿入している可能性があります。しかし、KVMに最適な完全なドライバー（ディスク、ネットワーク、バルーニングなど）を取得するには、VirtIO-Win ISOパッケージをインストールすることをお勧めします。

  3. ネットワーク設定：

    新しいVMが正しいIPアドレスを受信し、インターネットや他のネットワークリソースにアクセスできることを確認します。静的IPを使用する場合は、ゲストOS内で再設定してください。

  4. 古いソフトウェアの削除：

    ゲストOS内を再確認し、古いハイパーバイザー（例：VMware Toolsがまだ削除されていない場合）から不要になったソフトウェアパッケージとドライバーを完全に削除します。これにより、リソースの消費を抑え、競合を回避できます。

  5. ゲストOSの最適化：

    Linux VMの場合、/etc/fstabをチェックして、変更があった場合にマウントポイントが正しい新しいUUID/ラベルを使用していることを確認できます。使用しているカーネルが標準カーネルであるか、KVM用に最適化されていることを確認してください。

  6. スナップショットの作成：

    新しいVMが安定して動作し、詳細なチェックが完了したらすぐにスナップショットを作成します。これにより、将来問題が発生した場合に安全な復元ポイントが提供されます。

結論：virt-v2vで仮想化インフラを最適化する

virt-v2vは、仮想化インフラ管理における最も複雑なタスクの1つである、異なるプラットフォーム間での仮想マシン変換を簡素化する非常に価値のあるツールです。これは、作業時間を何時間、何日も節約するだけでなく、エラーのリスクを軽減し、システム全体を再構築することなくKVMの利点を最大限に活用することを可能にします。

有料プラットフォームからKVM/libvirtへの移行を検討しているIT管理者、または私のようにあらゆる種類のハイパーバイザーを使ってホームラボを試している人々にとって、virt-v2vは不可欠なツールです。ツールがいかにスマートであっても、大きな変更を行う前には常にデータのバックアップが最優先事項であることを忘れないでください！

Share:
Tags: