Proxmox Virtual Environment 9.0 released!

Hi,
Code:
./find-old-packages2.sh
Can we remove those old packages from bookworm?
There is also an official way to do this ;) https://www.debian.org/releases/trixie/release-notes/upgrading.en.html#obsolete
But please make sure you have all repositories correctly configured and updated before running apt list '~o'! This will list all locally installed packages that are not available in any configured repository. There are cases where you actually want to keep a local package, but you probably know about the ones you explicitly built/installed/want to keep. Others can be removed.

pbs3to4:
WARN: proxmox-boot-tool is used for bootloader configuration in uefi mode but the separate systemd-boot package, is not installed.
initializing new ESPs will not work until the package is installed.

Its a pve+pbs server, the messages are a bit confusing..., i installed systemd-boot-efi + systemd-boot-tools "manually" and removed systemd-boot
the pbs message is probably forgotten to be updated?
Thanks for the report! This was already reported in the PBS release thread. The PBS checker script will be updated to align this error (the relevant change unfortunately didn't make it in time for the PBS release).
 
Last edited:
Are there any logs for pvestatd in the journal of the PVE 8 hosts?

Checked logs for pvestatd on all proxmox 8 nodes, found some old mistakes but nothing particular to proxmox 9 node.

Found this in global systemlog of proxmox 8 node:

Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-node-9.0/proxmox-4
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-vm-9.0/259
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-vm-9.0/202
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-vm-9.0/211
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-storage-9.0/proxmox-4/PBS-NEW
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-storage-9.0/proxmox-4/ISO
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-storage-9.0/proxmox-4/Proxmox4-Raid10-Ext4
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-storage-9.0/proxmox-4/local


proxmox-1 is version 8, proxmox-4 is version 9
 
Last edited:
Checked logs for pvestatd on all proxmox 8 nodes, found some old mistakes but nothing particular to proxmox 9 node.

Found this in global systemlog of proxmox 8 node:

Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-node-9.0/proxmox-4
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-vm-9.0/259
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-vm-9.0/202
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-vm-9.0/211
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-storage-9.0/proxmox-4/PBS-NEW
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-storage-9.0/proxmox-4/ISO
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-storage-9.0/proxmox-4/Proxmox4-Raid10-Ext4
Aug 11 14:23:28 proxmox-1 pmxcfs[2048981]: [status] crit: RRD update error: unknown/wrong key pve-storage-9.0/proxmox-4/local


proxmox-1 is version 8, proxmox-4 is version 9
that means you haven't upgraded all the nodes to the last v ersion of 8.x before starting with the upgrade of the first node to 9.x
 
Great job Proxmox team. Upgraded my test host without issues!
One thing to report though, love the new mobile-friendly UI, it loads and work just fine in Chrome, but when using Firefox it loads the classic UI.
(Pixel 9 Pro XL, Android 16, Firefox 141.0.1)
Same issue here with the new mobile UI, It's loading fine on Chrome but old UI on Firefox.
Did you find any fix for it? Or just wait for an update to fix it?
For reference: https://bugzilla.proxmox.com/show_bug.cgi?id=6657
 
Hi,
That said.. I can't help think there is potentially something else amiss, the timing just seems too coincidental
  1. The backup errors only started occurring after upgrading PVE 8 to 9 (PBS backups run nightly, so.. ever since the upgrade)
  2. Those errors occur immediately on attempted backup, against 4 different templates but all in the same way (The device is not writable: Permission denied) while mounting the storage, rather than at some abritrary block during a read op
please open a new thread pinging me with @fiona and providing the output of the following commands:
Code:
cat /etc/pve/qemu-server/135.conf
apt install debsums && debsums -c qemu-server
pveversion -v

Does running systemctl reload-or-restart pvescheduler.service pvedaemon.service pveproxy.service pvestatd.service help?
 
  • Like
Reactions: TimRex
Hi,
When it formatted the disks, it keeps complaining about finding an existing rpool. (Even though I already cleaned the disks and removed all partitions.)
ZFS labels are often not easy to get rid of. Did you use zpool labelclear?
 
that means you haven't upgraded all the nodes to the last v ersion of 8.x before starting with the upgrade of the first node to 9.x

Upgraded another proxmox-8 node to latest 8.4.2. Logged to it and status of all nodes, both 8 and 9 versions is green.
The solution is clear.
Many thanks and best regards!
 
  • Like
Reactions: fabian
I was reviewing my RAM uses and the ballooning was not working with 4096MB 50% share so i turned it off. it had pci passthrough but no longer. It shows full ram uses in Windows 11 pro, actual uses is half or even lower around 3GB. PVE is on nvme ext4 default.

1754921917852.png

1754921880737.png
 
No, I removed the partitions and reinitialized the disks. but that may have not been enough?
That alone does not get rid of file system signatures, those are not part of the partition table, but are in the partition's data. There also is the wipefs tool that can help to get rid of left-overs.
 
  • Like
Reactions: Daniel-Doggy
I've upgraded our production cluster to pve9 and most things are good but there are clearly some problems with virtio networking. Two things stand out (and there may be more).

First, our cluster has compute, storage and hybrid nodes. The storage nodes are all R740XD and the compute nodes are a mix of R740 and R750 and the hybrid node is a R750. The hybrid node is essentially the same as the other R750s in the stack, with a newer bios, and guests with virtio network drivers cannot be successfully migrated to our from this host. When migrating to the host the following error is observed (this is from any other node in the stack)

Code:
Aug 10 18:17:02 hybr-01-prod QEMU[1473513]: kvm: Features 0x130afffaf unsupported. Allowed features: 0x1c0010179bfffe7
Aug 10 18:17:02 hybr-01-prod QEMU[1473513]: kvm: Failed to load virtio-net:virtio
Aug 10 18:17:02 hybr-01-prod QEMU[1473513]: kvm: error while loading state for instance 0x0 of device '0000:00:12.0/virtio-net'
Aug 10 18:17:02 hybr-01-prod QEMU[1473513]: kvm: Putting registers after init: Failed to set XCRs: Invalid argument

When migrating from the node to any other node in the stack, the receiving node generates the following error.

Code:
Aug 10 18:51:00 comp-06-prod QEMU[1578269]: kvm: get_pci_config_device: Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0
Aug 10 18:51:00 comp-06-prod QEMU[1578269]: kvm: Failed to load PCIDevice:config
Aug 10 18:51:00 comp-06-prod QEMU[1578269]: kvm: Failed to load virtio-net:virtio
Aug 10 18:51:00 comp-06-prod QEMU[1578269]: kvm: error while loading state for instance 0x0 of device '0000:00:12.0/virtio-net'
Aug 10 18:51:00 comp-06-prod QEMU[1578269]: kvm: load of migration failed: Invalid argument

guests without the virtio network driver migrate fine to and from.

The second issue took me almost 24 hours to identify because it is so odd. We have a load balancer that talks to three vms that live on a different network segment. The vms all seem to work fine and are on the network without issue. From certain network segments an ssl session can be established but then when the vm starts sending data, it disappears / never makes it to the requester. This does not happen across all network segments. We moved the vms to the same network as the load balancer and it then worked. We initially thought it was a firewall issue and spent a lot of time on that but as a test I changed the interface to e1000 on one of the vms and everything worked on its old network segment. There is clearly some weird problem here.

It seems there is some issue with virtio network in the latest qemu. We are running the following across all hosts:

Code:
QEMU emulator version 10.0.2 (pve-qemu-kvm_10.0.2-4)
Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers
 
hello proxmox team!
Just wanted to say a big thank you! :)
Last weekend I updated first pbs in a VM on my NAS without any troubles.
Today I updated my pve from 8 to 9. Just a simple home lab setup, so nothing fancy, but my first update after only a short time using pve. So, was I nervous? Betcha!

