KVMからNutanix AHVへ仮想マシンを移行する方法|qcow2を使った手動移行

Windows

KVMで稼働している仮想マシンを、Nutanix AHVへ移行したい場合があります。

VMware ESXiやHyper-VからNutanix AHVへの移行ではNutanix Moveが利用できますが、一般的なKVMはNutanix Moveの移行元として公式資料に掲載されていません。

そのためKVMからAHVへ移行する場合は、KVMの仮想ディスクを取得し、Nutanix側へ登録して新しいVMを作成する手動移行を検討します。

この記事では、KVMで使用しているqcow2形式の仮想ディスクをNutanix AHVへ移行する場合の基本的な流れと注意点を解説します。

KVMからNutanix AHVへqcow2を使って仮想マシンを移行する方法
KVMのqcow2仮想ディスクをNutanix AHVへ移行する基本手順と確認ポイント

KVMからNutanix AHVへの移行方法

大まかな流れは次のようになります。

KVM VMの構成確認
 ↓
VM停止
 ↓
qcow2バックアップ
 ↓
qemu-imgでディスク確認
 ↓
Nutanixへイメージ登録
 ↓
AHV VM作成
 ↓
ディスク・NICなどを設定
 ↓
VM起動
 ↓
OS・ネットワーク・サービス確認

単にqcow2ファイルをコピーするだけではなく、移行元VMの構成を事前に記録しておくことが重要です。

Nutanix MoveでKVMから直接移行できる?

Nutanix Moveは、異なる仮想化基盤やクラウドからNutanixへVMを移行するためのツールです。

ただし、2026年時点のNutanix公式資料で示されている主な移行元には、VMware ESXi、Microsoft Hyper-V、Nutanix AHV、AWS EC2、Microsoft Azureなどが含まれていますが、一般的なKVMは含まれていません。

そのため、KVMからNutanix AHVへの移行では、Moveを前提とせず手動移行を検討します。

1.KVM側でVM構成を確認する

最初に移行対象VMの構成を記録します。

libvirtを使用している場合は、次のようなコマンドで確認できます。

virsh list --all
virsh dominfo VM名
virsh domblklist VM名
virsh domiflist VM名

XML設定も保存しておくと、移行後の構成確認に役立ちます。

virsh dumpxml VM名 > VM名.xml

特に確認しておきたいのは次の項目です。

  • vCPU数
  • メモリ容量
  • 仮想ディスク
  • ディスクバス
  • NIC
  • MACアドレス
  • BIOS / UEFI
  • IPアドレス
  • ゲストOS

2.仮想ディスクの形式を確認する

KVM側で使用している仮想ディスクを確認します。

virsh domblklist VM名

例えば、

/var/lib/libvirt/images/rocky9.qcow2

のようなファイルが使用されている場合があります。

ディスク情報はqemu-imgで確認できます。

qemu-img info /var/lib/libvirt/images/rocky9.qcow2

ここでファイル形式や仮想ディスク容量などを確認します。

3.VMを停止する

移行用の最終ディスクを取得する場合は、データの整合性を確保するためVMを正常に停止してから作業する方法が分かりやすいです。

virsh shutdown VM名

状態を確認します。

virsh list --all

VMが停止したことを確認してからディスクをコピーします。

4.qcow2をバックアップする

移行作業前に元のqcow2を残しておきます。

例えば、

cp -a rocky9.qcow2 rocky9_before_nutanix.qcow2

のようにバックアップできます。

大容量ディスクの場合はコピーに時間がかかるため、空き容量も事前に確認します。

df -h

KVMのqcow2イメージをバックアップする方法については、こちらでも解説しています。

KVM仮想マシンのイメージファイルをバックアップする方法【qcow2】
やりたいこと1.CentOS8のKVMホスト上の仮想マシン(Windows)のOSを落として、イメージファイルのコピー2.仮想マシンを立ち上げて、デスクトップに新しいファイルを作成3.サイド仮想マシンのOSのを停止4.イメージファイルをリネ…

5.qcow2を確認・必要に応じて変換する

コピーしたイメージを確認します。

qemu-img info rocky9.qcow2

必要に応じて別のqcow2ファイルとして変換することもできます。

qemu-img convert -p -f qcow2 -O qcow2 \
rocky9.qcow2 rocky9-nutanix.qcow2

ただし、変換が必ず必要というわけではありません。

元のディスク形式、スナップショット構成、移行先で利用する形式などを確認して判断します。

6.Nutanixへディスクイメージを登録する

次にqcow2イメージをNutanix側へ登録します。

Prismのイメージ管理機能から、移行用の仮想ディスクイメージをアップロードします。

環境やAOS / Prismのバージョンによって画面構成や名称が異なる場合がありますが、基本的にはイメージを登録し、そのイメージを新しいVMのディスクとして利用します。

大容量のqcow2ではアップロードに時間がかかるため、ネットワーク帯域や作業時間にも注意します。

