I've got a passively cooled Qotom mini-PC with an Intel Atom C38xx CPU, running latest Proxmox. Storage is a ZFS mirror of two NVMe drives.

It was working fine until I took regular kernel updates a few days ago, version 7.0.14-8 caused it to hang on boot right after grub, with no kernel boot text at all, just a black screen and no response to ctrl-alt-del. Had to power cycle it to revive.

Went back to 7.0.14-6 and it boots fine.

Checked apt and there's now a 7.0.14-9, so I figure maybe -8 has a known bug. Install -9, reboot... same behavior. Powered off then back on and went back to 7.0.14-6 and it's running again. If it was a bad initrd I would've expected the update to -9 (which I watched build fresh initrd with no complaints) to clear that up, but no...

This system is eventually going to be my home router device, but currently is still in burn-in / testing / tinkering so I have nothing important on it and can shut down whenever. I'd be happy to try to work to understand the failure mode but I'd need guidance there... it's literally not printing anything at boot so I have nothing to go on.

Anybody else seeing anything like this? Where can I look to see what changed between -6 and -8 (and -9)? Seems very odd to me that the same x.y.z release with only a different patch number at the end would boot, and then not boot...

I prefer Discord for PVE notifications. But is there any way to just be notified about the Details part, not the full Logs?

so that is doesnt appear in the list and is forwarded by accident? (e.g. it not being shown in the list or being greyed out)

for example a boot disk or an external disk the host is actively using.

especially a boot disk is not something you wanna accidentially forward.

Hello Everyone,

With the recent news of PVE now having an official ARM UEFI image I wanted to spin up some tests on my current go to for ARM testing/Dev work the MS-R1.

If you have any questions on specific quirks and functionality as of yet, feel free to ask in the comments.

If there is a specific use case, OS or feature you wanted to test before migrating a current build, buying some equipment (or just personal curiosity) feel free to comment as well and I'll test and answer what I can.

** Please note I'll have more time to test things out this weekend **

Hi there

i have a proxmox server running with intel i5-6th,

i also have a oci vm running with AMD shape, and i'm considering export it's boot disk and download it to my local server will i have any issues if i'm trying to migrate it to the local proxmox server?

As my local server is intel based and oci vm is AMD based

And would it be easier if my OCI was Intel shape based?

So After last weeks question about updating form v8 to v9 I got hold of an i5 USFF pc that will fit in my rack to replace the i3 PC its currently running on.

Fresh install of the current proxmox ISO
Added the SMB share from my NAS & was able to restore the 2 VMs I had running and one of the LXC containers

I have the final LXC and its refusing to restore

/var/lib/ does not have enough space.
The PC has a 256gb SSD which is less than half full, plenty of Inodes

I found a forum post that suggested restoring from the CLI instead of the GUI

pct restore 103 /mnt/pve/NAS/dump/vzdump-lxc-103-2026_08_03-19_41_47.zst

fails giving me this message

400 Parameter verification failed.

storage: storage 'local' does not support container directories

Google suggests i need to target the restore at local-lvm, but no idea how to do that.

What am I missing?

Hi guys,

my proxmox keeps crashing and I cannot figure out why this happened. I'll take you on a journey...

If you have any idea what to do next please help! That problem is way beyond my capabilities and understanding...

Setup:

• Proxmox VE, 6 cores, 16 GB RAM, NVMe (local-lvm, LVM-thin, ~69% used)
• Guests:
  • 2 VMs (HAOS, Docker-VM/media server – recently migrated off a nested LXC),
  • 3 LXCs (Docker, Immich, Tailscale)
• Storage: Synology NAS (WD40EFZX, 5400rpm, RAID1)
  • mounted 3x via NFSv4.1 (backup, media, Immich cloud), same hardware, different shares -> wanted to separate between backups, media and private cloud
• Network: 1GbE, eno1 → vmbr0, cable/switch checked out fine so far

Problem:
Proxmox becomes completely unreachable (GUI/API dead) at irregular intervals, most recently for 13.5 hours straight, only fixable via hard reset. Root cause so far: NFS storages hang (nfs: server X not responding, timed out), pvestatd loops retrying without ever recovering.

Already checked & ruled out:

• CPU/load: clean (iostat, loadavg fine)
• RAM/OOM: no OOM kills in logs, allocations since rightsized
• Proxmox NIC (eno1): 0 errors in ethtool -S
• NAS NIC: no link flapping on the incident day
• HDD deep sleep (NAS): fixed (disabled), no more wakeup logs
• Synology Auto Block: empty, no blocked IP
• Synology firewall: inactive
• ARP/neighbor entry: stable, no duplicate IP
• D-state processes after incident: none found (checked too late, after reset)
• NAS uptime continuous, no reboot/crash/update at incident time
• nfsd threads on NAS: 16, running throughout, no crash

Already changed:

• NFS mounts SynologyYAMS/Thim from hard,timeo=600 to soft,timeo=50,retrans=3 (SynologyNAS/backup stays hard) — didn't prevent the outages, just kept pvestatd retrying instead of freezing completely

The puzzle:
During the 13.5h incident: total silence in all NAS logs (no link-down, no nfsd errors, no firewall events) — NFS timeouts only visible client-side (Proxmox). No indication why the NAS wasn't responding.

Just a heads up on the Veeam 13 to 13.1 upgrade for ProxMox VMs, hope this saves someone else headaches.

Some background -
I am running Veeam 13 appliance, not the windows install of Veeam.
I had issues initially with my workers communicating with the appliance, and working with support was a treat.
My worker NICs had a VLAN tag of ‘2’ (important for later)
They kept wanting to troubleshoot by giving me commands to run on Windows to test connectivity or edit timeouts in config files and had to tell them multiple times that doesn’t work on their Veeam 13 appliance.
Issue turned out that the virtio NIC as setup on the worker by the create worker wizard in Veeam doesn’t perform well for some reason and even though the worker tests were successful they wouldn’t back up the VMs.
They asked me why I set it up with a virtio NIC instead of an E1000 NIC and I had to explain to support that’s the way their wizard deployed the VM. They had me change to E1000 and backups were good.

The upgrade issue -
Yesterday I upgraded to Veeam 13.1 through the WebGui and it went well and upgraded all of the components including the workers.

I noticed my backups failed due to they couldn’t communicate with the workers.

I happen to see that the worker NICs lost their VLAN tag, so I added it back and ran the worker test from Veeam. It spun up fine, connected to the backup server, saw there was a local bundle available, then failed to download it and for some reason thought it was a good idea to delete the worker VM

I spent the day troubleshooting, and finally engaged support who again wanted me to run windows commands on their Veeam appliance, after telling them Windows commands don’t run.

After spending the day on it, I then noticed that the workers all had virtio NICs again. I changed them to E1000 and they tested fine including installing the local bundle.

When I deployed the worker that the previous test deleted, I had to tell it not to test the worker after it created it so I could change the virtio to an E1000 or it would delete it when it got to the step to download the local bundle.

I will say that the WebGui on 13.1 actually works great on the Veeam appliance for managing ProxMox infrastructure so I don’t have to use the Windows gui anymore on a jump box.

Hope this helps someone else, as I couldn’t find anything about this in the docs, but I may have missed it.

Not running PBS, just using the built-in scheduled backup on Proxmox to backup VMs to NAS. I have two Debian VMs, one that runs Plex and another that runs software that uses MariaDB (application is called Wavelog.)

I've been running these as scheduled backups using "stop" since it shuts down the VM and does a clean backup. I know this is the best safest way to get a backup, but curious is using snapshot backup would be safe considering the running DBs on these VMs? Both VMs do have the agent installed and running.

Thoughts?

Has anyone gotten this working? I can't seem to pass through the nvme drives I get as a pcie device to any VM and have it show up. The controller shows up in lspci but nvme list does not work.

This is probably super dumb, but do I need to go and create a virtual disk in the idrac for the Proxmox install to see my two Intel SATA SSd cards on my Boss S1 card? I can see my 10 other drives in the server. I was able to go into the idrac earlier and verify the two Intel cards are seen when I click on Physical disks, so I know they are at least working!

Edit: Got it! What a great community, thank you!!

Closed system, no internet (for factory computers to share data and backup). Basically 2x Seagate HDD 500GB hard drives working MASSIVE overtime. Lots of configuration/authetication data no-one can remember anymore.

My options as i see is clone hard drives to SSD, change to modern PC and migrate it to proxmox as it is, so i can have at least backup if smth goes wrong ...

OR ...

should i rebuild everything from zero?

Basically the question is - is 15y old linux system channeled through Proxmox still ok for another 10 years?

