自宅ラボの仮想化基盤を VMware ESXi から Proxmox VE に移行した。

動機

自宅ラボでは2台の物理マシンに VMware ESXi をインストールして仮想化基盤を構築しているが、VMUG Advantage 会員になることをケチっていたため vMotion を使えない状態だった。 仮想ホストのメンテナンスをしようと思っても VM の停止を許容するしかなかった。

そんな折、オープンソースの Proxmox VE という仮想化プラットフォームの存在を知った。 Proxmox VE であれば無償で仮想化基盤の HA クラスタを組むことができるとのことで、ESXi から Proxmox VE に切り替えることにした。

AWS SAA の勉強をしないといけない現実から目を逸しているだけ。

Proxmox VE とは

Proxmox VE (Virtual Environment) は、Debian ベースの仮想化プラットフォームで、KVM による仮想マシン環境と LXC によるコンテナ環境が提供されるらしい。 KVM も LXC も使ったことがないので実際どんなものかは分からない。

複数の物理マシンを用意すれば無償でクラスタを組むことができる（大事になことなので2度言う）点が VMware 製品とは異なり、個人的に大きなメリットと感じた。

また、試せてはないけど Proxmox VE のストレージとして Ceph を構築できるらしい。 物理マシンがもう1台欲しくなっちゃうけど時期が悪すぎる。

Proxmox VE 導入

ESXi から Proxmox VE に VM を移行する。 手順は Proxmox 公式 Wiki の Migration of servers to Proxmox VE を参考にした。

VM 個別ではなく ESXi 全体を一気に移行する Server self-migration の手順も記載されていたけど、ビビって VM 個別に対応した。 そもそも普段からバックアップを取っていればビビる必要はない。

VM エクスポート

ESXi からすべての VM のバックアップを取得する。

VM を停止させた状態で Web コンソールから OVF (Open Virtualization Format) を含めた以下の各種ファイルをダウンロード。 ISO もダウンロードできたけど Proxmox VE へのインストールには不要だった。

  • .ovf
  • .vmdk
  • .mf
  • .nvram

今回は Proxmox から参照しやすくするため、バックアップファイルを NAS に保存。

Proxmox VE インストール

公式サイトから ISO イメージをダウンロードして USB メモリに焼き、物理マシンに USB メモリを挿して起動。 USB 経由でブートが起動してこなかったので UEFI から USB ブートを許可設定した。

Proxmox VE のインストーラが起動したら、画面に従って初期設定をおこなう。 特段、難しい設定項目はないので手順は省略（スクショ撮ってないだけ）。

インストール完了後に再起動するので、起動してきたらブラウザでアクセスして Proxmox VE を管理できる。

NAS ストレージ追加

我が家では NAS として Synology DS220j を導入していて、NFS の設定までは完了している。 Proxmox VE から NFS で NAS をマウントして利用するために、「ストレージ」画面で以下のような設定をおこなう（スクショは設定完了後のもの）。

IP 直打ちなのは DNS サーバも VM で動かしているので、移行時に DNS が使えず名前解決できなくなるため。

VM インポート

VM のバックアップファイルを使って Proxmox VE に VM を作成する。

Proxmox VE に SSH でログインするか、Web コンソールからノードのメニューから「Shell」を選択する。 Web コンソールのほうが手っ取り早く利用できて便利だった。

Wiki に記載の通り、インポートには qm importovf コマンドを使った。 コマンドの引数/オプションと実際の設定値は以下の通り。

qm importovf <vmid> <manifest> <storage> [OPTIONS]

  • vmid

    Proxmox VE クラスタ内 VM のユニークな ID を指定。 100 から連番に使っていった。

  • manifest

    OVF ファイルのパス。 Proxmox VE のストレージとして NAS をマウントしており、OVF ファイルは /mnt/pve/nas/images/ 配下に格納されいた。

  • storage

    VM のイメージファイルを格納するストレージ名。 初期状態では local と local-lvm の2種類のストレージが存在していたので、local-lvm を選択。

    ESXi 側で複数ストレージをマウントしている VM もあって、それぞれ .vmdk ファイルとしてダウンロードしていた。 qm importovf コマンドでは各 .vmdk ファイルごとに格納するストレージを選択することはできないみたい。

  • --format

    作成する VM イメージファイルのフォーマット (qcow2 | raw | vmdk) を指定。

    今回は qcow2 を選択。 VMware 用のフォーマット vmdk も選択可能だったけど、イメージのスナップショットやシンプロビジョニングを利用するには qcow2 を選択する必要があったので。

    ちなみに qcow は QEMU Copy On Write の略語らしい。

  • --dryrun

    ドライラン。

qm imporovf コマンドを Proxmox VE のシェルで実行すると、.vmdk ファイルが個別にインポートされていく。 .ovf ファイルに利用する他のファイルの情報が記載されていて、これを参照しているらしい。

進捗が表示されるのでしばらく待つ。 30 GB くらいの VM であれば 5～10 分ほどで完了した。

root@pve1:~# qm importovf 100 /mnt/pve/nas/images/example/example.ovf local-lvm --format qcow2
  Logical volume "vm-100-disk-0" created.