So: thank you for your great work, great documentation and great product. With that and a little help from https://forum.heimnetz.de/ I got it done without headaches.
These days it is almost "normal" (sad but true) for major updates to cause major trouble (even in a home lab). So: thumbs up for this work of yours! :)
 
Last edited:
I upgraded to 9.0.4 two hosts based on different hardware. So far, so good with exception of UI Summary page graphs: average and maximum graphs for respective period don't change when being toggled...
Am I missing some settings to tick off
 
Hi,

There is also an official way to do this ;) https://www.debian.org/releases/trixie/release-notes/upgrading.en.html#obsolete
But please make sure you have all repositories correctly configured and updated before running apt list '~o'! This will list all locally installed packages that are not available in any configured repository. There are cases where you actually want to keep a local package, but you probably know about the ones you explicitly built/installed/want to keep. Others can be removed.


Thanks for the report! This was already reported in the PBS release thread. The PBS checker script will be updated to align this error (the relevant change unfortunately didn't make it in time for the PBS release).
lol, thank you, so easy :-)
 
Hello, we have upgraded 6 PVE 8 servers via apt successfully and without any glitch or problem. But number 7 gives us headaches. This one is the only server with ZFS as boot / root file system, the others have LVM / ext4 setups. We upgraded to the latest 8.4 version and booted into that successfully. Then we did all the steps outlined in the docs and finally an apt dist-upgrade. This ended with :

