Install, Pin, and Configure Proxmox VE Kernels
Install an opt-in Proxmox kernel, pin or unpin a kernel version, and change the kernel command line on GRUB or systemd-boot hosts.
On this page
Proxmox VE ships its own kernel packages, which include ZFS and are tested with the rest of the platform. When you need newer hardware support, you can install one of the newer opt-in kernels, pin the host to a known-good version, and adjust kernel parameters. Run the commands as root on the node.
Note
Older notes installed Debian backports kernels (linux-image-amd64 with zfs-dkms) on Proxmox. Don't do that on current releases. Proxmox's opt-in kernels give you the same newer hardware support with ZFS built in and without DKMS rebuilds.
Check the Running Kernel and Installed Kernels
uname -r
proxmox-boot-tool kernel listInstall an Opt-in Kernel
Proxmox publishes newer kernels as opt-in packages, announced on the Proxmox forum. For example, proxmox-kernel-7.0 on Proxmox VE 9 or proxmox-kernel-6.14 on Proxmox VE 8:
apt update
apt install proxmox-kernel-<VERSION>
rebootOnce installed, later builds of that kernel series arrive with normal updates. Opt-in kernels are less tested than the default series, so try them on one node first.
Pin a Kernel Version
By default, the node boots the newest installed kernel. To boot a specific version instead, for example to stay on a kernel that works with a particular NIC or GPU driver, pin it. Use the exact version string from proxmox-boot-tool kernel list:
proxmox-boot-tool kernel pin <KERNEL_VERSION>To try a kernel for a single boot only, so a failed boot falls back on the next reboot:
proxmox-boot-tool kernel pin <KERNEL_VERSION> --next-bootRemove the pin to go back to booting the newest kernel:
proxmox-boot-tool kernel unpinPinning works with both GRUB and systemd-boot.
Change the Kernel Command Line
Where kernel parameters go depends on the bootloader. Find out which one the host uses:
proxmox-boot-tool status
efibootmgr -vefibootmgr shows systemd-bootx64.efi for systemd-boot, and grubx64.efi or shimx64.efi for GRUB. On a legacy BIOS host, it reports that EFI variables aren't supported, which means GRUB. In practice, ZFS-on-root installs booting in UEFI mode without Secure Boot use systemd-boot, and everything else uses GRUB.
systemd-boot
Edit /etc/kernel/cmdline. It's a single line, so append parameters to the end:
root=ZFS=rpool/ROOT/pve-1 boot=zfs intel_iommu=on iommu=ptThen copy the change to every boot partition:
proxmox-boot-tool refreshGRUB
Edit GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"Then regenerate the GRUB config:
update-grubAfter rebooting, confirm the parameters took effect with cat /proc/cmdline.
Warning
Kernel and command-line changes can leave a node unbootable. Keep console or IPMI access available, migrate or shut down guests first, and on a cluster change one node at a time.
Disabling CPU Vulnerability Mitigations
Some performance guides suggest adding mitigations=off to the kernel command line. It turns off the kernel's protections against Spectre, Meltdown, and related CPU flaws, which can win back a few percent of CPU performance on older processors.
Warning
On a hypervisor, mitigations=off lets code in one VM potentially read memory from the host or from other VMs. Never use it on hosts that run untrusted guests, customer workloads, or anything exposed to the internet. Measure the actual gain before considering it on an isolated lab host.
Sources
This article is in the public domain (CC0 1.0), code samples included. Use it however helps you.