Proxmox Virtual Environment 9.0 released!

wickeren · Aug 19, 2025

Have upgraded my 3-node cluster just fine, at least it looks like, all VM's and CT's are running.
But I get lots of errors like this now for various actions:

Code:

/etc/ssh/ssh_config line 55: Bad key types '+ssh-rsa,ssh-dss'.
/etc/ssh/ssh_config: terminating, 1 bad configuration options

This is happening when opening a shell on another node then logged in, opening a VM console on another node then logged in, trying to migrate machines between nodes etc.
The etc/ssh/ssh_config on the nodes don't even have a line 55, they have only 53. Did I miss something here? Have choosen to keep using the installed etc/ssh/ssh_config. Any idea how to resolve this?

Johannes S · Aug 19, 2025

SInisterPisces said:
I don't believe that the PVE/PBS dev teams put those sorts of warnings in the actual product GUIs.

They do. For example btrfs is still in this state allthough it was introduced years ago.
I would never trust the Internet if the official docs say something different.

SInisterPisces · Aug 19, 2025

Johannes S said:
They do. For example btrfs is still in this state allthough it was introduced years ago.
I would never trust the Internet if the official docs say sonething different.

Ah. I've apparently never tried an experimental feature, then.

Defintely trust the docs. Proxmox documentation is some of the best out there.

matteo.fracassetti · Aug 20, 2025

SInisterPisces said:
I think it was announced as a "technology preview" in the initial press release.

I don't believe that the PVE/PBS dev teams put those sorts of warnings in the actual product GUIs.

Ok, I but i need to know if this feature is still a technology preview or if is enough mature to be considered "production ready" also in very large deployment with tens or hundreds nodes.

Stoiko Ivanov · Aug 20, 2025

wickeren said:
Have upgraded my 3-node cluster just fine, at least it looks like, all VM's and CT's are running.
But I get lots of errors like this now for various actions:
/etc/ssh/ssh_config line 55: Bad key types '+ssh-rsa,ssh-dss'. /etc/ssh/ssh_config: terminating, 1 bad configuration options
This is happening when opening a shell on another node then logged in, opening a VM console on another node then logged in, trying to migrate machines between nodes etc.
The etc/ssh/ssh_config on the nodes don't even have a line 55, they have only 53. Did I miss something here? Have choosen to keep using the installed etc/ssh/ssh_config. Any idea how to resolve this?

hmm - check if there are some files in `/etc/ssh/ssh_config.d/` - or even a bit more general run - `grep -rE 'ssh-dss' /etc/` - check this on all nodes in your cluster!

if that does not point to the issue - please open a new thread (feel free to mention me with @Stoiko Ivanov) - and share the output of `ssh -vv root@<other-node-in-your-cluster` ( after checking the output for sensitive data)

shahar · Aug 20, 2025

mikeyo said:
This release and the beta has an issue with the graphical installer UI not displaying when using IPMI ASPEED 2600 remote video. Just a grey screen and moving cursor. I have to revert to the terminal to install.

View attachment 88889

Have a similar issue with a SuperMicro via IPMI
But haven't checked the VGA output of the board yet - need to go there in person for this...

ZXBombJack · Aug 20, 2025

Hi, we have a cluster in the lab with three hosts (nested ESXi VMs) and Ceph 19.2.3. We didn't encounter any problems with version 8.4, but after upgrading to Proxmox 9, existing VMs configured with SeaBIOS won't boot and show an internal error in the GUI. In the console, I see what is shown in the attached image.
Even a new VM with SeaBIOS has the same problem, with UEFI on existing and new VMs, I don't detect any problems.
The situation is identical on all three hosts, and the VMs behave in the same way.

Code:

Aug 20 15:34:27 proxmox3 pvedaemon[7125]: start VM 104: UPID:Proxmox3:00001BD5:0000F0C3:68A5CEE3:qmstart:104:root@pam:

Aug 20 15:34:27 proxmox3 pvedaemon[1957]: <root@pam> starting task UPID:Proxmox3:00001BD5:0000F0C3:68A5CEE3:qmstart:104:root@pam:

