大学の輪行で割り当てられた海外の大学論文に書かれてあったんだんだが、その大学では、座学と実験をスパイラルにやっているところがあるらしい。つまり、本来は理論と実験は対をなすものでとても意味がある構成だと思う。日本の大学だと、座学と実験が完全に分かれているので、座学が「当然の内容」、実験は、差し詰め「手順がステップバイステップで書かれた家庭科の料理」みたいなものになり、実験は成功するが、レポートも素人目に見ても意味不明なものができあがる。
そういう人が社会に出ると座学だけの悪影響「誰が言ったんですか、どこに書いてあったんですか?サポートされますか?」だけいう人が出現。自分で手を動かして調べてみろといいたいが、事象の理解が脳内で理論と実験で真っ二つなので、そこまで辿り着かない。実験をさせてみても、やはり理論と実験が真っ二つなので、結構、いや完璧に意味不明な使い用のない文章アウトプットがでてくる。学生時代ではそれでよかったかもしれないが、社会に出ると完全に使い物にならない。受験勉強の弊害なのか、誰もが羨む高学歴な人でもそうだったりする。知識はあるが知恵がない。
閑話休題
VMwareのOVA/OVFファイルで提供されたものをKVMで動かすようにする方法。
過去にVMware VMをOracle VirtualizationやOpenShift Virtualizationでも試したので確実に動くと思う。Oracle Virtualizationなどへの移行の時は、VMware VMがソースだったが、今回は、OVAファイルなので少し手順が違うというか楽。VMからの移行だとVDDKを使わなければならなかったが、OVAからだとイメージ変換から始められるので工程も時間も少なく済む。
さて、vmdkファイルをQcow2ファイルに変えらればいいと考えがちだが、そうは問屋が下さない。それは単純にイメージフォーマットを変換しただけにすぎないから。
OSがたとえ起動ができたとしても、ディスクコントローラーやNIC、付属するユーティリティが異なるために、イメージフォーマットを変換しただけでは、最悪はブートが始まらない、うまくいったとしてもディスクが見つからなくブートしない。まぁ、OVAファイルのVMがIDEとかドライバが特にいらない場合以外は、100%ブートしないと思う。
最低でもディスクコントローラーを変えないとブートしない。この作業は結構難しい。昔、SATAのコントローラーをIDE互換からAHCIに変えるときに苦労した人もいたはず。ドライバーを変えるとOSのカーネルがディスクをマウントできない。もちろん、BIOSやEFIなどのブートローダーも考慮しないと、IPL(死語)で起動できない。これを実現するには、一度起動して変更することなんだが。。。えっ、起動しないイメージを変換するために起動するとは?ちょっとトリッキーな行為が必要になる。基本的のP2VやV2V、V2Cのツールは必ずどこかでOSを起動させている。AWS VMDKimportもインポート後に一度中で起動させている。一度起動して構成変更したりしないと絶対に移行は完了しない。つまり、イメージ変換だけでは絶対に無理。
qemu-imgで変換と紹介しているケースもあるが、標準的なレガシーデバイス(IDEとか)ではないと起動しない。
以下にqemu-imgとvirt-v2vの特徴を調べてみた。
qemu-img
-
役割: ディスクイメージのフォーマット変換・操作ツール
-
できること
-
VMDK, QCOW2, RAW などのフォーマット間変換
-
ディスクサイズの拡張/縮小
-
イメージのコピー・クローン
-
できないこと
-
ゲストOSの中身を理解して修正すること
-
ドライバの入れ替え、initramfs/grub修正、VMware Tools 削除などは不可
「ファイル形式を変えるだけ」。変換後の VM が起動できるかどうかは保証しません。
virt-v2v
-
役割: 仮想化環境の移行専用ツール(VMware/Hyper-V → KVM)
-
できること
-
OVA/OVF/VMDK を読み込み、QCOW2 に変換
-
ゲスト OS を解析(libguestfs を利用)
-
VMware デバイス(lsilogic、e1000 など)を virtio に差し替え
-
fstab を UUID 化、initramfs 再生成、grub/EFI 設定修正
-
SELinux relabel、カーネルモジュール調整
-
firstboot スクリプトが設定されて VMware Tools 削除や qemu-guest-agent 導入をする
-
できないこと
-
Windows のドライバ導入を全自動で済ませること(virtio-win.iso が必要)
「OSごと安全にKVM向けに変換して起動できるように直してくれる」ツール。
まとめ表
項目
|
qemu-img
|
virt-v2v
|
---|---|---|
主用途
|
ディスクフォーマット変換
|
VM移行(VMware/Hyper-V → KVM)
|
OS認識
|
しない
|
する(libguestfsで中身を操作)
|
デバイス置換
|
しない
|
VMware→virtioへ変更
|
initramfs/grub修正
|
なし
|
自動修正
|
VMware Tools削除
|
不可
|
–firstbootスクリプトで実施
|
QEMU Guest Agent導入
|
不可
|
–firstbootで実施
|
Windows対応
|
形式変換だけ
|
virtio-win ISO追加で移行支援
|
-
単なる変換なら qemu-img(早いが、起動できる保証なし)。
-
確実に起動まで持っていくなら virt-v2v(OS内修正が自動で入る)。
一番簡単なのは、virt-v2vを使うこと。このツールは、イメージ変換をした後にQemuで起動をしてデバイスを書き換えてくれる。さらにvirt-v2vは進化をしているので、なるべく最新版を使うことをおすすめする。
環境
Qemuが動くPCあるいは仮想マシン(仮想マシンの場合は仮想化を有効にする。)
移行先の稼働させる環境ではなく、イメージ変換専用のホストを用意したほうがいい。
コンバートする仮想マシンのサイズに依存するが、仮想マシンが起動できる、CPU、メモリが必要。同時に複数の変換をするなら、複数のQemu VMが動かせるくらいのスペックが必要。
ネットワークはインターネットアウトバウンドが可能であること。
ディストリビューションは、virt-v2vに関しては実はUbuntuよりもRHEL系のほうが新しい。よって、今回はvirt-v2vは、RHEL10系のOracle Linux 10を使う。(RHEL10のサブスクリプション登録が面倒だったので)
Xwindowはいらないので最小のパッケージで構築
virt-v2v環境の構築
dnf install virt-v2v virt-v2v-bash-completion libguestfs-winsupport
libvirtやQemuなどがインストールされる

