ProxmoxにESXiからゲストをインポート

りっちゃん

2024年8月20日 17:48

他の仮想基盤製品をProxmoxに移行

よくある話でProxmoxに今まで使っていた仮想マシンを移植したいと思うのは当然のこと。代表例としてESXiで動いている仮想マシンを移行してみる。
細かな部分はこちらを参照して欲しい。

■標準的な移行の説明

■P2V,V2Vに関する説明

ESXiとの接続

まずはESXiに接続してデータストアの情報が見れるようにする。
[データセンタ]-[ストレージ]-[追加]-[ESXi]

　ID ：接続先のESXiまたはvSphere名
　サーバ　　：ESXiorvSphereのIP
　ユーザ名　：rootまたはAdministrator等
　パスワード：rootまたはAdministratorのパスワード
　ノード　　：登録先のProxmox名
　有効　　　：■
　Skip Certificate Verification：■※
　※外部で証明できる有効な証明書があれば：□

ESXiからのVMインポート（Windows編）

例として「Win2019」と書いてあるゲストをインポートする

仮想ハードウェアの情報はこんな感じ

それでは早速インポートしてみよう。先ほどESXiの認証情報を使って接続したストレージの配下に仮想マシンの仮想ディスクリストが表示されるので選んでインポートをクリックする。
[データセンタ]-[ノード名]-[ESXi名]-[Virtual Guests]-[インポート]

インポート用の設定ウインドウが開くので以下を参考に設定する。
　VM ID　　：既存とぶつからない番号
　ソケット　：ESXiからの引継ぎ数または任意の数値
　コア　　　：ESXiからの引継ぎ数または任意の数値
　メモリ　　：ESXiからの引継ぎ数または任意の数値
　名前　　　：ESXiからの引継ぎ名または任意の名称
　CPU type　：既定値（動作可能なタイプに修正）
　OS種別　　：既定値
　バージョン：既定値
　Default Storage ：インポート先のストレージ
　形式　　　　　：qcow2
　Default Bridge ：VM割り当て用のBridge用NIC名
　Live Import　　：□インポート後に起動する場合はチェック

ESXi上でゲストが起動していると上記「警告」が表示される。※事前に停止すること。

インポートが開始されるとこんな感じで進捗が表示される。インポート速度はネットワーク帯域とストレージ側の処理性能、今回で言うとESXi側の処理性能、Proxmox側の処理性能によって変わる。もちろんインポートディスクが大きければそれだけ時間もかかるので事前に自分の環境でどのくらいの転送性能がでるのかは、実験しておくと良い。

ちなみに、今回のゲストは・・・150GBで１５時間もかかった。前にテストした感じだと１時間もあれば終わってるハズだったんだけど。どうしてだろう？

【インポートテスト（環境による差が大きい部分）】

　■インポート構成①
　・1Gbps１本：NAS→コンバート→NAS
　　16GB： 6分
　　40GB：13分
　　100GB：30分
　■インポート構成②
　・1Gbps１本：ESXiローカルSSD→コンバート→NAS
　　120GB：30分

【インポート後の対応】

ここは一発インポートした仮想マシンを「開始」してみる。普通に起動するのかと思いきや・・・予想通りの画面である。

移行直後のハードウェアはこうなってるのでProxmoxで起動できるように再調整する。基本的にハードウェア設定の修正が反映されるタイミングは仮想マシンが再起動ではなくシャットダウンされた状態となるので設定変更タイミングは注意すること。

