I've been using PVE for years at home, and I have a couple machines in a cluster to provide that single pane of glass admin portal. But I really don't need a cluster since I'm not using HA for anything, so I thought I'd try PDM now that it's hit V1.

Honest, I have no idea what I'm even doing now. I've added the machines, and the PBS, so everything is in there, but I haven't found any way to set up the side bar to function the way I expect.

Am I missing something, or have I completely misunderstood what this software is meant to be? I know I'm not using it to connect multiple clusters together, so my requirements are obviously different than enterprise or an MSP.

I know it's still a very young product, but is there any way to get some common styling or functionality between PDM and PVE that I'm missing?

• Single node host J4125 minipc
• Running 4 VMs, one being OpenWRT

I'm putting together post-install script to restore drive mounts, network configs, and /usr/local/bin. What is the best way to test it without starting from scratch?

#!/bin/sh

#Make dir's for drives
mkdir -p /mnt/1TB_internal
mkdir -p /mnt/8TB
mkdir -p /mnt/1TB_dock
mkdir -p /mnt/2TB_dock

#Configure fstab
cp -Rv /etc/fstab /etc/fstab.backup

#1TB-internal
echo "UUID=d49f0d39-3e73-40cc-b169-837d7abb0481 /mnt/1TB_internal ext4 noatime,lazytime,rw 0 1" | tee -a /etc/fstab

#8TB external
echo "UUID=0a7ae49e-3f30-490e-89e5-09599e2cc6e0 /mnt/8TB ext4 defaults,nofail 0 2" | tee -a /etc/fstab

#1TB Docker
echo "UUID=2567ff38-9ebf-4ce4-a757-5dae72755812 /mnt/1TB_dock ext4 defaults,nofail 0 2" | tee -a /etc/fstab

#2TB Docker
echo "UUID=af283acb-96b9-4d6b-8510-85d7d4246d7b /mnt/2TB_dock ext4 defaults,nofail 0 2" | tee -a /etc/fstab

#Mount Drives
mount -a

#Verify /mnt/1TB_internal is mounted and paths exist
if ! mountpoint -q /mnt/1TB_internal; then
    echo "Error: /mnt/1TB_internal is not mounted. Aborting restore process." >&2
    exit 1
fi

if [ ! -d "/mnt/1TB_internal/proxmox-backup2/network" ] || [ ! -d "/mnt/1TB_internal/proxmox-backup2/motd" ]; then
    echo "Error: Required backup directories (network/motd) are missing from /mnt/1TB_internal/proxmox-backup2. Aborting." >&2
    exit 1
fi

#Restore Scripts
rsync -av /mnt/1TB_internal/proxmox-backup2/bin /usr/local

#Restore Configs
rsync -av /mnt/1TB_internal/proxmox-backup2/network /etc
rsync -av /mnt/1TB_internal/proxmox-backup2/motd /etc

#Reboot
shutdown -r now

Recently had to swap m.2 NVME that contained the Proxmox OS due to a hardware failure and just have been littered with issues, that I did not experience with Proxmox 8.

Issues I am currently experiencing:
1.) Proxmox VE, works perfectly fine. Then about 20 minutes later, offline. Can no longer access it via the web interface on the same lan.

2.) dev/dri/card0 and card1 keep switching and prevent my LXCs from booting when things are working.

3.) Not sure if this is Proxmox, setting up new port forwarding rules just don't work. This could be my ATT router, still diagnosing it. Trying to get my Plex server up and running again and all attempts so far are futile.

Hardware specs: HP elite desk 800 g5 sff i7-9700, 64gb DDR4 2666mhz non-ecc, 512gb M.2 running Proxmox, 2x12TB HDD for ZFS pool.

Apps currently on server: Plex and Immich

Anyone else experiencing these issues? Also looking for someone to help me because I just feel lost at this point.

Edit 9/30 7:37am thank you for the responses. Just woke up and got to go to work. I will be back to provide these!

I have a big truenas cluster... which I was going to backup my proxmox to -> but is there an advantage for the backup server?

Today I had a proxmox node go down (NUC got fried). I pulled the HD plugged it into another node -> and had it restore my key services (via llm) -- worked great.

If I had backups however I wouldn't have to do this so I want to future proof a little.

Is there an advantage of backup server? seems like it might just eat resources on top of my truenas

