著者 Linux kernel 7.1の新機能とサーバーへの影響
Linux kernel 7.1は2026年6月14日にリリースされました。VPSで使える変更、実行中のkernelの確認方法、各ディストリビューションへの反映時期を解説します。
Linux kernel 7.1 の新機能
Linux kernel 7.1 は 2026 年 6 月 14 日にリリースされ、7.0 から 9 週間後のリリースとなりました。VPS（virtual private server）の利用者に関係する変更は、ストレージとファイルシステム、ネットワーク、メモリ管理、プロセスとコンテナの制御の4分野に集約されます。それ以外の変更の大半はデスクトップとグラフィックス関連であり、ヘッドレスサーバーでは読み込まれません。
まず、別の点を確認する必要があります。サーバーで 7.1 が動作している可能性はほぼなく、今後もしばらくは動作しないでしょう。kernel.org には 7.1 が longterm リリースとして掲載されていません。2026 年 8 月 11 日時点の longterm 系列は 6.18、6.12、6.6、6.1、5.15、5.10 です。主要なサーバー向けディストリビューションは、これらのいずれか、または各ディストリビューションが独自に保守する系列を基盤にしています。「kernel の新機能」と「サーバーで新しく利用できる機能」には数年の差があるため、このガイドでは両方を扱います。
現在 VPS で実行されている kernel
uname -r
uname -srm
systemd-detect-virtuname -r は実行中の kernel release を表示します。Ubuntu 24.04 では、6.8.0-79-generic のように表示されます。最初のダッシュより前の部分は upstream の系列です。それ以降はディストリビューション独自の build number であり、upstream の番号とはまったく連動しません。Canonical の 6.8.0-79 には、後の kernel から backport された修正が数千件含まれているため、2024 年 3 月に Linus が 6.8 としてタグ付けしたコードそのものではありません。そのため、「自分の kernel は古い」という説明だけでは、実際の状態を十分に表せません。機能は古い場合があります。しかし、security fix は通常、古くありません。
systemd-detect-virt は、kernel を変更できるかどうかを示します。完全な virtual machine では、独自の kernel image を起動し、upgrade が実際の upgrade になるため、kvm と表示されます。container virtualization では host kernel を共有するため、lxc または openvz と表示されます。container plan では、uname -r に provider の kernel が表示されます。kernel package をインストールしても、起動できるものは変わりません。また、provider が host を新しい kernel で再起動するまで、この release の機能は利用できません。kernel に関する作業を計画する前に、この確認を実行してください。
The data behind this chart
[
{
"distro": "Ubuntu 26.04 LTS (7.0)",
"releases_behind_7_1": 1,
"notes": "GA kernel, shipped with the April 2026 release"
},
{
"distro": "Ubuntu 24.04 LTS, HWE (6.17)",
"releases_behind_7_1": 4,
"notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
},
{
"distro": "Debian 13 trixie (6.12)",
"releases_behind_7_1": 9,
"notes": "upstream longterm line, kernel.org projected EOL December 2028"
},
{
"distro": "RHEL 10 and its rebuilds (6.12)",
"releases_behind_7_1": 9,
"notes": "Red Hat backports fixes into its own frozen 6.12 stream"
},
{
"distro": "Ubuntu 24.04 LTS, GA (6.8)",
"releases_behind_7_1": 13,
"notes": "the default unless you install the HWE stack"
},
{
"distro": "Ubuntu 22.04 LTS, GA (5.15)",
"releases_behind_7_1": 26,
"notes": "upstream longterm line, kernel.org projected EOL December 2026"
}
]これは 6 個の platform を対象とした結果であり、7.1 を起動する platform は 1 つもありません。最も新しいのは Ubuntu 26.04 LTS (7.0) で、upstream release では 1 個遅れています。現在もサポート対象で最も古いものは、26 release 遅れています。Ubuntu 24.04 のデフォルト GA kernel は 13 release 前の位置にあり、Debian 13 と RHEL 10 は 6.12 longterm 系列で 9 release 前です。release 数の比較は、ディストリビューションが backport した内容を無視するため、おおまかな指標にすぎません。しかし、差の全体像を示すことはできます。これらのどれを実行するか検討している場合は、server で LTS と interim release のどちらを選ぶかという比較が、この数値の背景にある判断です。
7.1 のストレージとファイルシステム
7.1 では、ブロック層だけでなくファイルシステム内でも T10 PI（protection information）を生成・検証できるようになり、T10 の柔軟なアライメントにも対応しました。T10 PI は各ブロックに付加される追加バイトです。チェックサムと、そのデータが属するブロックを識別するタグを保持するため、書き込み先を誤った書き込みや途中で中断された書き込みを、正常なデータとして返す前に検出できます。VPS テナントにとっての問題はハードウェアです。整合性メタデータはデバイスが公開する必要がありますが、仮想ディスクでは通常公開されません。
ls /sys/block/vda/integrity/ほとんどの VPS ディスクでは No such file or directory が返されます。デバイスが整合性サポートを登録した場合に限り、ブロック層が integrity ディレクトリを作成するためです。このエラーはここでは通常の結果であり、障害ではありません。ストレージ機能をさらに調べる前に、ディスクの実体を確認したい場合は、まず VPS のディスクが実際に NVMe かどうかを確認する必要があります。また、VPS における NVMe と SATA SSD の違いでは、その違いによって数値が変わる理由を説明しています。
Btrfs では、メモリー圧迫時の copy-on-write による増幅が修正されました。また、追跡対象の範囲にある最初の extent の消去を高速化する変更も入り、マージの説明ではサンプルワークロードでスループットが 10% 向上したと報告されています。シャットダウン処理は experimental として扱われなくなりました。XFS では、iomap を通じた zero range のフラッシュと検索が改善され、リアルタイムグループのジオメトリに write pointer が追加されました。これは zoned device に向けた基盤となる変更です。このリリースでは NTFS が全面的に書き直され、完全な書き込みサポートと iomap への変換が行われました。Windows マシンのディスクイメージをサーバーでマウントする場合に重要な変更です。
知っておくとよい小規模なストレージ関連の変更もあります。ユーザー空間のブロックドライバーである ublk では zero-copy I/O が追加されました。io_uring では SCSI passthrough コマンドが追加されました。SED-OPAL self-encrypting drive のサポートでは STACK_RESET コマンドと拡張 single user mode が追加されました。direct-access device 用の新しい fs-dax character driver も追加されています。また、VFS は inode->i_ino を unsigned long から u64 へ拡張しました。これにより、32-bit build における inode number の上限がなくなります。ネットワークファイルシステムでは、カーネル内 NFS サーバーが sign_fh mount option を通じて file handle に署名できるようになり、CIFS client には O_TMPFILE が追加されました。
ネットワーク: キューのリースとコンテナへの効果
ネットワーク関連で最も大きな変更は、ハードウェアキューのリースです。仮想 netdev が、物理 netdev 上の実キューにバインドされたキューをリースし、そのキューのプロキシとして動作できるようになりました。主な対象はコンテナです。これまでは、AF_XDP（address family express data path。ネットワークスタックを介してコピーせず、生パケットをユーザー空間に渡すソケットタイプ）を使用するコンテナに、デバイス全体に近いリソースを割り当てる必要がありました。キューをリースすれば、コンテナはハードウェアキューを1つ取得し、AF_XDP とメモリープロバイダーをネイティブ速度で実行できます。同時に、ホストは NIC の残りのキューを使えます。この機能は、io_uring のゼロコピー経路における AF_XDP サポートと同時に導入されます。
通常の用途では、sockfs のソケットが user.* 拡張属性を受け入れるようになりました。パスベースの AF_UNIX ソケットは、下位のファイルシステムから xattr サポートを継承していました。しかし、sockfs にのみ存在するソケットにはサポートがありませんでした。これで、プロセスはソケットにラベルを付けられます。eBPF プログラムは、そのラベルを基準にフィルタリングできます。
2 つの機能が削除されました。UDP-Lite は利用者が見つからなかったため削除されました。IPv6 はロード可能なモジュールとしてビルドできなくなりました。IPv6 を使用する場合は、カーネルに組み込む必要があります。後者は、どのディストリビューションのカーネルでも見える変更ではありません。主要なサーバーディストリビューションは、すでに IPv6 を組み込んでビルドしているためです。
メモリ管理: swap テーブルが完成しました
swap の再設計は第3段階に入り、この段階で静的な swap マップがなくなります。swap の数は、swap テーブルに直接保持されるようになりました。削減量は静的な swap メタデータの約30%です。これは、swap が実際に使用されているかどうかに関係なく、swap デバイスのサイズに応じてカーネルが保持していたメモリです。絶対量は小さな swap ファイルでは少なく、設定する swap の容量に応じて増加します。
MGLRU（multi-generational least recently used、新しいページ回収アルゴリズム）は、ページの young フラグを1ページずつではなく、バッチ単位で確認できるようになりました。この変更で公表された数値は、Arm64 32コアサーバーで60%を超える改善です。ページ単位のコストが高い環境ほど、バッチ処理の効果が大きくなります。そのため、この数値は大規模な Arm マシンで得られたものです。x86 ではなく Arm の VPS を使用している場合、これは7.1で自身の測定結果に最も現れやすい変更です。ただし、2コアまたは4コアの環境では、この規模の改善にはなりません。
ここでは、終了中の memory cgroup からの転送もなくなり、khugepaged のスキャンで使用する CPU も減り、maple tree では大きなノードの処理を中心に大規模なリファクタリングが行われました。いずれも設定する項目ではありません。システム時間がわずかに減ったこととして確認できます。
スケジューラ: sched_ext のサブスケジューラと FRED のデフォルト有効化
sched_ext は、BPF プログラムとして CPU スケジューラを記述し、実行時に読み込める拡張可能なスケジューラ方式です。6.12 で導入されました。7.1 では、サブスケジューラ向けの中核構造が追加されます。これにより、将来的には control group ごとに独自のスケジューラを使用できるようになります。この点は慎重に読んでください。7.1 では実装が完成しておらず、特に enqueue 処理が不足しています。そのため、現時点で有効化できる機能ではなく、後のリリースに向けた基盤です。
Intel FRED（flexible return and event delivery）は、対応ハードウェア上でデフォルトで有効になります。FRED は従来の x86 event delivery 経路を、より整理された方式に置き換えます。6.9 以降の kernel に含まれており、これまでは fred=on boot argument によって有効化できました。デフォルトで有効に変更されたことは、出荷済みハードウェアで十分な検証が行われたことを示します。これまでに公開された測定値は、I/O 負荷の高いワークロードで 4% から 7% の範囲です。ただし、これはクライアント向け silicon を Phoronix がテストした結果です。実際のワークロードを測定するまでは、サーバーで同程度の効果を見込まないでください。
Proxy execution では、リモートの lock owner を boost するための donor migration が追加されました。EEVDF では、negative lag に関する修正が行われました。また、high-resolution timer の中核部分が大幅に書き直されました。これらはレイテンシ品質に関する変更であり、設定ファイルから制御する項目はありません。
clone3() の新しいプロセスおよびコンテナ制御
clone3() に 3 つのフラグが追加されました。いずれも、監視プロセスが長年手作業で回避してきた制約を解消します。CLONE_AUTOREAP を指定すると、子プロセスは終了時に自分自身を回収するため、親プロセスが wait() を呼び出さないままゾンビプロセスとして残りません。CLONE_NNP は、子プロセスの作成時に no_new_privs を設定します。これにより、clone の実行後に子プロセス自身がフラグを設定するまでの間隙がなくなります。CLONE_PIDFD_AUTOKILL は、子プロセスの存続期間を親プロセスに返される pidfd に結び付けます。pidfd を閉じると子プロセスが強制終了されるため、監視プロセスが停止しても孤児プロセスが実行され続けることはありません。
マウント名前空間にも同様の機能が追加されました。CLONE_EMPTY_MNTNS を clone3() に、UNSHARE_EMPTY_MNTNS を unshare() に指定すると、何も含まないマウント名前空間を作成できます。通常は親プロセスのマウントをすべてコピーしてから、ランタイムが不要なマウントをアンマウントする必要があります。FSMOUNT_NAMESPACE を使うと、fsmount() によりファイルシステムを新しい名前空間へ直接配置できます。コンテナランタイムはこの処理を 10 年にわたって手作業で組み立ててきました。この処理を 1 回の呼び出しで実行できるため、ランタイムはホストのマウントで埋まった名前空間から開始する必要がなくなります。
仮想化では、guest_memfd が userfaultfd をサポートするようになりました。これにより、ハイパーバイザーはユーザー空間からゲストのページフォールトを処理できます。Arm の Protected KVM には匿名メモリのサポートが追加されましたが、マージ自体では本番環境での使用準備が整っていないと説明されています。
カーネル 7.1 はいつサーバーに届くのか
Fedora にはすでに導入されています。Fedora 44 の更新リポジトリは、2026 年 7 月から 8 月にかけて 7.1 系列へ移行しました。Fedora は 1 つのリリースの中で、カーネルを新しい安定系列へリベースするためです。Arch と openSUSE Tumbleweed にも同じ理由で導入されています。これらはテスト用のマシンであり、サービスを稼働させるマシンではありません。
それ以外は待つことになります。これは意図された動作です。Debian 13 は 6.12 でリリースされ、リリースのサポート期間中は 6.12 を維持し、修正をバックポートします。RHEL 10 は 6.12.0 でリリースされ、同じ方式を採用しています。Ubuntu 26.04 LTS は 2026 年 4 月に 7.0 でリリースされました。Ubuntu 24.04 LTS には hardware enablement stack があり、後続の Ubuntu リリースに含まれる新しいカーネルを LTS へ取り込みます。この stack は 24.04.4 point release の時点で 6.17 です。2026 年 8 月 27 日に予定されている 24.04.5 では、7.0 へ移行します。
ここで誤解されやすい点があります。HWE stack は、最新の interim release が採用しているカーネルへ移行するため、上流の系列を完全に飛ばすことがあります。Ubuntu LTS には 7.0 が含まれます。一方、7.1 は LTS のベースにならない可能性があります。その後の interim release が、さらに新しい系列を採用するためです。7.1 から LTS に取り込まれるのは修正であり、現在使用している系列へバックポートされます。機能の大部分は取り込まれません。
安定版サーバーで新しいカーネルを使用したい場合、サポートされる方法は限られています。
# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot
# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot再起動後、実際に起動したカーネルを確認します。
uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-requireduname -r には新しい系列が表示され、dpkg -l にはインストール済みのすべてのカーネルイメージが表示されます。uname -r に古いバージョンが表示され、dpkg -l に新しいバージョンが表示される場合、パッケージはインストールされていますが、bootloader のデフォルトは変更されていません。GRUB のメニュー項目を確認してください。/var/run/reboot-required が存在する場合、パッケージによってカーネルは更新されたものの、その後に再起動されていません。パッチ適用済みのサーバーが脆弱なコードを実行し続ける理由として、これが最も一般的です。
本番 VPS で 7.1 を追うべきか
いいえ。その理由は、慎重さのために慎重になる必要がないからではありません。ディストリビューションのカーネルは、サポート契約の一部です。Canonical、Red Hat、SUSE、Debian はそれぞれ、固定されたリリース系列にセキュリティ修正をバックポートし、そのカーネルとともに提供するユーザー空間でテストしています。サードパーティーのアーカイブにある mainline カーネルや自分でビルドしたカーネルを使うと、機能を得る代わりにこの作業を自分で担うことになります。誰もあなたのビルドへ修正をバックポートしないためです。あなた自身がカーネルの保守担当になります。
例外はありますが、範囲は限られます。古いカーネルでは動かせないハードウェアを使う場合、または自分のワークロードで測定した性能改善を、結果に対する責任を負ってでも必要とする場合です。VPS では、前者に該当することはほとんどありません。見えているハードウェアは仮想化されているためです。それ以外では、ディストリビューションのカーネルを最新に保ち、再起動を求められたら再起動してください。すでにディストリビューションのアップグレードを予定しているなら、Ubuntu 24.04 から 26.04 への移行によって 6.8 から 7.0 へ一度に更新できます。これは、単一のカーネルパッケージで得られる更新幅より大きな変更です。
FAQ
VPS で実行されている Linux カーネルを確認するにはどうすればよいですか？
uname -r を実行します。6.8.0-79-generic のような結果が表示されます。最初のハイフンより前の番号は、ディストリビューションが基盤としている上流の系列です。その後ろはディストリビューション独自のビルド番号で、バックポートされた修正が含まれます。続いて systemd-detect-virt を実行します。lxc または openvz と表示された場合は、コンテナ仮想化環境です。ホストのカーネルを共有しているため、変更できません。kvm と表示された場合は、独自のカーネルイメージで起動しているため、アップグレードは自分で実施します。
Linux 7.1 は長期サポートカーネルですか？
いいえ。2026 年 8 月 11 日時点で kernel.org に掲載されている longterm 系列は 6.18、6.12、6.6、6.1、5.15、5.10 で、7.1 は含まれていません。通常の stable リリースであり、次の mainline リリースが公開されると、その stable 系列はまもなく終了します。何年にもわたる修正が蓄積され、今後も何年も修正が提供されるカーネルが必要なら、ディストリビューションのカーネルがすでにそれに該当します。
Ubuntu または Debian はいつカーネル 7.1 をリリースしますか？
デフォルトになる可能性はほぼありません。Debian 13 はリリース期間を通じて 6.12 を使用し、RHEL 10 は 6.12.0 を使用します。Ubuntu 26.04 LTS は 7.0 を搭載してリリースされました。Ubuntu の hardware enablement stack は、最新の interim リリースが搭載するカーネルへ移行するため、上流の系列を丸ごと飛ばすことがあります。Ubuntu 24.04 LTS は、2026 年 8 月 27 日の 24.04.5 point release で HWE カーネルを 7.0 に移行する予定です。7.1 の修正は、古い系列へのバックポートとして提供されます。通常、機能は提供されません。
Linux 7.1 で仮想プライベートサーバーに実際に関係する変更は何ですか？
4 項目です。Hardware queue leasing により、コンテナは実 NIC のキュー 1 つを AF_XDP でネイティブ速度のまま使用できます。swap rework の第 3 段階では、静的な swap map が廃止され、swap デバイス用にカーネルが保持するメタデータが公表値で 30% 削減されます。MGLRU は page young flag をバッチ処理で確認でき、多数のコアを持つ Arm サーバーで最大の公表性能向上が得られています。また clone3() には CLONE_AUTOREAP、CLONE_NNP、CLONE_PIDFD_AUTOKILL が追加され、子プロセスの監視がより安全になりました。ファイルシステムレベルの T10 protection information も追加されましたが、仮想ディスクで必要な整合性メタデータが公開されることはほとんどありません。
カーネルをアップグレードすると VPS が壊れますか？
よくある問題は起動時に発生します。完全な /boot により、インストール中に update-initramfs が No space left on device で失敗し、パッケージが半構成状態になります。sudo apt autoremove --purge で古いカーネルを削除してから、再インストールします。古いカーネル向けにビルドされた out-of-tree モジュールは読み込めなくなるため、DKMS で管理されるものは再ビルドが必要です。再ビルドに失敗しても、実行時にモジュールが見つからなくなるまで気付けないことがあります。また、再起動後も uname -r が古いバージョンを示し、dpkg -l に新しいイメージが表示される場合、インストール自体は壊れていません。ブートローダーのデフォルトが変更されていないだけです。