①ハードディスク
　[ハードディスク(scsi#)]-[デタッチ]

　[未使用のディスク #]-[編集]-[追加]

すべてのハードディスクを同じようにIDEとして追加し直す。

②とりあえず、ここまで修正できたら「開始」をクリックする。どうだろう？Windowsのログイン画面が無事に表示されたかな？

コンソールから「A」→「■■ ■ （Ctrl＋Alt＋Delの略)」をクリックする

③VMwareToolsのアンインストール

④VirtIOドライバーのインストール
　isoは事前にダウンロードして準備しておく。
　https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers

⑤Windowsの「SCSIコントローラ」をVirtIO SCSIに変更
　ここは仮想マシンをシャットダウンしてから実施する。

選択して「編集」をクリック

「VirtIO SCSI」になったことを確認

⑥WindowsのハードディスクをSCSIタイプに変更
詳しくはこちらを参照
■Windows 用準仮想化ブロックドライバー
https://pve.proxmox.com/wiki/Paravirtualized_Block_Drivers_for_Windows

単純にハードディスクタイプをSCSIに修正するだけではブルースクリーンとなって正常に起動できないので以下の手順を踏む。この部分を詳しく書いた記事があまりなかったので手探りで調べてみた。

「VirtIO Block」のディスクを一時的に追加する

追加されたことを確認する

仮想マシンを起動して追加したディスクが「ディスクの管理」に表示されることを確認する。ディスクとして認識できればOKなのでフォーマット等は必要ない。

仮想マシンをシャットダウンして初めに追加した1GBのディスクを削除してから元のOSディスクタイプを「VirtIO Block」に修正する。

ディスクを再登録する順番は要注意。起動用ディスクから登録する。

仮想マシンを起動すると今度はSCSIドライバー起動としてサクッと起動が完了する。IDEに対してずいぶんと起動時間が短縮される。

起動後のディスクのプロパティでは「Red Hat VirtIO SCSI Disk Device」として表示された。

⑦ネットワークデバイス
　[ネットデバイス(net0)]-[編集]-[モデル]
　・Intel E1000 → VirtIO(準仮想化)

⑧その他
　・Windowsのライセンス認証を要求されるので再認証を実施する
　・デバイスマネージャー等でエラーとなったものを修正する
　・イベントログでエラーとなったものを修正する

VMwareTools がアンインストールできなくなった場合

以下のPowerShellスクリプトを保存して実行する。実行後に再起動すればアンインストールは完了する。

完了したら再起動

Remove_VMwareTools.ps1

ESXiからのVMインポート（Linux編）

例として「CUPS」と書いてあるゲストをインポートする
ちなみにCUPSはプリントサーバです。我が家でスマートフォンやChromeBookから一般プリンターを使うために踏み台にしています。
https://www.cups.org/

仮想ハードウェアの情報はこんな感じ

インポートが開始されると進捗が表示される。ちなみに、今回のゲストは・・・16GBで４２分かかった。前にテストした感じだと６分もあれば終わってるハズだった。環境の違いか？

【インポート後の対応】

ここは一発インポートした仮想マシンを「開始」してみる。普通に起動する・・・おそらく元からSCSI系のドライバーでディスクが認識されていることが理由らしい。

移行直後のハードウェア設定については少し最適化しておく。基本的にハードウェア設定の修正が反映されるタイミングは仮想マシンが再起動ではなくシャットダウンされた状態となるので設定変更タイミングは注意すること。

①「SCSIコントローラ」をVirtIO SCSIに変更
　ここは仮想マシンをシャットダウンしてから実施する。

選択して「編集」をクリック

「VirtIO SCSI」になったことを確認

②ネットワークデバイス
　[ネットデバイス(net0)]-[編集]-[モデル]
　・Vmware vmxnet3 → VirtIO(準仮想化)

仮想マシンを起動してコンソールを開いて以下のコマンドを実行してインターフェースを認識しているか確認する。

# ip add

エディタでネットワーク設定を編集する

cd /etc/netplan
sudo vi  00-installer-config.yaml
　：ens160　→　enp6s18

編集前がこの状態

編集後はこの状態

ネットワーク設定を有効化する

sudo netplan apply

Pingを実行してネットワークが開通したことを確認する

ping 192.168.1.254

今回はインターネットに接続できる環境なのでチョイチョイとエージェントをインストールしてみる。

sudo apt install -y qemu-guest-agent
sudo systemctl enable qemu-guest-agent
sudo systemctl start qemu-guest-agent

できればエージェントをインストールしておきたいが、できなかった場合はそのまま使うことになるかな。

ESXiからのVMインポート（コマンド編）

インポートとの流れとしてはProxmoxサーバから VMDK ファイルにアクセス可能な環境をつくりディスクイメージを QCOW2 に※変換。仮想マシンのディスクとして紐づけする。
※Proxmox自体はvmdkに対してアクセスできるのでqcow2への変換は必須ではないけれど、ケジメ？

ESXi側のストレージは様々な形態であるため、環境にあった方法でVMDKにアクセスできるようにすること。

今回はESXi上で動かしていた「Minecraft」サーバをインポートしてみる。
まずはインポート先となる仮想マシン「フォルダ」を作成する。
Proxmoxで仮想マシンを作成するが、ポイントは新規で仮想ディスクを作成せずに仮想マシンの構成のみ手動で実施する。
[VMを作成]-[全般]-[OS:メディアを使用しない]-[システム]-[ディスク:なし]-[CPU]-[メモリ]-[ネットワーク]

イメージのコンバートを実行する

# qemu-img convert -f vmdk /mnt/pve/esxiDatastore/Minecraft/Minecraft.vmdk -O qcow2 /mnt/pve/NAS_Storage/images/1001/vm-1001-disk-0.qcow2

動きをみる限り vmdk を読み出しながら qcow2 として書き出している。その進捗が表示されるとわかりやすいが、コマンドの実行としては応答待機状態となるのでわかりにくい。　書き出し先で ls -la を実行すると徐々にファイルサイズが大きくなるのがわかる。

移行元のディスクサイズ　40GB　、　移行先のディスクサイズ　18GB
タイムスタンプから推測すると　18GBの転送：16分くらい？　これも環境によると思われる。転送容量は実用量と思われる。1GBで1分くらいの感覚。

ディスクを追加する。WebGUIから既存のディスクイメージを接続できれば良いが現在はコマンドのみで実行可能。

■パスは環境に合わせて変更する
qm set <VMID> -virtio0 /mnt/pve/NAS_Storage/images/<VMID>/vm-<VMID>-disk-0.qcow2

「update VM <VMID>」が表示されればOK

とりあえず、起動してみる。。。

なにが不味かったのか調査。
ディスクのコンバートのやり直し・・・vmdkとしてマウントする。scsiやideとしてマウントやり直す。色々試したけどダメだった。
あと、コンバートをやり直したらディスクは１個だけとなった。理由は不明。

色々悩んでいると、ふと気になったので仮想マシンの構成データを直接確認してみる。

■普通に起動できるLinux系設定
/etc/pve/qemu-server# cat 1000.conf
boot: order=sata0;scsi0
■今回起動できないLinux系設定
/etc/pve/qemu-server# cat 1001.conf
boot: order=net0

なるほど、起動対象情報としてディスクがなかったのね。

[編集]をクリックして起動情報を編集する

はい、起動してみる。
わかってしまえば簡単である。

あとはネットワークの修正です。仮想マシンをインポートした場合はNIC名称が変更となるので新しく認識したインターフェース名に修正すれば完了。

ProxmoxにESXiからゲストをインポート

他の仮想基盤製品をProxmoxに移行

ESXiとの接続

ESXiからのVMインポート（Windows編）

【インポートテスト（環境による差が大きい部分）】

【インポート後の対応】

VMwareTools がアンインストールできなくなった場合

Remove_VMwareTools.ps1

ESXiからのVMインポート（Linux編）

【インポート後の対応】

ESXiからのVMインポート（コマンド編）

いいなと思ったら応援しよう！