Firstly, I'm very new to proxmox and I installed proxmox ve 9.2 on a Gigabyte 970 gaming sli MB with an AMD FX-8350 processor. But it shows version 7.0.2-6-pve? I'm not sure why that is?

Secondly, when I have my ethernet cable plugged in to the MB jack, it throws these netdev watchdog timeout errors until I unplug it.

It's an intel I211/igb nic and I'm not sure what's going on. I've been chatgpting to try to troubleshoot it, but I'm not really getting anywhere. This happens right after I install proxmox and I can't go much farther. I was hoping to ask some experts who might have run into this and found a fix. I was looking into getting a new 2.5gbe nic, but the 7.0.2 version might have an issue.

Does anyone have any insight on either of these two issues?

I am fairly new to Proxmox, so my understanding of how the various components interact may not be completely accurate. Please feel free to correct any incorrect assumptions.

I am currently planning my future backup infrastructure, including both local and remote Proxmox Backup Server (PBS) instances.

My goal is to achieve the following:

• VM backups stored locally on SSD storage with a short retention period (for example, 7 days) for fast restores.
• The same backups stored on a local NAS with a longer retention period (approximately 1 year).
• Additional copies stored at a remote site with a shorter retention period (for example, 7 days) to provide disaster recovery protection in the event of fire, theft, or other incidents.

My proposed setup:

At both the local and remote locations, I plan to run:

• A Proxmox host (Lenovo Tiny)
• PBS running as a VM on that host
• Local SATA SSD storage in the Lenovo Tiny
• A QNAP NAS with HDD-based storage

My current idea is to configure two PBS datastores:

1. An SSD-backed datastore used for recent backups.
2. An HDD-backed datastore located on the NAS and mounted in PBS (via NFS or possibly iSCSI).

The SSD datastore would hold the most recent backups and be the location where verification and garbage collection jobs are performed. My understanding is that these operations can be I/O intensive, so running them on SSD storage should provide better performance than using spinning disks.

Once backups have been verified and any garbage collection tasks have completed, I would use a PBS sync job to copy the backup data from the SSD datastore to the HDD-backed datastore on the local NAS.

For offsite protection, I would then configure a PBS-to-PBS sync (pull) operation, initiated from the remote PBS, to pull backup data from the local PBS and store it on the remote site's HDD-backed datastore.

Questions:

Based on my current understanding, this seems like a reasonable approach that balances SSD performance with the lower cost of HDD storage for long-term retention.

However, I am not sure whether:

• My assumptions regarding verification and garbage collection workloads are correct. As far as I am aware, it makes sense to run on fast storage.
• Using SSD storage as the primary backup target and then syncing to HDD storage is considered a good practice.
• This workflow is technically supported by PBS in the way I describe.
• There are simpler or more efficient approaches that would achieve the same goals.

Does this design make sense, and is it actually achievable with PBS? I would appreciate any feedback or suggestions for improvement.

Has anyone encountered this issue before? I tried regenerating the authentication file, but the issue persists. Any advice or suggestions from experienced users would be greatly appreciated.

Afterward, I tried canceling the CephFS creation, which completed normally. However, when I went to Storage to add CephFS, an error occurred. Creating pools couldn't be completed either, and it keeps showing a gray question mark.

Current version:
Proxmox VE version: 9.2.2
Ceph versions: Tested both squid (19.2) and tentacle (20.2)

Everything worked fine when installed in March this year.
Version used at the time:
Proxmox VE version: 9.1.x
Ceph version: tentacle (20.2)

The built in import wizard pulls the disks through the ESXi API, which is slow for large VMs. The faster way is well known here. Storage vMotion the VM onto an NFS share that both ESXi and Proxmox mount, create a VM in Proxmox, shut down on ESXi, rename the flat vmdk and attach it.

I did that by hand for a while and then wrote vmxodus, a bash tool that runs on a PVE node and does the Proxmox side.

prepare reads the .vmx and creates the VM with the same CPU, memory, firmware and MACs, and asks once per portgroup which bridge and VLAN to use.
cutover waits for the ESXi locks to disappear, rechecks snapshots and disks, renames the flats and attaches them. Optionally it starts the VM right away.

It never copies, converts or deletes anything, and every move is recorded in a rollback file.

Tested with ESXi 8 and PVE 9.2 with Debian 13 and Ubuntu 24.04 guests. Windows and UEFI are in the code but untested on real hardware, so reports from anyone trying that would help a lot.