run-parts: executing /etc/kernel/postinst.d/initramfs-tools 6.14.8-2-pve /boot/vmlinuz-6.14.8-2-pve
update-initramfs: Generating /boot/initrd.img-6.14.8-2-pve

Running hook script 'zz-proxmox-boot'..
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..
Copying and configuring kernels on /dev/disk/by-uuid/B336-C9A1
Copying kernel 6.14.8-2-pve
Copying kernel 6.8.12-13-pve
/usr/sbin/grub-probe: error: failed to get canonical path of `/dev/disk/by-id/scsi-35002538840116350-part3'.
run-parts: /etc/initramfs/post-update.d//proxmox-boot-sync exited with return code 1
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1

which means we now have a fully upgraded 9.0 system running on kernel 6.8.12 as shown by the 8to9 script:

Checking proxmox-ve package version..
PASS: already upgraded to Proxmox VE 9

Checking running kernel version..
WARN: unexpected running and installed kernel '6.8.12-13-pve'.

I do not even dare to reboot in this state. The installation is pretty normal, the ZFS status of the "rpool" is fine and I cannot see why it could build a new boot config when upgrading to the latest 8.4 but not when doing 9.0 30 minutes later. Does anybody have a hint how to get out of this short of reinstalling?
I also tried to create the links to the disks manually (/dev/disk/by-id/scsi-35002538840116350-part3 and one other disk) but then grub-probe complains about "# grub-probe /
grub-probe: error: unknown filesystem."

Glad for any hints, JC

could you open a new thread and tag me there? please also include the output of "lsblk", thanks!
 
I've upgraded our production cluster to pve9 and most things are good but there are clearly some problems with virtio networking. Two things stand out (and there may be more).

First, our cluster has compute, storage and hybrid nodes. The storage nodes are all R740XD and the compute nodes are a mix of R740 and R750 and the hybrid node is a R750. The hybrid node is essentially the same as the other R750s in the stack, with a newer bios, and guests with virtio network drivers cannot be successfully migrated to our from this host. When migrating to the host the following error is observed (this is from any other node in the stack)

Code:
Aug 10 18:17:02 hybr-01-prod QEMU[1473513]: kvm: Features 0x130afffaf unsupported. Allowed features: 0x1c0010179bfffe7
Aug 10 18:17:02 hybr-01-prod QEMU[1473513]: kvm: Failed to load virtio-net:virtio
Aug 10 18:17:02 hybr-01-prod QEMU[1473513]: kvm: error while loading state for instance 0x0 of device '0000:00:12.0/virtio-net'
Aug 10 18:17:02 hybr-01-prod QEMU[1473513]: kvm: Putting registers after init: Failed to set XCRs: Invalid argument

When migrating from the node to any other node in the stack, the receiving node generates the following error.

Code:
Aug 10 18:51:00 comp-06-prod QEMU[1578269]: kvm: get_pci_config_device: Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0
Aug 10 18:51:00 comp-06-prod QEMU[1578269]: kvm: Failed to load PCIDevice:config
Aug 10 18:51:00 comp-06-prod QEMU[1578269]: kvm: Failed to load virtio-net:virtio
Aug 10 18:51:00 comp-06-prod QEMU[1578269]: kvm: error while loading state for instance 0x0 of device '0000:00:12.0/virtio-net'
Aug 10 18:51:00 comp-06-prod QEMU[1578269]: kvm: load of migration failed: Invalid argument

guests without the virtio network driver migrate fine to and from.

The second issue took me almost 24 hours to identify because it is so odd. We have a load balancer that talks to three vms that live on a different network segment. The vms all seem to work fine and are on the network without issue. From certain network segments an ssl session can be established but then when the vm starts sending data, it disappears / never makes it to the requester. This does not happen across all network segments. We moved the vms to the same network as the load balancer and it then worked. We initially thought it was a firewall issue and spent a lot of time on that but as a test I changed the interface to e1000 on one of the vms and everything worked on its old network segment. There is clearly some weird problem here.

It seems there is some issue with virtio network in the latest qemu. We are running the following across all hosts:

Code:
QEMU emulator version 10.0.2 (pve-qemu-kvm_10.0.2-4)
Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers

could you please open a new thread, tag @fiona and include (in addition to the info above):

the VM config of such a failing migration
the full migration task log
the VM start task log on the target node
the system log for both nodes covering the time period of the migration (journalctl --since ... --until ...)

thanks!
 
  • Like
Reactions: fiona