Proxmox Virtual Environment 9.2 available!

I'm really new user with limited knowledge on linux, nonetheless I was able to install version 9.1, iirc, without issues.
Now with (I don't have the 9.1 anymore) the installer hangs on

modprobe: FATAL: Module shpchp not found in directory /lib/modules/7.0.2-6-pve
 
Code:
tree /home/
/home/
└── tom
    └── sources
        └── infra
            └── pve-cd-builder
                ├── debian-base
                │   └── extra-repos
                │       ├── debian-trixie
                │       │   └── 2026-04-23T13:15:09Z
                │       ├── debian-trixie-security
                │       │   └── 2026-04-23T13:33:31Z
                │       └── debian-trixie-updates
                │           └── 2026-04-23T13:33:18Z
                └── tmp
                    └── proxmoxrepo
Hello guys!
I've just downloaded the PVE and PBS ISO from the Proxmox site. After installation I noticed an unusual folder. I don's see this folder on my current instances.
 
  • Like
Reactions: Johannes S and Fra
Hi,
many thanks for the new release.
Since PVE 9.0, snapshots on LVM (e.g. on an iSCSI LUN) are supported. This is great because we have migrated from VMware which was connected to a huge iSCSI storage system. Unfortunately, the snapshot feature is still in "technical preview" state. I had hoped to get this released in 9.2, but this is not the case.

Is there any roadmap when this will be officially supported without limitation?

Thanks
Andreas
 
Code:
tree /home/
/home/
└── tom
    └── sources
        └── infra
            └── pve-cd-builder
                ├── debian-base
                │   └── extra-repos
                │       ├── debian-trixie
                │       │   └── 2026-04-23T13:15:09Z
                │       ├── debian-trixie-security
                │       │   └── 2026-04-23T13:33:31Z
                │       └── debian-trixie-updates
                │           └── 2026-04-23T13:33:18Z
                └── tmp
                    └── proxmoxrepo
Hello guys!
I've just downloaded the PVE and PBS ISO from the Proxmox site. After installation I noticed an unusual folder. I don's see this folder on my current instances.
these are benign leftover empty directories from the ISO building process - you can remove all of /home/tom, the next iso builds will not have them anymore!
 
  • Like
Reactions: Johannes S and Fra
Hi,
many thanks for the new release.
Since PVE 9.0, snapshots on LVM (e.g. on an iSCSI LUN) are supported. This is great because we have migrated from VMware which was connected to a huge iSCSI storage system. Unfortunately, the snapshot feature is still in "technical preview" state. I had hoped to get this released in 9.2, but this is not the case.

Is there any roadmap when this will be officially supported without limitation?

Thanks
Andreas
Look into Starlvm or OCFS2 file system. Both free and both allow VM snapshots on shared ISCSI. Just make sure you keep TPM on local-lvm and back up any needed secrets for VM level TPM use in case a host dies and a new TPM needs to be generated. (do not put TPM disks on iscsi storage)
 
Hi @bmorrisj ,

thanks for your response. Do you have an experience with StarLVM or OCFS2 on iSCSI for 8 nodes and approx 300 VMs on a 80TB iSCSI volume (hosted by a Synology)? Is this something which could run stable and with good performance?

I am a bit reluctant to use a solution which is not recommended by Proxmox and was therefore looking for their new volume chain solution. But because it is an important productive solution I am afraid to use a "technology preview" feature.

Therefore, once again the question whether there is any roadmap when this will be released.

Thanks again
Andreas
 
Upgrade to 9.2.3 from 9.1 went without issue across all my nodes. Didn't need to do any resource remapping, plug-n-play all the way.

Nice to see Proxmox upgrades becoming so streamlined even when migrating kernels, well done Proxmox Team.
 
Ok, so I notice something strange after the 9.2.3 upgrade from 9.1.

One of the LXCs is logging this warning every few minutes:

Code:
eth0: Failed to set IPv6 MTU to 9198: Invalid argument

The process causing this error is: systemd-networkd

The LXC is running kernel "Ubuntu 26.04 LTS (GNU/Linux 7.0.6-2-pve x86_64)"

I have no idea why it is doing this, was not happening before, but I did upgrade the LXC too just after the PVE host upgrade.

I have no scripts in this container which do anything link relative so it seems this maybe has something to do with background Proxmox network scripting or something related?

Any ideas?

This guest does use RDMA for mounting some samba shares, and everything appears to be working with no problems.

But this warning log entry is a little annoying, why is the MTU change being attempted?
The LXC container network interface is specifically set to 9000, that is the bridge MTU, also had it set to 1 to take the bridge MTU, changed it to 9000 to see if it made a difference, but to no avail.
 
Last edited:
Hi @Domino,
is there anything else before or after that log line? What does your container configuration look like, i.e. pct config ID with the numerical ID? What do you see when you run networkctl cat eth0.network in the container? What do you see with ip a in the container and on the host (there, the output for the bridge and bridge ports would be interesting)?
 
Hi @Domino,
is there anything else before or after that log line? What does your container configuration look like, i.e. pct config ID with the numerical ID? What do you see when you run networkctl cat eth0.network in the container? What do you see with ip a in the container and on the host (there, the output for the bridge and bridge ports would be interesting)?

Hi Fiona,

Code:
 /etc/systemd/network/eth0.network
[Match]
Name = eth0

[Network]
Description = Interface eth0 autoconfigured by PVE
Address = xxx.xxx.xxx.xxx/16
Gateway = xxx.xxx.xxx.xxx
DHCP = no
IPv6AcceptRA = false

Code:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 30000

2: eth0@if100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 30000
    link/ether <mac> brd <mac> link-netnsid 0
    inet xxx.xxx.xxx.xxx/16 brd xxx.xxx.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

3: eth1@if101: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 30000

Code:
# pct config 103
arch: amd64
cores: 4
features: nesting=1
hostname: xxxxxx
memory: 2048
nameserver: xxx.xxx.xxx.xxx
net0: name=eth0,bridge=dlan,gw=x.x.x.x,hwaddr=<mac>,ip=x.x.x.x/16,mtu=9000,type=veth
net1: name=eth1,bridge=lan,hwaddr=<mac>,ip=x.x.x.x/8,ip6=<public-ipv6>/64,type=veth
onboot: 0
ostype: ubuntu
parent: Ubuntu-23
rootfs: local-lvm:vm-103-disk-1,mountoptions=noatime,replicate=0,size=128G
searchdomain: local
swap: 8192

Unfortunately there are no other log entries around this warning, the log entry is from process ID 104, which is the systemd-networkd service itself.

There is also docker running inside this container, but no docker networking as the docker containers are set to use host networking so no additional virtual network interfaces/bridges.

It is a strange one, everything is working fine, just no idea what is triggering those warning log entries.


I can't see any logical pattern in the timing of the warning log entries:

Code:
2026-06-05 13:10:35.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument
2026-06-05 13:03:35.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument
2026-06-05 12:54:46.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument
2026-06-05 12:50:41.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument
2026-06-05 12:47:18.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument
2026-06-05 12:38:46.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument
2026-06-05 12:34:54.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument
2026-06-05 12:30:50.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument
2026-06-05 12:23:16.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument
2026-06-05 12:19:09.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument
2026-06-05 12:11:18.000 eth0: Failed to set IPv6 MTU to 9198: Invalid argument


Update:

If I leave docker disabled, no warning log entries!!!!
So it seems something in Docker has changed, investigating further.

Conclusion:

So, it seems that something privilege related has indeed changed, but where? I have no idea, it wasn't an issue in 24.04 ubuntu LXC running under PVE 9.1, but I upgraded both the PVE host and the LXC rather quickly so is the issue caused by a new docker change or the underlying LXC to version 26.04 change or PVE 9.2 upgrade , or a combination of it all, I guess I won't know unless I go back to backups and do the upgrades one stage at a time.

I have now stopped the warnings at least.

The solution was:
I first added an mtu entry into the docker network file, which already had the bridge disabled and never needed an mtu entry before the upgrade, but this change did stop the warnings after restarting the docker service and containers.

[/etc/docker/daemon.json]

PVE 9.1
Code:
{
    "bridge": "none"
}

update to for PVE 9.2
Code:
{
    "bridge": "none",
    "mtu": 9000
}


Then I noticed new warnings appearing on docker container startup:

Code:
eth0: Failed to read IPv6 MTU: No such file or directory

Ok so this sounds like a privilege issue, although this error appears only the once on container startup.

So I gave the docker container network-admin privileges by adding to the docker compose file:

Code:
cap_add:
  - NET_ADMIN

No warnings now, all operating as it was prior to PVE 9.2 upgrade.

Going forward I really need to do one thing at a time rather than go ahead and upgrade everything, it is a practice I usually follow religiously, but in this instance I was a little over-confident considering the lxc guests are backed up and easily restorable etc.

Anyway, thanks @fiona , funny how just talking to someone else opens the brain a little more.
 
Last edited:
  • Like
Reactions: fiona
I have a question about the automatic load balancing. We have five nodes in our cluster, three of them on AMD, and the other two on Intel. Is there a way to specify that Proxmox can only do live migrations between nodes that are on the same platform? Otherwise, a live migration breaks the guest.
 
I have a question about the automatic load balancing. We have five nodes in our cluster, three of them on AMD, and the other two on Intel. Is there a way to specify that Proxmox can only do live migrations between nodes that are on the same platform? Otherwise, a live migration breaks the guest.
The canonical way to solve that would be to not use the "host" CPU type.
 
three of them on AMD, and the other two on Intel.
Look at Datacenter --> HA --> Affinity Rules --> HA Node Affinity Rules. Read about the "Strict" flag shown there.

Probably you can create two rules, one with the AMD nodes and one with the Intel nodes. Select the VMs to be "in" the corresponding Affinity Rule.
 
The canonical way to solve that would be to not use the "host" CPU type.
Even then, AMD <-> Intel live migrations can break due to too many subtle differences and vendor-specific optimizations to guarantee that this could work independent of the used vCPU type; some types (like host) will make breakage much more likely, though.

Udo is spot on with the node affinity rules.
 
Hi, I just install one new ProxMox 9.2 via ISO, and found seems can not add/modify Notes of VM in the Summary tab. I had tried to created new VM, also can not add/modify the Notes.
Edit: I just tried to login via Chrome, and found Edit button is showing, seems it is only missing in Firefox browser.
 
Last edited:
Hi, I just install one new ProxMox 9.2 via ISO, and found seems can not add/modify Notes of VM in the Summary tab. I had tried to created new VM, also can not add/modify the Notes.
Edit: I just tried to login via Chrome, and found Edit button is showing, seems it is only missing in Firefox browser.
Working here normally, with Firefox 151.0.3 (64-bit).
 
  • Like
Reactions: leesteken
Migration from VMware ESXi 8.0.3 to PVE 9.2.2 was going smoothly. The import wizard is doing a great job.
Attention: VEEAM Backup 13.0 doesn't like Proxmox VE 9.2.x, this is an unsupported environment!
I learned this today from the VEEAM support team and had to find a workaround for this, because we don't want to go back to PVE 9.1, which would be supported.
Temporary workaround is using agent-based backups until PVE 9.2 is officially supported with VEEAM B&R 13.1 (no date for GA yet).
BUT installing Proxmox VE 9.2.2 was such a straight forward procedure, thank you for this release!
 
  • Like
Reactions: fba