Aug 20 15:34:27 proxmox3 systemd[1]: Started 104.scope.

Aug 20 15:34:29 proxmox3 kernel: tap104i0: entered promiscuous mode

Aug 20 15:34:29 proxmox3 kernel: vmbr1: port 2(fwpr104p0) entered blocking state

Aug 20 15:34:29 proxmox3 kernel: vmbr1: port 2(fwpr104p0) entered disabled state

Aug 20 15:34:29 proxmox3 kernel: fwpr104p0: entered allmulticast mode

Aug 20 15:34:29 proxmox3 kernel: fwpr104p0: entered promiscuous mode

Aug 20 15:34:29 proxmox3 kernel: vmbr1: port 2(fwpr104p0) entered blocking state

Aug 20 15:34:29 proxmox3 kernel: vmbr1: port 2(fwpr104p0) entered forwarding state

Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 1(fwln104i0) entered blocking state

Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 1(fwln104i0) entered disabled state

Aug 20 15:34:29 proxmox3 kernel: fwln104i0: entered allmulticast mode

Aug 20 15:34:29 proxmox3 kernel: fwln104i0: entered promiscuous mode

Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 1(fwln104i0) entered blocking state

Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 1(fwln104i0) entered forwarding state

Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 2(tap104i0) entered blocking state

Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 2(tap104i0) entered disabled state

Aug 20 15:34:29 proxmox3 kernel: tap104i0: entered allmulticast mode

Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 2(tap104i0) entered blocking state

Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 2(tap104i0) entered forwarding state

Aug 20 15:34:29 proxmox3 pvedaemon[7125]: VM 104 started with PID 7135.

Aug 20 15:34:29 proxmox3 pmxcfs[1447]: [status] notice: received log

Aug 20 15:34:29 proxmox3 pvedaemon[1957]: <root@pam> end task UPID:Proxmox3:00001BD5:0000F0C3:68A5CEE3:qmstart:104:root@pam: OK

Aug 20 15:34:32 proxmox3 QEMU[7135]: KVM: entry failed, hardware error 0x7

Aug 20 15:34:32 proxmox3 kernel: kvm_intel: set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state.

Aug 20 15:34:32 proxmox3 QEMU[7135]: EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000

Aug 20 15:34:32 proxmox3 QEMU[7135]: ESI=00000000 EDI=00000000 EBP=00000000 ESP=00006edc

Aug 20 15:34:32 proxmox3 QEMU[7135]: EIP=0000fa6b EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0

Aug 20 15:34:32 proxmox3 QEMU[7135]: ES =0000 00000000 ffffffff 00809300

Aug 20 15:34:32 proxmox3 QEMU[7135]: CS =f000 000f0000 ffffffff 00809b00

Aug 20 15:34:32 proxmox3 QEMU[7135]: SS =0000 00000000 ffffffff 00809300

Aug 20 15:34:32 proxmox3 QEMU[7135]: DS =0000 00000000 ffffffff 00809300

Aug 20 15:34:32 proxmox3 QEMU[7135]: FS =0000 00000000 ffffffff 00809300

Aug 20 15:34:32 proxmox3 QEMU[7135]: GS =0000 00000000 ffffffff 00809300

Aug 20 15:34:32 proxmox3 QEMU[7135]: LDT=0000 00000000 0000ffff 00008200

Aug 20 15:34:32 proxmox3 QEMU[7135]: TR =0000 00000000 0000ffff 00008b00

Aug 20 15:34:32 proxmox3 QEMU[7135]: GDT=     00000000 00000000

Aug 20 15:34:32 proxmox3 QEMU[7135]: IDT=     00000000 000003ff

Aug 20 15:34:32 proxmox3 QEMU[7135]: CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000

Aug 20 15:34:32 proxmox3 QEMU[7135]: DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000

Aug 20 15:34:32 proxmox3 QEMU[7135]: DR6=00000000ffff0ff0 DR7=0000000000000400

Aug 20 15:34:32 proxmox3 QEMU[7135]: EFER=0000000000000000

