「Proxmox VE」のリポジトリ構成を理解してホストをアップデートしよう

はじめに

前回は、「Proxmox VE」のISOイメージを使用したインストールと、Web管理画面へのアクセス方法までを解説しました。

インストール後、各種設定を行う前に、まずはProxmoxのアップデートを行い、バージョンを最新化しておくことをお勧めします。ISO イメージはマイナーバージョンリリース時点のパッケージセット(9.1-1、9.2-1など)で構成されており、公開後に提供された不具合修正やセキュリティアップデートは含まれていないためです。

そこで今回は、Proxmox VEホストのアップデート方法と、その理解を深めるためにリポジトリ、カーネル、パッケージなどの関連要素について解説していきます。

リポジトリ

Proxmox VE はパッケージ管理に APT を使用しており、更新に利用する APT リポジトリは大きく「Debian ベース」リポジトリと「Proxmox VE 向け」リポジトリに分けられます。

まずは、これらの違いについて説明します。

「Proxmox」リポジトリ・「Debian」リポジトリ

大きくはProxmox 固有のパッケージが格納されているリポジトリと、Debian 共通のパッケージが格納されているリポジトリに分類されます。

カーネル・パッケージ

次に、Proxmoxリポジトリ・Debianリポジトリに格納されているカーネル・パッケージについて説明します。

Proxmox カーネル

Proxmox VEはDebianベースと公式ドキュメントなどでも説明されますが、「Proxmoxカーネル」というUbuntuカーネルをカスタマイズしたものを利用しています。

前回で「Proxmox VEのHCLは公開されていませんが、Proxmox VEはUbuntuカーネルを基にしたカスタムカーネルを使用しているため、Ubuntu認定サーバーをハードウェア互換性確認の参考にすることは有効」と説明した理由はここにあります。

Proxmox パッケージ

Proxmox の独自パッケージです。pve-manager、pve-ha-manager、pve-cluster、pve-container などがあります。

主要パッケージ

ZFS、Ceph、QEMU/KVM、カーネルなどの主要パッケージについては、独自にビルド・調整したパッケージを Proxmox リポジトリで提供しています。

Debian リポジトリにも同名または同種のパッケージが存在する場合がありますが、Proxmox 版は -pve や +pve などのリビジョンを持ち、Debian 版より新しいバージョンとして扱われることが多いため、APT の通常ルールにより Proxmox 版がインストール候補になります。

そのため、Proxmoxの動作に必要なパッケージの多くがProxmoxリポジトリから適用されます。

「Test」「No-subscription」「Enterprise」リポジトリ

Proxmoxリポジトリは、さらに「Test」「No-subscription」「Enterprise」の3種類のリポジトリに分かれます。

この表だけを見ると各リポジトリの違いが分かりづらいですが、誤解を恐れずに言えばTestリポジトリはアルファ版、No-subscriptionリポジトリはベータ版、Enterpriseリポジトリは正式版と言って良いと思います。
※コミュニティフォーラムでも散見される表現です。

Test・No-subscription リポジトリは無料で公開され、ユーザーによるフィードバックを受けます。Enterpriseリポジトリでは、それらに加えて開発元による動作検証を経てから公開されます。

提供時期の違いを除けば、各リポジトリに機能的な差はないため、バグの量・安定動作するかの違いと言えます。

また、Enterprise リポジトリの利用にはサブスクリプションを契約し、ホストにサブスクリプションキーを設定、アクティベーションを行う必要があります。アクティベーションはshop.proxmox.comへの定期的な通信が必要です。

Test・No-subscription リポジトリ運用時の注意点として、開発元からのアナウンス粒度が異なる点が挙げられます。

Test・No-subscription リポジトリは、新機能評価やデバッグの意味合いも強いため、日常的に内容が更新されます。

また、影響規模の大きい変更が加えられた際に、コミュニティフォーラムでの周知にとどまったり、周知がない場合もあります。