7.Nutanix AHVで新しいVMを作成する

イメージ登録後、AHV側で新しいVMを作成します。

KVM側で記録した情報を参考に、

  • vCPU
  • メモリ
  • ディスク
  • NIC
  • ネットワーク / VLAN
  • 起動方式

などを設定します。

最初からCPUやメモリを大幅に増やすのではなく、まず移行元に近い構成で起動確認し、その後必要に応じて調整すると原因を切り分けやすくなります。

8.BIOSとUEFIに注意する

移行時に注意したいのが起動方式です。

KVM側がUEFIで起動していたVMをAHV側で異なる方式にすると、OSが起動できない可能性があります。

KVM側のXMLなどを確認し、元のVMがどの方式で起動していたか確認しておきます。

9.VirtIOとデバイスドライバを確認する

AHVで使用する仮想デバイスをゲストOSが認識できるかも重要です。

特にWindows VMではVirtIOドライバの準備が重要になります。

Linuxでも、利用しているOS・カーネルが必要なVirtIOデバイスを認識できるか事前に確認しておきます。

「KVMもAHVもKVM系だから必ずそのまま起動できる」と考えず、ゲストOSの互換性を確認してから移行します。

10.AHVでVMを起動する

VMを作成したら起動します。

最初はコンソールから確認できる状態にしておくと、ネットワークが利用できない場合でも原因を確認しやすくなります。

確認するポイントは、

  • ブートローダーが起動するか
  • OSが起動するか
  • ディスクを認識しているか
  • NICを認識しているか

です。

11.LinuxではNIC名が変わっていないか確認する

KVMからAHVへ移行すると仮想ハードウェア構成が変わるため、NIC関連の設定を確認します。

ip addr
ip link
ip route

固定IPを設定しているVMでは、インターフェース名やMACアドレスの変更によってネットワーク設定がそのまま利用できない場合があります。

DNSやデフォルトゲートウェイも確認します。

12.fstabとディスクを確認する

Linuxではディスク認識も確認します。

lsblk
blkid
df -Th

/etc/fstabでUUIDを利用している場合は、移行後も正しくマウントできているか確認します。

cat /etc/fstab

OSが起動しても、一部のデータ領域だけマウントされていないケースがあるため注意します。

13.サービスを確認する

OSが起動しただけでは移行完了ではありません。

Linuxなら、

systemctl --failed

などで失敗しているサービスを確認します。

さらに実際の用途に応じて、

  • Web
  • データベース
  • メール
  • ファイル共有
  • 監視
  • バックアップ
  • EDR

などのサービスが正常に動作するか確認します。

14.ネットワーク疎通を確認する

移行後は最低限、

ip addr
ip route
ping デフォルトゲートウェイ
nslookup ホスト名

などでネットワークを確認します。

同じIPアドレスを利用する場合は、移行元KVM VMと移行先AHV VMを同時に本番ネットワークへ接続しないよう注意します。

15.移行元VMをすぐに削除しない

AHV側でVMが起動したからといって、KVM側のVMをすぐ削除するのはおすすめできません。

一定期間は旧VMやバックアップを保持し、問題が発生した場合に戻せるようにしておきます。

KVM VM停止・保持
        ↓
AHV VM起動
        ↓
OS確認
        ↓
ネットワーク確認
        ↓
サービス確認
        ↓
アプリケーション確認
        ↓
問題がなければ本番運用

移行後にCPU・メモリを調整する

AHVへの移行後、実際の負荷を確認してCPUやメモリを調整します。

▶ Nutanix AHVでVMのCPU・メモリを増やす方法|稼働中のHot Addも解説

移行後にVMが遅い場合

移行後にパフォーマンスが悪い場合は、CPUだけでなくメモリやストレージI/Oなどを確認します。

▶ Nutanix AHVでVMが重い・遅いときの確認ポイント|CPU・メモリ・ストレージを切り分け

NutanixのHealthも確認する

移行後はVMだけでなく、Prism Element側のAlertsやクラスタのHealthも確認します。

▶ Nutanix Prism Elementで確認したいアラートと健全性チェック|運用で最初に見るポイント

まとめ

KVMからNutanix AHVへの移行では、一般的なKVMをNutanix Moveの移行元として扱うのではなく、仮想ディスクを利用した手動移行を検討します。

基本的な流れは、

KVM構成確認
 ↓
VM停止
 ↓
qcow2バックアップ
 ↓
qemu-imgで確認
 ↓
Nutanixへイメージ登録
 ↓
AHV VM作成
 ↓
起動
 ↓
OS・ネットワーク・サービス確認

となります。

特にBIOS/UEFI、VirtIO、ディスク、NIC、ゲストOSの互換性を事前に確認しておくことが重要です。

また、移行後すぐにKVM側のVMを削除せず、十分な動作確認を行ってから切り替えることで、移行トラブル時にも戻しやすくなります。

参考情報

コメント

タイトルとURLをコピーしました