Aug 20 15:34:32 proxmox3 QEMU[7135]: Code=00 00 00 66 89 f8 66 83 c4 1c 66 5b 66 5e 66 5f 66 5d 66 c3 <cd> 19 cb 00 00 00 00 00 00 00 00 7e 81 a5 81 bd 99 81 7e 7e ff db ff c3 e7 ff 7e 6c fe fe

Aug 20 15:34:38 proxmox3 pmxcfs[1447]: [dcdb] notice: data verification successful

Aug 20 15:34:38 proxmox3 sshd-session[7292]: Accepted password for root from 192.168.1.158 port 64700 ssh2

Aug 20 15:34:38 proxmox3 sshd-session[7292]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0)

Aug 20 15:34:38 proxmox3 systemd-logind[980]: New session 18 of user root.

Aug 20 15:34:38 proxmox3 systemd[1]: Started session-18.scope - Session 18 of User root.

Aug 20 15:34:38 proxmox3 sshd-session[7300]: Received disconnect from 192.168.1.158 port 64700:11: Connection terminated by the client.

Aug 20 15:34:38 proxmox3 sshd-session[7300]: Disconnected from user root 192.168.1.158 port 64700

Aug 20 15:34:38 proxmox3 sshd-session[7292]: pam_unix(sshd:session): session closed for user root

Aug 20 15:34:38 proxmox3 systemd[1]: session-18.scope: Deactivated successfully.

Aug 20 15:34:38 proxmox3 systemd-logind[980]: Session 18 logged out. Waiting for processes to exit.

Aug 20 15:34:38 proxmox3 systemd-logind[980]: Removed session 18.

pveversion -v
proxmox-ve: 9.0.0 (running kernel: 6.14.8-2-pve)
pve-manager: 9.0.5 (running version: 9.0.5/9c5600b249dbfd2f)
proxmox-kernel-helper: 9.0.3
proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2
proxmox-kernel-6.14: 6.14.8-2
proxmox-kernel-6.8.12-13-pve-signed: 6.8.12-13
proxmox-kernel-6.8: 6.8.12-13
proxmox-kernel-6.8.12-11-pve-signed: 6.8.12-11
proxmox-kernel-6.8.12-9-pve-signed: 6.8.12-9
ceph: 19.2.3-pve1
ceph-fuse: 19.2.3-pve1
corosync: 3.1.9-pve2
criu: 4.1.1-1
frr-pythontools: 10.3.1-1+pve4
ifupdown2: 3.3.0-1+pmx9
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.0
libproxmox-backup-qemu0: 2.0.1
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.0.3
libpve-apiclient-perl: 3.4.0
libpve-cluster-api-perl: 9.0.6
libpve-cluster-perl: 9.0.6
libpve-common-perl: 9.0.9
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.4
libpve-network-perl: 1.1.6
libpve-rs-perl: 0.10.10
libpve-storage-perl: 9.0.13
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 6.0.4-2
lxcfs: 6.0.4-pve1
novnc-pve: 1.6.0-3
proxmox-backup-client: 4.0.14-1
proxmox-backup-file-restore: 4.0.14-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.1.1
proxmox-kernel-helper: 9.0.3
proxmox-mail-forward: 1.0.2
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.0
proxmox-widget-toolkit: 5.0.5
pve-cluster: 9.0.6
pve-container: 6.0.9
pve-docs: 9.0.8
pve-edk2-firmware: 4.2025.02-4
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.3
pve-firmware: 3.16-3
pve-ha-manager: 5.0.4
pve-i18n: 3.5.2
pve-qemu-kvm: 10.0.2-4
pve-xtermjs: 5.5.0-2
qemu-server: 9.0.18
smartmontools: 7.4-pve1
spiceterm: 3.4.0
swtpm: 0.8.0+pve2
vncterm: 1.9.0
zfsutils-linux: 2.3.3-pve1

matteo.fracassetti · Aug 20, 2025

ZXBombJack said:
Hi, we have a cluster in the lab with three hosts (nested ESXi VMs) and Ceph 19.2.3. We didn't encounter any problems with version 8.4, but after upgrading to Proxmox 9, existing VMs configured with SeaBIOS won't boot and show an internal error in the GUI. In the console, I see what is shown in the attached image.
Even a new VM with SeaBIOS has the same problem, with UEFI on existing and new VMs, I don't detect any problems.
The situation is identical on all three hosts, and the VMs behave in the same way.