transferred 0.0 B of 16.0 GiB (0.00%)
transferred 163.8 MiB of 16.0 GiB (1.00%)
transferred 327.7 MiB of 16.0 GiB (2.00%)
(snip)
transferred 16.0 GiB of 16.0 GiB (100.00%)

VM 設定

ここからが本記事のメイン。

インポートが完了後に Web ブラウザから VM を起動して状態を確認したところ、Booting from Hard Disk... というメッセージとともに固まっていた。 残念ながらインポート直後の設定ではうまく起動しなかった。

VM の「ハードウェア」の設定を見てみると、下図のようになっていた（スクショを撮り忘れて違う VM を作成して再現したので VMID とかは異なる）。

VM を起動させるために試行錯誤して、最終的には以下の設定をすることで VM の起動に成功している。 ここからは以下の設定に辿り着いた試行錯誤を記録しておく。

BIOS

はじめに、デフォルトの SeaBIOS というものから UEFI への変更が必要だった。

UEFI を使う場合は EFI ディスク の追加も必要で、「追加」ボタンから EFI ディスクを選択して追加。 イメージの格納場所を指定するが、今回は VM イメージと同じ場所 (local-lvm) を指定した。

この状態で起動すると一歩前進、EFI Shell というものが起動してきた。 EFI Shell を操作したら起動しないかと試してみたけど無理だったので、次のパターンを探った。

SCSI コントローラ

ネットで情報を漁ったところ、「SCSI コントローラを VMware PVSCSI にすればよい」という情報を見かけた（どのサイトか失念してしまった…）。

SCSI コントローラをデフォルトの LSI 53C895A から VMware PVSCSI に変更したところ、無事にブートローダが起動した（ブートローダであってるかな？）。

しかし、CPU does not support x86-64-v2 というエラーで kernel panic が発生してしまったので、次の一手を探すことに。

あと、試行錯誤の途中でディスクを IDE 接続に変更するパターンも試してみたらこちらでも起動したけど、IDE は SCSI より性能が劣るという認識なので SCSI で使いたかったので不採用とした。

プロセッサ

ちょうど Red Hat のナレッジベースに同じメッセージの Issue が上がっていた。 タイトルは Hyper-V となっているけど、コメントに QEMU も同じ問題が発生しているとあった。

[Hyper-V] RHEL 9 guest panic's during boot with following error Fatal glibc error: CPU does not support x86-64-v2

どうやら RHEL 9 は x86-64-v2 アーキテクチャ向けにビルドされていて、かつ QEMU がエミュレートする CPU が x86-64-v2 をサポートしていないため CPU does not support x86-64-v2 というエラーが発生するとのこと。 赤帽エンジニアブログに翻訳記事があったが、CPU 関連の知識が無さ過ぎてなにが書かれているのかサッパリ。

とにかく、CPU 周りがよろしくないということで、プロセッサの「種別」をデフォルトの kvm64 から EPYC/AMD に変更したところ、うまく起動してきた。 EPYC/AMD を選択したのは、移行1台目の物理マシンが AMD CPU を使っていたため。

しかし、EPYC/AMD のままでは後述するクラスタ構築後のマイグレーションで Intel マシンに VM を移動できなかった。 そこで、プロセッサ種別を host に変更すると Intel/AMD に関係なく起動する VM ができあがった。 host を使うデメリットがありそうではあるが…。

マシン & ネットデバイス

ここまでの設定で VM が起動するようにはなったが、追加でマシンとネットデバイスの設定をおこなった。

マシンのほうは、設定項目として i440fx と q35 の2通りのチップセットがあるが、q35 を選択している。 両者とも初耳だったのでググったところ、i440fx は PCI のみをサポートする古いチップセット (1996) で、q35 は比較的新しく (2007)、PCIe をサポートしているということがわかった。 PCI/PCIe どちらも使う予定がなかったけど、新しい q35 を選んだ。

Virtualized Windows 10 – i440FX vs Q35

ネットデバイスは、VM をネットワークに接続するために必要なので追加した。 モデルは色々選択できるようだけど、SCSI ドライバと同じように VMware vmxnet3 を使っている。

以上で VM の移行が完了、あとはひたすら2台分の VM をインポート & 設定変更するだけ。

Proxmox VE HA クラスタ構築

2台の物理マシンを Proxmox VE に移行できたのでクラスタを組む。 クラスタを利用しないと Proxmox VE に移行した意味がない。

下図はクラスタ構築後のスクショだけど、1台目のノードで「クラスタを作成」して「Join情報」を使って2台目で「クラスタに参加」するだけ、とても簡単にクラスタを組めた。

クラスタを組んだあとは VM のマイグレーションを試してみた。 前述のプロセッサの問題が見つかったけど、対処して無事にマイグレーションも成功している。

感想

なんとか ESXi から Proxmox VE への移行が完了して安堵。

想定より時間が掛かってしまったけど、主に VM の移行作業と調査に時間を取られていて、Proxmox VE 自体のインストールはとても簡単だった。 ESXi のときは NIC が対応してないだのなんだのあって大変だった記憶がある。

今までは VM 内の IaC しかできていなかったけど、Ansible も Terraform も Proxmox VE に対応しているようなので仮想ホスト側の IaC も進めていきたいところ。