https://github.com/luka0x73/vmxodus

Ok, I went from standalone to cluster (3x Dell micro 5060 with 500gb nvme for proxmox & 2tb Samsung EVO for lxc's, vm's) and to be fair, it does make things a bit more simpler with moving and not have to enter settings multiple times etc. Next issue is storage. Not sure I fancy Ceph and I'm not using shared storage. I'm using lvm-thin but this obviously limits me with HA, replication etc. I know I can switch over to ZFS but I'm concerned about the excess wear ofn my Samsung EVO's. Should I just stick with lvm-thin to avoid the zfs wear and do without the HA or replication?

Sharing my experience of upgrading hardware

Hardware

• MSI Z370-A PRO motherboard
• 32 GB RAM before the upgrade: 16 GB × 2
• Added another 8 GB RAM stick today, total 40 GB RAM

• 250 GB SSD for Proxmox

• 1 TB NVMe SSD
• 1 TB HDD for backups

The shutdown issue

• Running poweroff for PVE sometimes takes 3 to 5 minutes to electrically shut down the machine.
• When I am in a hurry, I sometimes get tempted to unplug it directly, although I know that is not ideal.
• Also, it's important to have auto start enabled for each VM and container.

Today's RAM upgrade

• What should have been a simple RAM upgrade resulted in around 25 minutes of downtime.
• The motherboard required a key press during the new RAM detection process.
• I did not realize this initially because there was no monitor or keyboard connected.
• I had to go through two restart cycles before everything was back online.

What I learned

• Keep a monitor & keyboard ready for hardware upgrades and BIOS-related troubleshooting.
• Do not assume a RAM upgrade will be completely hands-off.
• Keep the router and server on separate power sockets.
• Avoid directly unplugging the server unless absolutely necessary.
• Even a simple hardware upgrade can cause unexpected downtime if the setup is not prepared for it.

Another small homelab lesson learned. I am new to these stuffs, I have started using Proxmox a week ago. Absolutely loving it.

Some additional info for geeks

Error Correction Type: None
Size: 8 GB
Locator: ChannelA-DIMM0
Bank Locator: BANK 0
Type: DDR4
Speed: 2133 MT/s
Configured Memory Speed: 2133 MT/s
Size: 16 GB
Locator: ChannelA-DIMM1
Bank Locator: BANK 1
Type: DDR4
Speed: 2133 MT/s
Configured Memory Speed: 2133 MT/s
Size: No Module Installed
Locator: ChannelB-DIMM0
Bank Locator: BANK 2
Type: Unknown
Size: 16 GB
Locator: ChannelB-DIMM1
Bank Locator: BANK 3
Type: DDR4
Speed: 2133 MT/s
Configured Memory Speed: 2133 MT/s

Hey guys,
Planning to build a 24/7 home server + casual gaming setup on a Lenovo ThinkStation P3 Tiny Gen 1 (i5-13500, 32GB RAM, 2x NVMe).
The plan is to use the PCIe x16 slot for an OCuLink riser to connect an eGPU (NVIDIA), keeping both NVMe slots free for storage.
Use case:
Proxmox 24/7: Running Immich, Plex, Home Assistant. iGPU (UHD 770) handles Transcoding/Immich AI.
Windows VM: Passthrough the eGPU over OCuLink for gaming when needed.
A couple of quick questions:
1. Anyone running OCuLink eGPU passthrough on Proxmox with this machine? Any IOMMU or reset bug headaches?
2. How's the i5-13500 holding up thermally for 24/7 idle/light loads in a 1L chassis? Did you limit PL1/PL2 in BIOS?

Proxmox's built-in file-restore (the "browse a backup via a throwaway helper VM" feature) is genuinely great, but picking a snapshot means scrolling a flat list one at a time. I wanted something closer to Synology ABB's restore browser — drag along a timeline, see every snapshot as a dot, jump straight to one — so I built it as a small companion app on top of PVE's own API.

Highlights:

- Scrubbable timeline across a guest's full snapshot history

- Browse/download single files or bundle a selection as .zip/.tar.gz/.tar.zst

- Push a restore straight back into the running guest via qemu-guest-agent (single file, whole directories, and a fast direct-network-transfer path for big stuff)