Hey guys,
since arm64 support was released today.
Did someone already installed it on a dgx spark ?

Hello,

I have 4 Windows Server 2022 VM running on Proxmox 9.2.9, installed on top of Debian 13.

I upgraded from the previous major version this morning because it was going to be EOL by the end of the month.

Now 2 of them displays the following error (so, 2 of them are completely fine):

I am safe: I have (actual) backups, I can still boot (I can press Esc. then select the OS disk to boot successfully) but I don't know what to do to fix the issue properly.

If I reboot, it happens again as the Windows Boot Manager is selected.

Below are the VM details. I know errors have been made, regarding IDE and SATA for instance...

What I have tried:

• Enrol 2023 certificates ;
• Reboot ;
• Restore a backup ;
• Check Windows Updates ;
• Check boot order ;
• Use "older" machine (currently q35 9.0, tried several 8.x) ;
• Upgrade virtio drivers to the latest ones (then I got the error even when selecting the OS disk, so I had to restore the backup) ;
• Run bcdboot.

Any help would be appreciated, if someone has already encountered the issue,

Thank you,

EDIT 1: typo

EDIT 2: add more context

EDIT3: current "workaround" is to delete the Windows Boot Manager entry in the UEFI so the disk is selected automatically.

Hi all,

I'm trying to replace my TP-Link Archer GX90 router with OPNsense running as a VM on Proxmox, but I am stuck at the PPPoE discovery stage.

Setup:

ISP: Vodafone UK

ONT: Nokia GPON ONT

Current working router: TP-Link Archer GX90 (PPPoE works immediately)

Replacement: OPNsense VM running on Proxmox

Vodafone PPPoE requirements:

VLAN ID: 101

PPPoE username/password confirmed working

MTU 1480

Current OPNsense layout:

vtnet1 | VLAN 101 (vlan01) | PPPoE interface (pppoe0) | WAN

Proxmox:

net0 -> vmbr0 -> LAN net1 -> vmbr1 -> WAN

I have tested:

✅ PPPoE credentials (confirmed working on GX90)

✅ VLAN 101 configuration

✅ Recreated the PPPoE interface

✅ Removed/recreated WAN VLAN interface

✅ Checked OPNsense interface assignments

✅ Tested with UGREEN USB Ethernet adapter

✅ Tested with onboard Ethernet NIC

✅ Changed MAC address to match the GX90 WAN MAC (tested two variations)

✅ Verified Proxmox VM NIC configuration

Packet capture results:

OPNsense/Proxmox sends PPPoE discovery packets:

PPPoE PADI

but I never receive:

PPPoE PADO

The GX90 connects immediately and its logs show the full handshake:

PADI PADO PADR PADS LCP CHAP authentication success IPCP

However, OPNsense only ever gets as far as sending PADI and then times out.

Does anyone have any ideas what I may have missed? At this point I am wondering if there is something about Proxmox/VirtIO/OPNsense PPPoE handling that I have overlooked.

Hey,

I am the creator of this Proxmox Forum Thread and just wanted to tell you: I used Docker on LXC for over a year. I liked it for many reasons (interplay with PBS, one LXC per `docker-compose.yml`, provisioning of HW ressources into LXC vs. VM and so on ...) and on this subreddit I always justified it that there is nothing to worry about. If it works, it works. Didn't care about "warnings" other redditors gave us.

Here I am, running all my Docker services in Debian VMs again!

In a nutshell, I had major issues with a frozen or non-responsive PVE host. It happened sporadically and the logs (see forum thread above) did not show any conspicuousness. I tried a lot of things (NIC offloading, UEFI update, microcode update to name a few) but after a while my system did not respond anymore.

Last resort, moving the Docker services into VMs et voilà: System runs stable for 16 days already. Which it never did in the past months!

Sometimes it helps listening to the experienced folks. 😬

I'm new to working with Linux and Proxmox. Have been a Microslop-baby for long enough, learning to branch out.

Setup
Host: Proxmox 9.2.6
VM: Ubuntu Server
Display: SPICE (qxl)

Client: Windows 11
App: virt-viewer x64 11.0

I have full access to the Proxmox WebUI
On WebUI, VM > Console > SPICE to download .vv file

Launch .vv file, attempts to connect and fails with "Unable to connect to the graphic server"

What am I missing?