View attachment 89665

Code:

Aug 20 15:34:27 proxmox3 pvedaemon[7125]: start VM 104: UPID:Proxmox3:00001BD5:0000F0C3:68A5CEE3:qmstart:104:root@pam: Aug 20 15:34:27 proxmox3 pvedaemon[1957]: <root@pam> starting task UPID:Proxmox3:00001BD5:0000F0C3:68A5CEE3:qmstart:104:root@pam: Aug 20 15:34:27 proxmox3 systemd[1]: Started 104.scope. Aug 20 15:34:29 proxmox3 kernel: tap104i0: entered promiscuous mode Aug 20 15:34:29 proxmox3 kernel: vmbr1: port 2(fwpr104p0) entered blocking state Aug 20 15:34:29 proxmox3 kernel: vmbr1: port 2(fwpr104p0) entered disabled state Aug 20 15:34:29 proxmox3 kernel: fwpr104p0: entered allmulticast mode Aug 20 15:34:29 proxmox3 kernel: fwpr104p0: entered promiscuous mode Aug 20 15:34:29 proxmox3 kernel: vmbr1: port 2(fwpr104p0) entered blocking state Aug 20 15:34:29 proxmox3 kernel: vmbr1: port 2(fwpr104p0) entered forwarding state Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 1(fwln104i0) entered blocking state Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 1(fwln104i0) entered disabled state Aug 20 15:34:29 proxmox3 kernel: fwln104i0: entered allmulticast mode Aug 20 15:34:29 proxmox3 kernel: fwln104i0: entered promiscuous mode Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 1(fwln104i0) entered blocking state Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 1(fwln104i0) entered forwarding state Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 2(tap104i0) entered blocking state Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 2(tap104i0) entered disabled state Aug 20 15:34:29 proxmox3 kernel: tap104i0: entered allmulticast mode Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 2(tap104i0) entered blocking state Aug 20 15:34:29 proxmox3 kernel: fwbr104i0: port 2(tap104i0) entered forwarding state Aug 20 15:34:29 proxmox3 pvedaemon[7125]: VM 104 started with PID 7135. Aug 20 15:34:29 proxmox3 pmxcfs[1447]: [status] notice: received log Aug 20 15:34:29 proxmox3 pvedaemon[1957]: <root@pam> end task UPID:Proxmox3:00001BD5:0000F0C3:68A5CEE3:qmstart:104:root@pam: OK Aug 20 15:34:32 proxmox3 QEMU[7135]: KVM: entry failed, hardware error 0x7 Aug 20 15:34:32 proxmox3 kernel: kvm_intel: set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state. Aug 20 15:34:32 proxmox3 QEMU[7135]: EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 Aug 20 15:34:32 proxmox3 QEMU[7135]: ESI=00000000 EDI=00000000 EBP=00000000 ESP=00006edc Aug 20 15:34:32 proxmox3 QEMU[7135]: EIP=0000fa6b EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 Aug 20 15:34:32 proxmox3 QEMU[7135]: ES =0000 00000000 ffffffff 00809300 Aug 20 15:34:32 proxmox3 QEMU[7135]: CS =f000 000f0000 ffffffff 00809b00 Aug 20 15:34:32 proxmox3 QEMU[7135]: SS =0000 00000000 ffffffff 00809300 Aug 20 15:34:32 proxmox3 QEMU[7135]: DS =0000 00000000 ffffffff 00809300 Aug 20 15:34:32 proxmox3 QEMU[7135]: FS =0000 00000000 ffffffff 00809300 Aug 20 15:34:32 proxmox3 QEMU[7135]: GS =0000 00000000 ffffffff 00809300 Aug 20 15:34:32 proxmox3 QEMU[7135]: LDT=0000 00000000 0000ffff 00008200 Aug 20 15:34:32 proxmox3 QEMU[7135]: TR =0000 00000000 0000ffff 00008b00 Aug 20 15:34:32 proxmox3 QEMU[7135]: GDT= 00000000 00000000 Aug 20 15:34:32 proxmox3 QEMU[7135]: IDT= 00000000 000003ff Aug 20 15:34:32 proxmox3 QEMU[7135]: CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 Aug 20 15:34:32 proxmox3 QEMU[7135]: DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 Aug 20 15:34:32 proxmox3 QEMU[7135]: DR6=00000000ffff0ff0 DR7=0000000000000400 Aug 20 15:34:32 proxmox3 QEMU[7135]: EFER=0000000000000000 Aug 20 15:34:32 proxmox3 QEMU[7135]: Code=00 00 00 66 89 f8 66 83 c4 1c 66 5b 66 5e 66 5f 66 5d 66 c3 <cd> 19 cb 00 00 00 00 00 00 00 00 7e 81 a5 81 bd 99 81 7e 7e ff db ff c3 e7 ff 7e 6c fe fe Aug 20 15:34:38 proxmox3 pmxcfs[1447]: [dcdb] notice: data verification successful Aug 20 15:34:38 proxmox3 sshd-session[7292]: Accepted password for root from 192.168.1.158 port 64700 ssh2 Aug 20 15:34:38 proxmox3 sshd-session[7292]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0) Aug 20 15:34:38 proxmox3 systemd-logind[980]: New session 18 of user root. Aug 20 15:34:38 proxmox3 systemd[1]: Started session-18.scope - Session 18 of User root. Aug 20 15:34:38 proxmox3 sshd-session[7300]: Received disconnect from 192.168.1.158 port 64700:11: Connection terminated by the client. Aug 20 15:34:38 proxmox3 sshd-session[7300]: Disconnected from user root 192.168.1.158 port 64700 Aug 20 15:34:38 proxmox3 sshd-session[7292]: pam_unix(sshd:session): session closed for user root Aug 20 15:34:38 proxmox3 systemd[1]: session-18.scope: Deactivated successfully. Aug 20 15:34:38 proxmox3 systemd-logind[980]: Session 18 logged out. Waiting for processes to exit. Aug 20 15:34:38 proxmox3 systemd-logind[980]: Removed session 18.

