Proxmox Virtual Environment 9.0 released!

[fiona]

Hi,

Any chance on adding

pve-network-interface-pinning

to PVE 8? In a vacuum I think I'd prefer to set that in a controlled/known environment rather than upgrade, lose connectivity, fix it (presumably), and then change interface names again (from new to newer).

AFAIK, it's unlikely to be backported. However, you can still pin the names in Proxmox VE 8, just not with the tool:
https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#network_pin_naming_scheme_version

EDIT: actually, it was already backported and is available with pve-manager >= 8.4.9 currently available in the no-subscription repository.

 

[Zerstoiber]

Hi,

AFAIK, it's unlikely to be backported. However, you can still pin the names in Proxmox VE 8, just not with the tool:
https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#network_pin_naming_scheme_version

Hi Fiona, the roadmap mentions the tool and to run it "prior to upgrading", which makes me think it should be available in PVE8
https://pve.proxmox.com/mediawiki/index.php?title=Roadmap&type=revision&diff=12322&oldid=12281
-> I guess the Roadmap should not mention it, right?

 

[dramis]

@tithitoy @down16
This is not a problem, but due to the BSDs not reporting back any details regarding their internal memory usage. Therefore, we can only fall back to the host memory view, which has now changed a bit as we account for the overall overhead better.
In the past, the used memory shown in the Summary panel also never matched what you would see reported by pfsense/OPNsense.

You can compare the reported memory usage infos if you go the "Monitor" panel of a VM and type in info balloon. Compare the output from a FreeBSD based VM (e.g. OPNsense/pfsense) to one that runs Linux or Windows (with the Ballooning Agent running).

I'm seeing the same behavior with one of the virtual machines running Debian 12 and 13, so it's not limited to FreeBSD.

 

[gasherbrum]

I am also seeing the memory 100% behavior on win11, ubuntu 24.04 endpoints

 

[Jedis]

Hi,
for all the people who had issues with their LVM thin pools and needed to repair them ( @Jedis @Kevo @Damon1974 @thomascgh ): Could you provide the /var/log/apt/term.log from during the update (please check if it was already rotated, then the relevant logs might be in term.log.1.gz etc. instead) as well as the system journal from the time right before the upgrade and until the pool was repaired, e.g. the command could be journalctl --since "2025-08-05 17:00:00" --until "2025-08-07 11:00:00" > /tmp/journal.txt with adapted time stamps.

Here they are. Send me a PM for the password to the 7-Zip zip file.

 

[SInisterPisces]

Yes

Yes - because you're still on PVE-8 (bookworm) - I thought that the following part should explain that:

With Debian Trixie the systemd-boot package got split up a bit further into systemd-boot-efi (containing the EFI-binary used for booting), systemd-boot-tools (containing bootctl) and the systemd-boot meta-package (containing hooks which run upon upgrades of itself and other packages and install systemd-boot as bootloader).

@Stoiko Ivanov ,

Yes. That part was clear. I understood the problem--I just wasn't quite clear on how to deal with it.

which is also why the pve8to9 script does not warn you before upgrading to pve-9 (trixie):