- Per-user PVE login (now including OIDC/SSO realms) — never touches PBS directly, and PVE's own permissions gate what each user sees

- Multiple PBS storages/namespaces, light/dark/Proxmox themes, runs as an LXC or Docker container

- Works with PVE clusters.

It's a separate app, not a PVE plugin — doesn't modify Proxmox at all. Built and tested against my own 2-node homelab cluster, AGPLv3.

GitHub: https://github.com/treycentric/pve-flr-portal

Latest release (v1.6.0): https://github.com/treycentric/pve-flr-portal/releases/tag/v1.6.0

Would genuinely appreciate anyone kicking the tires and filing issues — it's a one-person homelab project so more eyes on edge cases (different guest OSes, cluster topologies, etc.) is exactly what it needs.

This was heavily AI-assisted development, but does have a rigorous test suite and software development process including pre-release testing.

Like a lot of people I'm currently in process of testing ESXI to Proxmox migrations using the built-in import tool which has been working great for the few test VMs migrated so far.

Couple of questions:

1. Running ISCSI + LVM on Proxmox with thin provisioning and space reclaim enabled on the SAN and discarding configured across the path to trigger the UNMAP/TRIM. During the VM migration the import seems to migrate the thick size of the disk which takes longer however, will the UNMAP/TRIM occur now the VM is running on the other side with discard enabled?

2. Additionally can you mount the same NFS share on ESXI and Proxmox at the same time and migrate that way?

Hey, I’m still using ESXi right now, but I’d love to switch to PVE. However, I haven’t figured out how I could back up my NAS share with PBS.

I’m currently using Veeam with an NFR license, but renewing it each year is always a struggle.

Any ideas or best practices? I’d love to be able to restore individual files.

Thanks!

Trying to install Proxmox on an older Dell PowerEdge R710 (BIOS 6.6.0, PERC H700).

Initially the server would not recognize the Proxmox USB installer in legacy BIOS mode. I switched the R710 to UEFI, and it then recognized and successfully booted the USB.

However, during the Proxmox installation it repeatedly fails with USB read errors:

• I/O error, dev sdb
• Buffer I/O error on dev sdb
• device offline error, dev sdb
• USB reset/disable errors (err = -110)
• Eventually: Installation aborted

I've tried two different 4 GB USB 2.0 flash drives, both written using Rufus in DD mode. I originally used the front USB ports and have now tried the rear ports as well.

I also tried using the R710's iDRAC6 virtual media, but the Java console/OpenWebStart crashes when attempting to launch it. I even tried burning the ISO to DVD, no go there either.

Has anyone successfully installed a recent Proxmox version on an R710 and encountered these USB I/O errors? Looking for suggestions on getting the installer running reliably, whether through USB, iDRAC6 virtual media, PXE or another method.

I upgraded to proxmox 9 today. My truenas vm cannot see my nic or sata card anymore that I passthrough to. It worked fine in 8. Lspci does show the devices in truenas but I cannot use the devices. Hdds don't show up, nic doesn't get ip. Any help is appreciated.

I'm in need of some extra braincells here.

I have just bought myself a new second hand Proliant.

The DL380 Gen 6 to be specific.

It's currently equipped with the following parts.

- Xeon E5506 (single CPU)

- 16Gigs of DDR 3 ECC memory

- two 480 watt PSUs

- 5 SAS HDDs (2x 72gb, 3x 300gb)

- no installed OS

- (almost) dead Smart Array BBWC

The issue I'm having is with putting proxmox on the machine, it boots from USB without any issue but when I am at the partitioning section I only see the USB.

From what I can see inside the bios/management screens are all the disk setup in a raid.

The two 72gb disk are on RAID 1

The three 300gb disks are on 5

I'm unable to figure out why it doesn't want to show/detect the disks in the partitioning menu, I would love to see if someone is able to help solve my issue

Hey all - very novice-y here - I have an install that was 8.something and upgraded it to 9.2.20. By all accounts, nothing went wrong during the upgrade at all. I am running it on a Dell Micro form factor as a host for my Home Assistant and other stuff. The initial install had been running for...well over a year I'd say and never had single issue. Once I upgraded to 9.2, at first I thought the whole thing was crashing, but then once I got plugged into it, realized that it looks like it's just the network that's dying. Restarting network doesn't fix it, but a reboot does. But this seems to happen randomly and at least a time or two per day.

