Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
VMwareの仮想マシンをProxmoxといったKVMハイパーバイザーへ移行する際、最初に直面する互換性の課題が存在します。QEMUはVMDKファイルを直接起動できず、拡張子の名称変更だけでは解決できないため、正しい形式変換作業が必須となります。
本ガイドではLinux、Proxmox、Windows環境でのVMDKからQCOW2への変換手順を解説します。qemu-imgによる処理フロー、Proxmoxのimportdisk操作、ドライバ再設定が必要な場面で活用するvirt-v2vを紹介し、末尾に頻出する起動エラーのトラブルシューティング表を記載しています。
変換作業を開始する前に、2つのディスク形式が相互利用できない理由を把握しておくと便利です。
VMDKはVMware独自のディスク形式で、ESXiやVMware Workstationで使用されます。QCOW2はQEMU・KVM標準形式で、スナップショット、圧縮、AES暗号化機能を標準搭載しており、Proxmoxや大半のOpenStack環境でデフォルト採用されています。
.vmdkファイルの拡張子を単純に.qcow2へ変更しても起動できません。ハイパーバイザーが有効な起動ヘッダーを検出できず、仮想マシンが起動失敗するためです。正しい変換処理で内部データ構造を再構築することで、KVM上で正常に動作するディスクが作成されます。
以下の手順を省略することが、変換後のイメージ破損や仮想マシン起動失敗の最も多い原因です。
qemu-img info source.vmdkを実行し、ファイルサイズ、形式、ディスク種別を確認します。-flat.vmdkで終わる大容量データファイルに分割することが多いため、変換ツールには-flat.vmdkを指定するか、2つのファイルを同一ディレクトリに配置します。Linux環境でディスク形式を変換する最も簡単な手段は、QEMUツールセットに含まれるqemu-imgユーティリティです。
大半のLinuxディストリビューションにはqemu-imgが標準搭載されていないため、各ディストリビューションのパッケージマネージャーでインストールします。
Ubuntu・Debian系の場合：
sudo apt update && sudo apt install qemu-utils
RHEL、CentOS、Fedoraの場合：
# RHEL/CentOS 7
sudo yum install qemu-img
# RHEL/CentOS 8以降、Fedora
sudo dnf install qemu-img
元のVMDKファイルが存在するディレクトリへ移動後、以下を実行します。
qemu-img convert -f vmdk -O qcow2 source.vmdk output.qcow2
各オプションの役割は以下の通りです。
-f vmdk：入力元のディスク形式を指定-O qcow2：出力先のディスク形式を指定-p：（オプション）変換中の進捗バーを表示-c：（オプション）出力ファイルを圧縮し容量を削減変換完了後、出力ファイルが正常か確認します。
qemu-img info output.qcow2
コマンド実行後に仮想ディスクサイズ、実際の使用容量、フォーマット種別が出力されます。形式がqcow2と表示され、仮想ディスクサイズが元のディスクと一致していれば変換成功です。
移行元の仮想マシンがWindowsの場合、変換後KVM上で起動失敗する可能性が高くなります。Windowsには標準でVirtIOドライバが搭載されておらず、KVMのストレージコントローラーと通信できないためです。
対応方法は2種類存在します。
Proxmox VEはDebianを基盤とし、qemu-imgが事前インストール済みです。ただし、インポート手順は一般的なLinux環境と異なります。単純に.qcow2ファイルをストレージディレクトリへコピーしても認識されず、qm importdiskコマンドでディスクを正しく登録する必要があります。
VMDKファイルをSCPまたはWebUIのファイルアップロード機能でProxmoxホストへ転送し、変換コマンドを実行します。
qemu-img convert -f vmdk -O qcow2 source.vmdk output.qcow2
変換完了後、qm importdiskコマンドでQCOW2ファイルを指定の仮想マシンにインポートします。
qm importdisk <VMID> output.qcow2 <ストレージ名>
<VMID>は移行先仮想マシンの番号（例：101）、<ストレージ名>はProxmoxの保存先ストレージ（例：localまたはlocal-lvm）に置き換えます。
インポート完了後、Proxmox WebUIの対象VMのハードウェアタブへ移動し、新規インポートしたディスクを接続してから起動します。
全てのProxmoxストレージバックエンドがQCOW2ファイルに直接対応しているわけではありません。
localなど、/var/lib/vz配下にファイルを保管）：.qcow2形式にネイティブ対応。local-lvm、ZFSなど）：QCOW2ファイルを直接保管できない。これらのバックエンドを対象にqm importdiskを実行すると、Proxmoxが自動的にデータを展開しraw論理ボリュームとして書き出します。これは正常な動作で、一般的にI/Oパフォーマンスが向上します。localが最も安全です。rawボリュームのパフォーマンスが重視される本番VMにはlocal-lvmへ切り替えてください。qemu-imgはWindowsネイティブアプリケーションとして提供されていないため、別の仮想マシンを起動するオーバーヘッドなしで完全なLinux環境を利用できるWindows Subsystem for Linux（WSL）経由で実行する手法が最も安定しています。
PowerShellを管理者権限で起動し、以下を実行します。
wsl --install
本コマンドでWSL2とデフォルトディストリビューションのUbuntuがインストールされ、設定完了にはPCの再起動が必要です。再起動後、ターミナルウィンドウが起動しUbuntuの初期設定が開始されます。
Ubuntuターミナル上で以下を実行します。
sudo apt update && sudo apt install qemu-utils
WSLはWindowsのドライブを/mnt/配下にマウントします。C:\VMs\my_disk.vmdkのファイルはWSL上で/mnt/c/VMs/my_disk.vmdkとしてアクセス可能です。
ただし/mnt/c/配下のパスから直接変換を実行すると、ファイルシステムを跨ぐオーバーヘッドにより処理速度が大幅に低下するため、パフォーマンス向上のため事前にVMDKファイルをWSLのホームディレクトリへコピーします。
cp /mnt/c/VMs/my_disk.vmdk ~/my_disk.vmdk
cd ~
qemu-img convert -f vmdk -O qcow2 my_disk.vmdk output.qcow2
変換完了後、QCOW2ファイルをWindowsのドライブへコピーします。
cp ~/output.qcow2 /mnt/c/VMs/output.qcow2
これでWindowsエクスプローラーからファイルにアクセス可能となり、KVMまたはProxmoxホストへ転送できます。
qemu-imgはディスク形式の変換のみを実行し、ディスク内部のOSに対する設定変更は行いません。ESXiからKVMへWindows仮想マシンを移行する際、新しいハイパーバイザーに必要なVirtIOドライバが存在しないため、ゲストOSが起動失敗するケースが多発します。
virt-v2vはこの課題を解決するツールで、一連の手順で完全な移行を実施します。ディスク形式変換、VirtIOストレージ・ネットワークドライバの埋め込み、ブートローダーの調整、競合を引き起こすVMware Toolsの削除を自動処理します。
以下の状況ではvirt-v2vを選択します。
Linuxゲストの場合はqemu-imgで十分なケースが大半です。Linuxカーネルには標準でVirtIOドライバが内蔵されているため、形式のみの変換で起動トラブルが発生しにくくなります。コマンドライン以外の各種V2V変換ツールを比較検討する場合は、当社のV2Vコンバーターガイドに主要なオプションを記載しています。
virt-v2vは大半のLinuxディストリビューションでパッケージマネージャーからインストール可能です。
# Debian/Ubuntu
sudo apt install virt-v2v
# RHEL/CentOS/Fedora
sudo dnf install virt-v2v
vCenterサーバー上の仮想マシンを直接移行するコマンド：
virt-v2v -ic vpx://ユーザー名@vcenter.example.com/データセンター/esxiホスト \
-it vddk \
-o local -os /var/tmp \
Windows移行対象VM名
スタンドアロン型ESXiホストに接続する場合は、vpx://をesx://に置き換えます。
virt-v2v -ic esx://ユーザー名@esxi-host.example.com \
-it vddk \
-o local -os /var/tmp \
Windows移行対象VM名
-it vddkオプションを使用するにはVMware Virtual Disk Development Kit（VDDK）を別途インストールする必要があります。VMware開発者ポータルからダウンロードし、virt-v2vのドキュメントに従ってライブラリパスを設定した後、上記コマンドを実行してください。ツールは指定したディレクトリへ変換済みQCOW2ディスクとメタデータファイル(.xml)を出力し、これらをKVMまたはProxmoxへインポート可能です。
変換時の不具合は主に2つの要因に起因します。間違ったソースファイルを選択した、またはゲストOSが期待するハードウェア構成とKVMの環境が不一致することです。
下表に最も頻出するエラーと対処法を記載します。
| エラー内容 | 原因 | 解決策 |
|---|---|---|
| Invalid footer | データファイルではなく記述子ファイルを選択 | -flat.vmdkファイルを使用 |
| 起動失敗：「not a bootable disk」 | ディスクコントローラー種別の不一致、または変換イメージの破損 | コントローラーをIDE、SCSI、VirtIOのいずれかに切り替え |
| local-lvm上でqcow2が非対応 | .qcow2ファイルをブロックストレージへ直接コピー | qm importdiskを使用 |
| Windowsゲストでブルースクリーン | VirtIOドライバが未導入 | IDEコントローラーで起動後、VirtIOドライバをインストールし切り替え |
| 出力ファイル容量が想定より大きい | シンプロビジョニングVMDKが変換時に展開 | -cオプションを追加し圧縮 |
本ガイドで紹介したqemu-img、virt-v2vによる処理フローは単一のディスク変換には適しています。しかし複数の仮想マシンを環境間で一括移行する場合、または移行処理中も本番システムを稼働させ続ける必要がある場合、手動のコマンドラインツールには限界が生じます。標準の検証機能、一元的な進捗管理、転送途中の障害から再開する仕組みが搭載されていないため、失敗時に最初から作業をやり直す必要があります。
i2Migrationは上記の課題に特化した統合移行プラットフォームです。物理、仮想、クラウド環境を跨いだ無停止ライブ移行に対応し、大規模なVMware→KVM移行時に発生する各種課題を解消します。
移行完了後も継続的なデータ保護が必要な運用チームには、i2Backupが仮想・物理・クラウド環境を統合したバックアップを提供します。高可用性要件の厳しいワークロードには、i2Availabilityが本番環境と災害復旧環境間のリアルタイムレプリケーションと自動フェイルオーバーを実現します。
VMDKからQCOW2への変換は、用途に適したツールを選ぶことがポイントとなります。
大半のLinuxユーザーは、qemu-img を使用すれば数行のコマンドでスムーズに変換可能です。Proxmox環境では、ストレージにディスクを正しく登録するため、追加で qm importdisk の実行が必要です。WindowsユーザーはWSL経由でLinuxと同じ手順を実行できます。ESXi上のWindows仮想マシンを移行しドライバの再設定が必要な場合は、フォーマットのみ変換する手法より virt-v2v の方が安定します。
いずれの手法を利用する場合も共通のルールが適用されます。エクスポート前にすべてのスナップショットを統合し、ツールには -flat.vmdk データファイルを指定し、インポート前に qemu-img info で出力ファイルを検証してください。
大規模な移行作業や停止時間を許容できない業務環境を扱う企業向けには、Info2soft のi2Migrationが適しています。本製品は検証機能、ドライバ自動挿入機能、異種環境間のライブ移行機能を標準搭載し、体系的な移行フローを提供します。