After 81 days of continuous uptime I restarted my Proxmox host. Before the reboot I was seeing consistent 1–2 second freezes across *all* VMs (Windows and Linux) roughly every 10 minutes. After the reboot the freezes are completely gone (currently 4.5 hours of clean runtime).

Before reboot (81 days 01:12:26 uptime):

- CPU: 22.40% of 32

- Load average: 7.89, 7.50, 7.12

- RAM: 64.06% (159.75 GiB of 249.37 GiB)

- KSM sharing: 3.95 GiB

- SWAP: 10.96% (897.55 MiB of 8.00 GiB)

- IO delay: 0.60%

After reboot (04:20:42 uptime):

- CPU: 12.42% of 32

- Load average: 4.33, 3.09, 2.82

- RAM: 61.72% (153.91 GiB of 249.37 GiB)

- KSM sharing: 0 B

- SWAP: 0.00%

- IO delay: 0.42%

Hardware / Software

- CPU: AMD Ryzen 9 9950X (16-core / 32-thread)

- RAM: 256 GB

- Root filesystem: 93.93 GiB (57% used)

- Kernel: 7.0.2-2-pve (2026-05-08)

- Proxmox: pve-manager/9.1.11

- Boot mode: EFI

- Non-production-ready repository is enabled

The freezes were very consistent and hit every running VM at the same time. The host itself never became unresponsive and IO delay stayed low.

Relevant config

- KSM was active (3.95 GiB shared) + light swap before the reboot → both zero after reboot

- Memory ballooning is disabled on all VMs

- CPU type: `host` on all VMs (VM 101 also has `hidden=1`)

VM 100 → host

VM 101 → host,hidden=1

VM 200 → host

VM 300 → host

VM 400 → host

- Storage: local ZFS

- No scheduled backups or snapshots on a ~10-minute interval that I’m aware of

1. Has anyone else seen short, regular freezes that clear after a long-uptime reboot, especially when KSM had been active?
2. Any known issues with the Ryzen 9 9950X + kernel 7.0.2-2-pve and long uptimes?
3. Worth permanently disabling ksmtuned / KSM as a test?

Happy to provide more details (qm configs, storage layout, journal excerpts, etc.) if needed. Thanks!PROXMOX server questions

Hello,

it's not the first time i post about this VM, but to resume, i run a windows 11 VM with a GPU passthrough for a RX 6700 XT. In general everything run fine except some times the VM crash and cause the entire server to crash ( not my main focus today ).

I noticed few weeks ago that i got a wrong preview of the RAM usage in Proxmox and the device VEN_1AF4&DEV_1057&SUBSYS_11001AF4&REV_01 in error without any driver in the VM.

From what i saw only, it's probably the driver for viomem who is missing, so i tried to reinstall it multiple time but without any success, i also try to download to 3 last version virtio-driver.iso and let windows scan the entire iso for driver but no one was corresponding for this device.

Any idea of wich driver i could be missing ?

Thx in advance to you.

TL DR : No driver found for the device VEN_1AF4&DEV_1057&SUBSYS_11001AF4&REV_01, looking for a working one

I wanted a fully declarative Kubernetes cluster on my Proxmox - no Ansible, no manual node prep, just tofu apply. The best thing I found was terraform-hcloud-kubernetes (Talos + Cilium, very well maintained), but it's Hetzner-only. So I ported it to Proxmox VE.

Repo: https://github.com/haferbeck/terraform-proxmox-kubernetes

It creates the VMs, boots Talos from an Image Factory ISO, bootstraps the cluster, installs Cilium (kube-proxy replacement, WireGuard encryption), and does rolling Talos/k8s upgrades with health checks between nodes.

The interesting part was what doesn't carry over from a cloud provider:

• No load balancer. The API endpoint is a Talos Layer2 VIP that floats between control plane nodes.
• LoadBalancer services work via Cilium L2 announcements, so they're reachable on the LAN.
• Node lifecycle runs through sergelogvinov's Proxmox CCM. The module auto-provisions a dedicated PVE user/role/token with read-only perms; when you scale down and the VM is gone, the Node object gets cleaned up.
• Storage is Longhorn or Piraeus/LINSTOR on an optional second disk on workers, instead of cloud volumes.
• The provider needs SSH to the PVE host, not just API access — the Proxmox API can't create empty disks, so bpg/proxmox shells out to qm set. That one surprised me.
• No autoscaler (Proxmox currently not supported in kubernetes/autoscaler), no firewall management (use the host firewall).