pveversion -v
proxmox-ve: 9.0.0 (running kernel: 6.14.8-2-pve)
pve-manager: 9.0.5 (running version: 9.0.5/9c5600b249dbfd2f)
proxmox-kernel-helper: 9.0.3
proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2
proxmox-kernel-6.14: 6.14.8-2
proxmox-kernel-6.8.12-13-pve-signed: 6.8.12-13
proxmox-kernel-6.8: 6.8.12-13
proxmox-kernel-6.8.12-11-pve-signed: 6.8.12-11
proxmox-kernel-6.8.12-9-pve-signed: 6.8.12-9
ceph: 19.2.3-pve1
ceph-fuse: 19.2.3-pve1
corosync: 3.1.9-pve2
criu: 4.1.1-1
frr-pythontools: 10.3.1-1+pve4
ifupdown2: 3.3.0-1+pmx9
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.0
libproxmox-backup-qemu0: 2.0.1
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.0.3
libpve-apiclient-perl: 3.4.0
libpve-cluster-api-perl: 9.0.6
libpve-cluster-perl: 9.0.6
libpve-common-perl: 9.0.9
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.4
libpve-network-perl: 1.1.6
libpve-rs-perl: 0.10.10
libpve-storage-perl: 9.0.13
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 6.0.4-2
lxcfs: 6.0.4-pve1
novnc-pve: 1.6.0-3
proxmox-backup-client: 4.0.14-1
proxmox-backup-file-restore: 4.0.14-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.1.1
proxmox-kernel-helper: 9.0.3
proxmox-mail-forward: 1.0.2
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.0
proxmox-widget-toolkit: 5.0.5
pve-cluster: 9.0.6
pve-container: 6.0.9
pve-docs: 9.0.8
pve-edk2-firmware: 4.2025.02-4
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.3
pve-firmware: 3.16-3
pve-ha-manager: 5.0.4
pve-i18n: 3.5.2
pve-qemu-kvm: 10.0.2-4
pve-xtermjs: 5.5.0-2
qemu-server: 9.0.18
smartmontools: 7.4-pve1
spiceterm: 3.4.0
swtpm: 0.8.0+pve2
vncterm: 1.9.0
zfsutils-linux: 2.3.3-pve1