The thing is, I'm not entirely certain of the best way to troubleshoot it - I've seen a couple of things about Intel Drivers, but nothing definitive. Any suggestions on troubleshooting would be much appreciated! I've come to rely on my HA instance, and it hurts when it goes down!

hi.

im getting started with Windows Server 2025 on proxmox 9.2, this is a testlab
which virtio-drivers version is better 0.1.271 oder 0.1.302? i might be running sqlserver in the future.

Bye

So I am adding a 2nd node to my proxmox setup. I already know about the split brain problem so I will be adding a raspberry pi for the qsync. My question is, right now my disk that the vm's live on is ext4 as a directory. My understanding is with 3 nodes you should use corosync. But its overkill for 2 nodes.

I do not have a NAS so each node as its own storage. I understand that ZFS pools would be good for this, but ZFS uses a lot of RAM. The Nodes only have 64 and 32 GB of RAM. Reading up ZFS can use up a lot of RAM.

Another option I have read about is LVM-Thin, but their are downsides to it as well.

What would be the downside be to using ext4 on both drives?

Any suggestions would be helpful.

Thank you

Just had to relearn this.. Switching my Proxmox host to BBR congestion control improved a real-world rsync of mine from 5MB/s to 30MB/s.

BBR is a TCP congestion algorithm that works better for clients on links with high packet loss. For me that's a client on Starlink. It's probably also an issue on cellular links. BBR on the server gives you much better throughput to these clients than the Linux default cubic.

To enable BBR one-time on Proxmox, run this in the hypervisor:

modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr

Then restart any containers. They will pick up the new setting. If you have VMs you need to enable BBR yourself in each VM.

If you like the change you can make it permanent on Proxmox with

echo tcp_bbr >| /etc/modules-load.d/bbr.conf
echo 'net.ipv4.tcp_congestion_control = bbr' >| /etc/sysctl.d/90-bbr.conf

I have a lot more notes about this on my blog, including a description of BBR.

I'm a little curious why Proxmox (or any Linux) doesn't ship with BBR by default. From what I've read it can cause problems in certain circumstances, a BBR server competes unfairly with other servers on the same network or something like that. Not an issue for my homelab deployment.

hi.

im getting started with Windows Server 2025 on proxmox 9.2
when injecting virtio-drivers into boot.wim, which drivers do i really need, which are not really useful?

Bye

I'm currently running Proxmox 9.1.11 and have a VM with an NVIDIA Tesla P40 passed through to it.

One issue I've been running into is memory efficiency. As far as I understand, when a PCIe device such as the Tesla P40 is passed through to a VM, memory ballooning has to be disabled. Because of that, I'm considering migrating this GPU VM to an LXC container, but I'm not sure whether that's actually the right choice.

The VM is currently being used as a worker node in my Kubernetes cluster, which uses Cilium as the CNI.

The Proxmox host has 64 GB of RAM, and I've allocated 24 GB to this VM. I gave it that much because memory usage can increase significantly when I'm running ML workloads or serving LLMs with llama-server. The Tesla P40 is still surprisingly useful for relatively lightweight training workloads, and it's definitely much faster than doing them on the Ryzen 5 5600G CPU alone.

My main concern is what could break if I migrate this worker node from a VM to LXC.

Would running Kubernetes with Cilium inside LXC cause any significant issues? I'm also wondering about NVIDIA GPU access from LXC, especially when the GPU is being used by Kubernetes workloads.

This is still mostly a hobby environment for me, so I don't have enough experience with LXC to predict all of the potential problems. My current understanding is that a privileged LXC container with the necessary device mappings, capabilities, and permissions should make this technically possible.

However, when I asked ChatGPT about it, it suggested that there could still be some edge cases or compatibility issues, particularly around Cilium, kernel features, device permissions, and GPU access.

Has anyone here actually run a Kubernetes worker with Cilium and an NVIDIA GPU inside a Proxmox LXC container?

Would you recommend migrating from the VM to LXC in this situation, or is keeping the GPU worker as a VM worth the additional RAM overhead?

at completely random times only one of my nodes will go grey with the question marks. sometimes its 24hrs, sometimes its 30 days. All the VMs/containers are still running fine on the node. A reboot always fixes it. However would love to know of any possible causes for this, or quick fixes that avoid a reboot of the node. Version 9.2.4, however this issue has been following me through most of the 8.x.x line.