I will warn you after upgrading to 9 (at that point the system will have `systemd-boot-tools`, `systemd-boot-efi` (both of which we need) and `systemd-boot` (which you want to get rid of installed)


Thanks for the feedback - much appreciated (the clearer our guides are the smoother the upgrades for our community will be) - any suggestions how to improve that part? - Thanks!

This is the part that confused me a bit.

Looking at the wiki:

As Proxmox Systems usually handle the installation of systemd-boot-efi as bootloader using proxmox-boot-tool the meta-package systemd-boot should be removed. The package was automatically shipped for systems installed from the PVE 8.1 to PVE 8.4 ISOs, as it contained bootctl in bookworm.

It was not clear to me just from reading this when the user should remove the package. This is my first in place upgrade (I always clean installed before.)

It also wasn't initially clear to me that during the upgrade process, the pve8to9 script will run again and tell you how to fix the bootloader and any other issues, which you'll then need to do manually before you reboot. I would suggest adding something to that effect to the Bootloader section of the wiki page, with an intra-page link to the warning to continously run the pve8to9 tool.

That's my fault. I wasn't ready to do the upgrade yet, so I didn't read the entire page, and missed the part about running the tool continuously. I just saw the discussion of the boot issue here in the thread and went a bit sideways. I'm sure I'm not the only person with the bad habit of jumping down directly to their potential issue in a long wiki page. A reminder on various parts of the page where not doing it might break your system's ability to boot to go back and read the warning about running the tool continuously would be really helpful.

If the pve8to9 checklist script suggests it, the systemd-boot meta-package is safe to remove unless you manually installed it and are using systemd-boot as a bootloader. Should systemd-boot-efi and systemd-boot-tools be required, pve8to9 will warn you accordingly.

See also bug for systemd-boot

 

[empirical6355]

Yes, that is what I meant. Thanks for the feedback! We'll need to investigate kernel changes in this area, as it very much sounds like a kernel issue from the feedback we got until now. A workaround should be booting an older kernel in the meantime.

Thank you @fiona for the help!

I can confirm that booting with an older kernel immediately fixed the issue. I ran proxmox-boot-tool kernel pin 6.8.12-13-pve
as per https://pve.proxmox.com/wiki/Host_Bootloader#sysboot_proxmox_boot_tool and then rebooted and my VM came right up with PCI passthrough working fine.

edit: and just for posterity, the kernel I was using that had issues was 6.14.8-2-pve

 

[floh8]

Why the official docu doesn't show the new pve feature like qemu+lvm, HA affinities etc. ?

 

[t.lamprecht]

Why the official docu doesn't show the new pve feature like qemu+lvm, HA affinities etc. ?

It should, did you force-reload the documentation site to ensure you don't just still see the previous repo? HA affinities have a dedicated section, and snapshot as volume chains on LVM has also docs, e.g. on our public mirrored docs these topics are visible here:

https://pve.proxmox.com/pve-docs/chapter-ha-manager.html#ha_manager_rules
https://pve.proxmox.com/pve-docs/chapter-pvesm.html#storage_lvm

 

[Stoiko Ivanov]

It also wasn't initially clear to me that during the upgrade process, the pve8to9 script will run again and tell you how to fix the bootloader and any other issues, which you'll then need to do manually before you reboot. I would suggest adding something to that effect to the Bootloader section of the wiki page, with an intra-page link to the warning to continously run the pve8to9 tool.

That's my fault. I wasn't ready to do the upgrade yet, so I didn't read the entire page, and missed the part about running the tool continuously. I just saw the discussion of the boot issue here in the thread and went a bit sideways. I'm sure I'm not the only person with the bad habit of jumping down directly to their potential issue in a long wiki page. A reminder on various parts of the page where not doing it might break your system's ability to boot to go back and read the warning about running the tool continuously would be really helpful.

Thanks that does sound quite sensible indeed! - I tried adapting the docs accordingly:
https://pve.proxmox.com/wiki/Upgrad...ation_automatically_and_should_be_uninstalled

 

[Starrbuck]

Two in-place updates went great. Thank you, Proxmox team, for all the hard work!

 

[SInisterPisces]

Thanks that does sound quite sensible indeed! - I tried adapting the docs accordingly:
https://pve.proxmox.com/wiki/Upgrad...ation_automatically_and_should_be_uninstalled

Thanks! That's a very helpful change.

 

[scyto]

I upgraded my first node, i think it di it correctly.

Now when it boots, it hangs here (grub menu is accessible)




I can get in to recovery mode via grub, i ran journalctl -xb and the last items relate to frr and thunderbolt, where i have custom configuration

I don't really know where to go next with this one - for example can i disable services in the recovery mode (like frr) and my udevs rules and try rebooting?

--edit--
this is realted to the thunderbolt config from my gists, this had no issues on 7.x or 8.x

@alistah on git hub figure out the fix

nano /etc/systemd/system/network-online.target.wants/networking.service

then Add under [Service] "TimeoutStartSec=30s"

and save

this gets past the permanent hang, network.service still errors as not started

 

[afftub]

high memory usage after pve9 upgrade





example 2

I've observed an increase in memory usage across all of my VMs since upgrading to Proxmox VE 9.0.

- pve-manager/9.0.3/025864202ebb6109 (running kernel: 6.14.8-2-pve)

 

[Impact]

Check arc_summary -s arc and top -o%MEM.

 

[fabian]

I upgraded my first node, i think it di it correctly.

Now when it boots, it hangs here (grub menu is accessible)

View attachment 89083


I can get in to recovery mode via grub, i ran journalctl -xb and the last items relate to frr and thunderbolt, where i have custom configuration

I don't really know where to go next with this one - for example can i disable services in the recovery mode (like frr) and my udevs rules and try rebooting?

--edit--
this is realted to the thunderbolt config from my gists, this had no issues on 7.x or 8.x

@alistah on git hub figure out the fix

nano /etc/systemd/system/network-online.target.wants/networking.service

then Add under [Service] "TimeoutStartSec=30s"

and save

this gets past the permanent hang, network.service still errors as not started

that usually doesn't mean that it hangs at that point, but that you don't get any of the rest of the output. you could try booting with "quiet" removed from the kernel cmdline (you can edit it for one boot in the Grub menu by hitting 'e'), that should display more messages. likely something delays or blocks the boot, like your suspicion that it's related to networking.. could you then open a new thread with the full journal output for a failed/hanging/slow boot?

 

[aaron]

I'm seeing the same behavior with one of the virtual machines running Debian 12 and 13, so it's not limited to FreeBSD.

Do you have the "ballooning device" enabled in the advanced memory options? if not, then there is no way to get the detailed guest view infos and you are in the same boat as with the *BSDs

high memory usage after pve9 upgrade

See the above or https://forum.proxmox.com/threads/proxmox-virtual-environment-9-0-released.169258/page-7#post-789415 and https://forum.proxmox.com/threads/proxmox-virtual-environment-9-0-released.169258/page-5#post-788983

In general: if the Memory usage is the same as Host memory usage, then for one reason or another, we don't get detailed guest view mem usage infos and fall back to the host view, which is now accounted for more accurately and can be over 100% as it included overhead on the host as well.

Reasons for not getting detailed guest mem usage infos: the guest doesn't report back anything, or the communication channel (Ballooning device) is not enabled.

 

[aaron]

Does anyone have an answer regarding my situation ? Thank you very much !

Did you run apt update after changing all the sources? Because then it should usually find a few hundred packages to update. It might need to run again. But yeah, in that case it should be fine. In the upgrade guide we don't call pve8to9 anymore, after changing the sources

 

[fiona]

Hi Fiona, the roadmap mentions the tool and to run it "prior to upgrading", which makes me think it should be available in PVE8
https://pve.proxmox.com/mediawiki/index.php?title=Roadmap&type=revision&diff=12322&oldid=12281
-> I guess the Roadmap should not mention it, right?

Sorry, I was wrong. Actually, it was already backported and is available with pve-manager >= 8.4.9 currently available in the no-subscription repository.

 

[fiona]

Hi,

Yes, I ran “apt update” afterwards, and this is what I got (in the console) : "579 packages can be upgraded. Run 'apt list --upgradable' to see them".

However, I didn't run “apt upgrade” unless you confirm that it's preferable before launching the update (PVE 9 with Debian 13) via "dist-upgrade"

running apt upgrade when you already switched the repositories to new Debian codenames is a no-go! And actually, you should always use apt dist-upgrade or apt full-upgrade on a Proxmox installation: https://lore.proxmox.com/pve-devel/20240909102050.40220-1-f.ebner@proxmox.com/