自宅での実験場としている仮想化プラットフォーム (仮想化基盤) のProxmox Virtual Environment (Proxmox VE) を、7系から8系へアップグレードしてみました。作業は次の公式ドキュメントに沿って進めまして、本記事には作業時の要点をメモしておきます。
以下の見出しに付与している番号は、公式ドキュメントでのセクション番号と対応させています。
既存PVEのアップグレードをaptコマンドを使って行います。
前提条件が9つ書かれていますので事前にクリアしておきます。
apt upgrade
を完了して7系最新版へ更新しました$ pveversion
pve-manager/7.4-17/513c62be (running kernel: 5.15.126-1-pve)
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pve-root 94G 8.3G 81G 10% /
アップグレード作業は、clusterに属するそれぞれのPVEノードのCLIで行う必要があります。また、作業はPVEの直接コンソールまたはSSH経由で行います。PVEのGUIで提供される仮想コンソールを通じて作業してはいけません (アップグレード途中で中断してしまうため)。
pve7to8
というコマンドを使って、アップグレード前のPVE環境の事前チェックを行います。
$ sudo pve7to8
= CHECKING VERSION INFORMATION FOR PVE PACKAGES =
Checking for package updates..
PASS: all packages up-to-date
Checking proxmox-ve package version..
PASS: proxmox-ve package has version >= 7.4-1
Checking running kernel version..
PASS: running kernel '5.15.126-1-pve' is considered suitable for upgrade.
= CHECKING CLUSTER HEALTH/SETTINGS =
SKIP: standalone node.
= CHECKING HYPER-CONVERGED CEPH STATUS =
SKIP: no hyper-converged ceph setup detected!
= CHECKING CONFIGURED STORAGES =
SKIP: storage 'google-cloud-storage' disabled.
PASS: storage 'local' enabled and active.
PASS: storage 'local-lvm' enabled and active.
PASS: storage 'qnap' enabled and active.
INFO: Checking storage content type configuration..
PASS: no storage content problems found
PASS: no storage re-uses a directory for multiple content types.
= MISCELLANEOUS CHECKS =
(省略)
= SUMMARY =
TOTAL: 33
PASSED: 24
SKIPPED: 7
WARNINGS: 0
FAILURES: 0
pve7to8 --full
でもサマリーは同じ状態になりました。総じて問題はなさそうです。
$ sudo pve7to8 --full
(省略)
= SUMMARY =
TOTAL: 33
PASSED: 24
SKIPPED: 7
WARNINGS: 0
FAILURES: 0
PVEが7.4-15以上になっていることを最終確認します。
$ sudo apt update
(省略)
All packages are up to date.
$ sudo apt dist-upgrade
(省略)
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$ pveversion
pve-manager/7.4-17/513c62be (running kernel: 5.15.126-1-pve)
sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
公式ドキュメントにある上記コマンドは、ファイル/etc/apt/sources.list
内の、Debianのバージョンを示すコードネーム文字列「bullseye (Debian 11)」を「bookworm (Debian 12)」に置換せよという意味だと読み取れます。今回の環境では、PVEのデフォルト状態にtailscaleとzabbixのリポジトリを別ファイルで追加している状態だったので、下記のように、それらに関する別ファイルも同様に書き換えておく必要がありました。
## 別ファイル書き換えの例
$ grep -R bullseye /etc/apt/
$ sudo sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list.d/HOGE1.list
$ sudo vim /etc/apt/sources.list.d/HOGE2.list
4.3.3.1で行った置換をチャラにすることになりますが、今回の環境はPVEを無償版として使用するので、/etc/apt/sources.list
を、No-Subscription向けのリポジトリを記述したProxmox VE No-Subscription Repositoryの内容へとまるごと入れ替えます。
$ cat /etc/apt/sources.list
deb http://ftp.debian.org/debian bookworm main contrib
deb http://ftp.debian.org/debian bookworm-updates main contrib
# Proxmox VE pve-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
# security updates
deb http://security.debian.org/debian-security bookworm-security main contrib
今回の環境ではCephは使用していませんが今後使用するかもしれないので、CephのNo-Subscription向けリポジトリを追加しておきます。
$ sudo -s
$ echo "deb http://download.proxmox.com/debian/ceph-quincy bookworm no-subscription" > /etc/apt/sources.list.d/ceph.list
編集したリポジトリ情報を用いてapt update
が問題なく行えるかを確認します (余談: 今回の環境におけるzabbixのリポジトリとしてUbuntu用を使っているのは何らかの運用上の都合ですかね?>過去の自分)。
$ sudo apt update
Hit:1 http://security.debian.org/debian-security bookworm-security InRelease
Hit:2 http://download.proxmox.com/debian/pve bookworm InRelease
Hit:3 http://download.proxmox.com/debian/ceph-quincy bookworm InRelease
Get:4 https://repo.zabbix.com/zabbix/5.4/ubuntu focal InRelease [4,958 B]
Hit:5 http://ftp.debian.org/debian bookworm InRelease
Get:6 https://pkgs.tailscale.com/stable/debian bookworm InRelease
Hit:7 http://ftp.debian.org/debian bookworm-updates InRelease
Fetched 11.5 kB in 6s (1,869 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
625 packages can be upgraded. Run 'apt list --upgradable' to see them.
PVEを実際にアップグレードするためにapt dist-upgrade
を実行します。
$ sudo apt dist-upgrade
(省略)
625 upgraded, 145 newly installed, 4 to remove and 0 not upgraded.
Need to get 640 MB of archives.
After this operation, 1,071 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
実行中、公式ドキュメントに言及されている問い合わせが表示されます。今回の環境では次のような選択を行いました。
/etc/issue
: defaultのNを選択/etc/lvm/lvm.conf
: LVMに関して特別な変更をしていないので上書きのYを選択/etc/ssh/sshd_config
: 問い合わせが現れませんでした/etc/default/grub
: 新旧の差分を表示して確認したあと、上書きで問題ないと判断してYを選択/etc/apt/sources.list.d/pve-enterprise.list
: 上書きのYを選択 (No-Subscription向けリポジトリへの変更は後ほどPVEのGUIでも行えるため)apt dist-upgrade
の完了後に再確認の意味でpve7to8
を実行しますと、表示されたのは「rebootをまだ行っていませんね」的なWARNINGSばかりだったので、PVEのアップグレードのやり残しはないと判断できました。
そしてPVEノードの再起動を行った後にpveversion
でPVEのバージョン確認を行ったところ、以下のように8系へ更新できていることが確認できました。各VMの起動も正常でした。
$ pveversion
pve-manager/8.0.4/d258a813cfa6b390 (running kernel: 6.2.16-15-pve)
今回のstandalone環境ではもちろん1台分で作業完了です。cluster構成を組んでいるのであれば、残りのPVEノードを1台ずつアップグレードせよとのこと。
上記とは別の実験環境 (マザーボード上の有線NICのドライバとしてe1000eを使用するハードウェア) のProxmox VEを、7系から8系へupgradeしたところ、有線接続のネットワークが使えなくなる現象に遭遇してしまいました。原因究明よりも復旧を急ぐべき状態だったため、山勘でKernelだけをupgrade前のものに戻して起動したところ、正常にネットワークが使える状態に戻ることが分かりました。
PVEバージョン | Kernelバージョン | 状況 |
---|---|---|
7系 (忘却) | 5.15.126-1-pve | 異常なし |
8系 (8.0.4) | 6.2.16-18-pve | 有線接続のネットワークが不通になる |
8系 (8.0.4) | 5.15.126-1-pve | 異常なし |
とりあえず、PVEは8系だけどもKernelはひとつ前、という組み合わせで仮想化プラットフォームの利用を継続するためには、(起動時にGRUBで都度手動選択をするわけにはいかないので) デフォルトKernelをひとつ前のものへ切り替えておく必要があります。この切り替えが可能なコマンドとして、PVEにはproxmox-boot-tool
が用意されていると知り、次のように実行したところ、デフォルトKernelを切り替えることができました。
# proxmox-boot-tool kernel pin 5.15.126-1-pve
Setting '5.15.126-1-pve' as grub default entry and running update-grub.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.2.16-18-pve
Found initrd image: /boot/initrd.img-6.2.16-18-pve
Found linux image: /boot/vmlinuz-5.15.126-1-pve
Found initrd image: /boot/initrd.img-5.15.126-1-pve
Found linux image: /boot/vmlinuz-5.15.30-2-pve
Found initrd image: /boot/initrd.img-5.15.30-2-pve
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Adding boot menu entry for UEFI Firmware Settings ...
done
なぜupgrade後にネットワークが不通になったのか。今思えば、8系でNICの名前が変更されて再設定が必要になったからという可能性もあるかもしれません。 ←これは憶測に過ぎない。実際はkernelの変更に伴う何らかの問題と思われる。[2024-05-28]