そのため、Test・No-subscription運用時にはコミュニティフォーラムで情報収集や適用前の確認をすることが重要になります。

直近の例を挙げるなら、Linux カーネル 6.17 から 7.0 系に変更になるタイミングと、CVE-2026-31431(通称 Copy Fail)の対応が重なるタイミングがありました。

No-subscriptionリポジトリを利用しているユーザーたちが脆弱性対応のためにパッケージのアップデートを行ったところ、Linux 7.0 系のカーネルが適用され動作に問題が起きてしまうという事象もありました。

もちろん、コミュニティフォーラムでの周知や適用前のパッケージ一覧に目を通していれば防げた問題であるため、Test・No-subscription リポジトリを利用することに問題があるというわけではありませんが、プライオリティの高い環境で利用する際は注意が必要です。

アップデート

ここからは、実際にアップデートを行うために必要な設定を行い、アップデートを実施していきます。

なお、今回紹介するのはインターネット接続環境がある場合の手順になります。もしプロキシ等を使ってもインターネットに接続できない完全なオフライン環境の場合には、「Proxmox Offline Mirror(POM)」を利用することで、を利用することで、オフラインアクティベーションやオフラインミラーによるアップデートが可能です。

プロキシの設定(プロキシ経由でインターネット接続する場合)

前述の通り、各リポジトリやアクティベーション用のサーバーはインターネット上に存在します。環境によってはインターネットに直接接続できずに、プロキシ経由での接続が必要な場合もあります。データセンター-オプション-HTTPプロキシからhttp://username:password@host:portの形式で設定できます。

この設定は Proxmox としてのプロキシ設定であり、Linux OS としてのプロキシ設定とは異なる点に注意が必要です。また、Linux OS として設定してもProxmox のプロキシ設定としては反映されません。その逆についても同様です。

サブスクリプションキーのアクティベーション(Enterpriseリポジトリの場合)

Enterpriseリポジトリを利用する場合は、サブスクリプションキーのアクティベーションが必要です。対象PVEノード-サブスクリプション-サブスクリプションキーのアップロードからサブスクリプションキーを登録します。

リポジトリの変更(Enterprise以外のリポジトリの場合)

デフォルトではEnterpriseリポジトリ(Cephを含む)が有効に設定されています。そのため、Test・No-subscriptionリポジトリを利用する場合は、利用するリポジトリを変更する必要があります。

なお、Test・No-subscription リポジトリはアクティベーションしなくても利用できるため、前述のアクティベーションの設定は不要になります。

1. 対象PVEノード-アップデート-リポジトリを選択を選択
2. Enterpriseリポジトリ(CephのEnterpriseリポジトリを含む)を選択し、上部の無効を選択
3. 上部の追加から利用するリポジトリを選択

アップデートの実施

Proxmox VEのアップデートでは「pveupdate」「pveupgrade」という apt (厳密にはapt-get) をラップしたコマンドが利用されます。

GUI であれば pveupdate、pveupgrade でアップデートを実行できますが、Linux 有識者であればこそCLIから apt コマンドでアップデートしてしまうというケースもあるので、注意が必要です。

CLIからアップデートする場合は、apt upgrade ではなく apt full-upgrade(apt-get dist-upgrade)を使用するよう公式ドキュメントで案内されています。一般的なDebian系の運用で使われる apt upgradeとは異なります。

1. 対象PVEノード-アップデート-再表示を選択
2. アップデートパッケージの一覧が更新されるので、内容を確認しアップグレードを選択
3. ポップアップが表示されアップデートが開始される。アップデートの適用確認を求められた場合はYを入力する
4. 適用後、システム再起動を推奨された場合(カーネル更新が含まれる場合など)は再起動する

おわりに

今回は、Proxmox VEのアップデートや関連する要素について説明しました。

その他の設定(ネットワーク、ストレージ、クラスタなど)については後続の各回で解説していきますが、まずは実際に使ってみることを優先して、次回は「VM」「LXC」について解説します。