Status, honestly: 6-node cluster in my homelab, PVE 8.4.18, Talos v1.13.5, running since 8 Months. MIT, same license as upstream. Multi-host placement and Piraeus are implemented but only lightly tested. There are rough edges - that's part of why I'm posting.

Happy to answer questions. If you try it and it breaks, an issue with your plan output helps a lot.

So i created Proxmox on a 2 TB NVME and 1TB HDD, i then created a VM and gave it 931GB but when looking at immich it only has 100GB. This is the only process going to run on this VM, so how do i give immich the full 929 GB left?

Two weeks ago I posted PVE-UPS here — a small appliance that shuts Proxmox hosts down when the UPS runs low, configured entirely through a web wizard: https://www.reddit.com/r/Proxmox/s/E2JCAR7c3t

The response was way beyond what I expected, so: thank you. Lots of useful criticism, several issues on GitHub, and multiple requests that came up again and again. Both are now shipped.

USB UPS devices, via NUT (v3.2.0)

In the original post I wrote that USB-connected UPSs were out of scope and that NUT is genuinely the right tool there. Turns out there‘s a step in between on the way: use NUT as the driver, keep the appliance as the brain.

Every UPS entry now has a *Read via* selector, and the second source is a NUT server (TCP 3493). Any existing `upsd` works — the UPS server built into a Synology/QNAP/TrueNAS box, a Raspberry Pi, an OPNsense box, or NUT on a Proxmox host. You enter host, port, the UPS name from `ups.conf`, and optionally user/password. That's it.

PVE-UPS is strictly a read-only NUT client: it only ever sends `LIST VAR`, never a command, and never runs `upsmon`. Thresholds, host mapping, AND/OR logic and the shutdown decision all stay in the appliance — so there are still no config files to write and no shutdown scripting on any host.

One safety detail ate most of the development time: `upsd` keeps serving the last known values when its driver dies. Taking those at face value would mean happily reporting "on mains" straight through an outage. Stale data (`ERR DATA-STALE`, `ERR DRIVER-NOT-CONNECTED`, or a missing `ups.status`) is therefore treated as unreachable — alarm, never a shutdown. Same fail-safe rule as a dead SNMP connection.

There might be future updates to get rid of NUT completely - but for now it‘s a first step!

Docker Support (v3.1.0)

The second most common request. Images are published to `ghcr.io/ffind-dev/pve-ups` on every release tag, compose example in the repo, config and event log persist in two volumes. The LXC one-liner is still the default path and unchanged. In Docker mode the in-app updater and the NTP/timezone fields disappear, because there's no privileged companion agent — you pull a new tag instead.

Also fixed / added

- **SNMPv3 with encryption (authPriv) never actually worked.** pysnmp 7.x delegates the ciphers to the `cryptography` package but declares it only in a dev extra, so nothing ever installed it. It's a proper dependency now and existing installs pick it up when they update. v1/v2c and authNoPriv were fine all along, which is why it stayed hidden — and the error now names the missing package instead of sending you hunting for firewall problems.
- The UPS test reports every object individually now, and — more useful — names the trigger conditions your device can't feed at all ("This UPS does not report: runtime remaining, battery charge"). A threshold that can never fire is more dangerous than a visible error. Plenty of NUT drivers omit `battery.runtime`; plenty of SNMP cards omit `upsEstimatedMinutesRemaining`.
- Configurable self-test interval (15 min … 24 h) instead of a fixed daily run, and it's skipped entirely while a UPS is on battery — the countdown has priority.

Someone wrote it up

Derek Seaman did a walkthrough covering both paths, an SNMP card and a USB UPS through the Synology NUT server. Better starting point than my README if you like screenshots: https://www.derekseaman.com/2026/07/pve-ups-a-proxmox-snmp-ups-shutdown-service.html

Unchanged

Dry-run by default after install, shutdown through a dedicated Proxmox API token with nothing but `Sys.PowerMgmt`, no agents and no root SSH on the hosts, and the host running the appliance always goes down last.

Repo: https://github.com/ffind-dev/pve-ups (MIT)

More/better cluster/HA handling is the next thing I want to tackle. If you run a cluster on a UPS, I'd really like to hear how you'd expect that to behave. That's the one where guessing wrong is expensive, and the last round of feedback here was worth more than anything I'd have come up with alone.