Nested virtualization support Is still enabled after upgrade?
Are you using "host" CPU type or an emulated one?

HCL used in VMware?

ZXBombJack · Aug 20, 2025

matteo.fracassetti said:
Nested virtualization support Is still enabled after upgrade?
Are you using "host" CPU type or an emulated one?

HCL used in VMware?

Yes
Tried both, but it doesn't change anything.
VMware Hardware Compatibility List (HCL) ? I don't understand what you mean.

matteo.fracassetti · Aug 20, 2025

ZXBombJack said:
Yes
Tried both, but it doesn't change anything.
VMware Hardware Compatibility List (HCL) ? I don't understand what you mean.

I'm sorry, I mean the virtual hardware compatibility level of the virtual machine. I don't remember the exact name used in VMware for this.

ZXBombJack · Aug 20, 2025

Virtual HW Version: ESXi 7.0 U2 and later (VM version 19)

ZXBombJack · Aug 20, 2025

I found the source of the problem:
I booted one of the three hosts with the previous kernel “Linux 6.8.12-13-pve” and my VMs with SeaBIOS start up normally. If I go back to using the kernel “Linux 6.14.8-2-pve,” the problem comes back!

It seems 6.14.8-2 Introduces stricter validation of VMCS (Virtual Machine Control Structure) in KVM.
Rejects incomplete or invalid CPU states more aggressively.
Combined with QEMU 10, it enforces more accurate emulation, which breaks compatibility with certain legacy boot sequences (like INT 19h used by SeaBIOS).
In nested virtualization (Proxmox inside ESXi), these stricter checks fail due to limited CPU feature exposure, causing the VM to crash before boot.

SInisterPisces · Aug 20, 2025

matteo.fracassetti said:
Ok, I but i need to know if this feature is still a technology preview or if is enough mature to be considered "production ready" also in very large deployment with tens or hundreds nodes.

I'd open a bug report on the Proxmox Bugzilla and ask for clarification on the status of this feature in the docs. It's not clear to me from reading them whether it's still TP or not.

matteo.fracassetti · Aug 20, 2025

SInisterPisces said:
I'd open a bug report on the Proxmox Bugzilla and ask for clarification on the status of this feature in the docs. It's not clear to me from reading them whether it's still TP or not.

Thanks you!!
I'll do.

Edit:
Done.
https://bugzilla.proxmox.com/show_bug.cgi?id=6707

asahiguy · Aug 20, 2025

Just a note from me, I upgraded a cluster today, fairly recently built (end of July) from 8.1.2 to v9
and the instructions listed here https://pve.proxmox.com/wiki/Upgrade_from_8_to_9 had a slight problem/my situation was different
i was on autopilot so I was just copy pasting the wiki (yeah i know).. and upon reboot PVE wasn't working, there was no GUI and there were no VMs launched so I investigate why.

Basically boils down to this section

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

but for me, on my system, it had to be

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources

I have logged this as a documentation "bug".

https://bugzilla.proxmox.com/show_bug.cgi?id=6708

janus57 · Aug 20, 2025

Hi,

asahiguy said:
but for me, on my system, it had to be

Does you install come from an OVH template ?

Best regards,

miguelwill · Aug 22, 2025

Greetings and thanks for the update. It was very stable and painless.

I wanted to ask a question about HA group migration. In my case, we have a multi-node cluster, and at this point, all of them have already been updated. I've checked each one with the "pve8to9" script, and it tells me everything is OK. However, when I try to edit or add affinity rules, it gives me an error indicating that the HA groups have not yet been migrated:

Is there a way to update the groups manually?
Or would I have to delete them and create them from scratch?

I also wanted to confirm that nothing goes wrong when deleting an HA group at this point.

Regards

update:
I found the following logs that appear to be related to some old nodes not being completely removed:

Aug 22 16:30:09 r640-84 pve-ha-crm[4183]: start ha group migration...
Aug 22 16:30:09 r640-84 pve-ha-crm[4183]: ha groups migration: node 'r630-79' is in state 'maintenance'
Aug 22 16:30:09 r640-84 pve-ha-crm[4183]: abort ha groups migration: node 'r630-79' is not online
Aug 22 16:30:09 r640-84 pve-ha-crm[4183]: ha groups migration failed
Aug 22 16:30:09 r640-84 pve-ha-crm[4183]: retry ha groups migration in 6 rounds (~ 60 seconds)

update2:
Well, after reviewing the errors in detail, I was able to find a solution: stopping all "pve-ha-crm" services on the nodes, deleting the "/etc/pve/ha/manager_status" file, and restarting the service on all nodes.
After this, in Datacenter Status -> HA, the list of nodes appears clean, without any old or deleted nodes.

D

[SOLVED] Thread 'lrm (unable to read lrm status)'

Feb 15, 2020

I had a server die this past week and I removed it from the infrastructure. I can confirm that the server is out of commission and is pulled from the rack. I removed the node and all is well, or so I thought. The cluster is giving me an issue with regards to it seeming not being able to find the node.

I had 5 nodes, now down to 4.
All 4 nodes (vdc2-vdc5) are showing as proper.

When I run a pvecm status, I get the following:

Cluster information
-------------------
Name: vdc-cluster
Config Version: 6
Transport: knet
Secure auth: on
Quorum information...

miguelwill · Aug 23, 2025

I was testing the affinity rules, and they worked correctly.
I only noticed that in the "node affinity rules" rules, if a rule is disabled, then when trying to "reactivate" it, it doesn't update the status. I was only able to reactivate it by editing the "/etc/pve/ha/rules.cfg" file and removing the "disabled" line from that rule.

gmpalter · Aug 24, 2025

Stoiko Ivanov said:
hmm - check if there are some files in `/etc/ssh/ssh_config.d/` - or even a bit more general run - `grep -rE 'ssh-dss' /etc/` - check this on all nodes in your cluster!

if that does not point to the issue - please open a new thread (feel free to mention me with @Stoiko Ivanov) - and share the output of `ssh -vv root@<other-node-in-your-cluster` ( after checking the output for sensitive data)

Trixie dropped support for DSA keys. From the Trixie release notes ...

Digital Signature Algorithm (DSA) keys, as specified in the Secure Shell (SSH) protocol, are inherently weak: they are limited to 160-bit private keys and the SHA-1 digest. The SSH implementation provided by the openssh-client and openssh-server packages has disabled support for DSA keys by default since OpenSSH 7.0p1 in 2015, released with Debian 9 (“stretch”), although it could still be enabled using the HostKeyAlgorithms and PubkeyAcceptedAlgorithms configuration options for host and user keys respectively.

The only remaining uses of DSA at this point should be connecting to some very old devices. For all other purposes, the other key types supported by OpenSSH (RSA, ECDSA, and Ed25519) are superior.

As of OpenSSH 9.8p1 in trixie, DSA keys are no longer supported even with the above configuration options. If you have a device that you can only connect to using DSA, then you can use the <span>ssh1</span> command provided by the openssh-client-ssh1 package to do so.

I ran into this issue when upgrading a Debian 12 VM to Debian 13. That system needs to connect to a very old Alpha system. (Rather than try the workaround, I reverted back to Debian 12 for the moment.)

SInisterPisces · Aug 24, 2025

gmpalter said:
Trixie dropped support for DSA keys. From the Trixie release notes ...

I ran into this issue when upgrading a Debian 12 VM to Debian 13. That system needs to connect to a very old Alpha system. (Rather than try the workaround, I reverted back to Debian 12 for the moment.)

I was not expecting to run into someone mentioning an in-production DEC Alpha today.
Awesome.

Proxmox Virtual Environment 9.0 released!

Renowned Member

Famous Member

Well-Known Member

New Member

Proxmox Staff Member

New Member

New Member

Attachments

New Member

New Member

New Member

New Member

New Member

Well-Known Member

New Member

New Member

Renowned Member

Renowned Member

[SOLVED] Thread 'lrm (unable to read lrm status)'

Renowned Member

New Member

Well-Known Member

We value your privacy