virt-v2v –version
virt-v2v 2.7.1rhel=10,release=4.0.1.el10
WindowsのOVAをインポートしたい場合は以下を実行する。
dnf install virtio-win
ただし、すべてのディストリビューションに、virtio-winは含まれていないので、以下でvirtio-winを入れる。Oracle Linux 10では必要だった。
rpm -ivh https://dl.rockylinux.org/pub/rocky/10.0/devel/x86_64/os/Packages/v/virtio-win-1.9.47-0.el10_0.noarch.rpm
移行元の動作イメージの用意
VMware ESXiで適当なイメージを用意しておく。ない場合は、ovftoolでovaファイルとしてエクスポートしておく。詳細は割愛。
RHEL 8.6 (サブスクリプション登録済み)とWindows Server 2022のOVAファイルを用意した。
virt-v2vでの変換
作成したOVAファイルを利用して、virt-v2vを行う。もし、OVFのディレクトリしかない場合は、OVFのディレクトリを指定して実行すればいい。変換後のイメージのディスクとネットワークは、virtioのドライバを使うようになっている。
mkdir -p /root/output
env LIBGUESTFS_BACKEND=direct \
virt-v2v -i ova /root/work/Source-VM.ova \
-o local -os /root/output \
-of qcow2 -on Converted-VM
Linuxをvirt-v2vを実行
メッセージを読むと初回起動で、Qemu guest agentをインストールすると出ている。(よって、Qemuにインポートした場合は、インターネットアウトバンドが有効なネットワークに接続し、dnfとかaptが使える状態にしておく必要がある。)

/root/output に生成されたイメージが出来上がっているはず。

ちなみに、xmlはKVMの構成情報。これを参照して、再構築してもいいし、新たに作っても問題ない。
Qcow2イメージを転送して、既存のHDDとしてvirtio接続のKVMゲストを構築すればいい。
変換後の起動確認
起動時に、Qemu Guest Agentがインストールされている。(RHEL 8.6にサブスクリプションを登録していたのはこのため)

パッケージを確認してみると、VMware Toolsもアンインストールされている。

Windowsをvirt-v2vを実行
この過程で一度、qemuで起動している様子

ちなみにVirtio-winが入っていないと以下のようになる。/usr/share/virtio-winがないか、フォルダの中が空。この場合は、virtio-winパッケージがインストールされているかどうかを確認

変換後の起動確認
何回も再起動をする。ログオンしようとしたら再起動、再起動後、またログオンしたら再起動。まるで再起動ループに入ったのではないかと錯覚するくらい。
その後、ログオンができた。
ドライバは問題なく適用されている。

Qemu Agentもインストールされている。よって、KVMのコンソールにはVMのIPアドレスが表示されているはず。

一度だけ、このエラーが出たが、2度目移行でなくなった。(目を離している隙に再起動されて処理されたのかもしれない。)
このエラーは、VMware Toolsをアンインストールをしようとすると発生するエラー。もし、これが出続けるのであれば、PowerShell Scriptで消せる。

ただ、IPv6のアドレスを大量に消費しているのが解せない。

以下を実行したら、IPv6の消費が少なくなったが。
netsh interface ipv6 set global randomizeidentifiers=disabled
netsh interface ipv6 set privacy state=disabled
いずれにせよ、事前に検証は必要で、流れも掴んでおく必要がある。
virt-v2vというツールは、Linuxだけではなく、WIndowsも対応していて、結構至れり尽くせりである。今回、OVAファイルを使ったが、VDDKを使ってあげれば、稼働しているvSphere VMから移行も可能。商用のツールによっては、VMware ToolsやQemu Guest Agentの面倒を見てくれないので、こっちの方が無償で便利かもしれない。(RHELは有償。それ以外だと無償で使える。)