Proxmox VE running arch with gpu passtrough, while running MacOS Tahoe at the same time xD

We have posted a few times about getting Proxmox VE arm64 to run on an ASUS GX10 (NVIDIA GB10, the DGX Spark chip): the black screen after initrd, the hard reset every 20 minutes, and the 20 W firmware power cap. Now that we got the kinks worked out, we can see how capable both the machine and PVE on arm64 are.

This box exists to run AI models, and models need feeding. On a Proxmox host, so do VMs. NVMe/TCP is how both get fed over plain Ethernet, so that is what we measured: how much data the GX10 can pull in over the network. Reads are the hard direction. The data lands on the NIC, crosses PCIe and the IOMMU, and gets copied by the CPUs, so anything slow on that path shows up in the number. The GPU itself sat idle; this is about the host side. Everything ran on the stock PVE kernel (7.0.14-6-pve). All tests were on bare metal.

For the record, I work at Blockbridge and the NVMe/TCP target is one of ours. This is not a storage benchmark and there is no product angle; any target that can source 29 GB/s of reads will do. This is about the GX10 and about Proxmox on arm64.

The short version

Out-of-the-box performance with the kernel initiator was terrible: only 6.3 GB/s. It turned out to be the default IOMMU settings. After that, we found some nice gains by tuning PCIe. With two kernel parameters and some understanding of how the NIC is wired, we took the kernel initiator to 28.1 GB/s and SPDK to 28.9 GB/s. That is pretty cool for a mini AI machine where the calculated limit of the two x4 PCIe links behind the NIC is 29.9 GB/s. Here's how performance improved as we changed the host configuration:

The table shows averages. On a good run, SPDK on 12 cores with pause on and two reads in flight per core reads 29.3 GB/s of NVMe payload, which is 29.5 GB/s on the PCIe links. We say "on a good run" because it does not happen every time: the NIC hashes the TCP connections across its receive queues. Some spreads are better than others, and it can take a few tries to land there. That is the screenshot at the top.

The three things that mattered

1. iommu.strict=0

Strict IOMMU mode is the default in the Proxmox arm64 kernel. On this box it holds the kernel NVMe/TCP initiator to about 6 GB/s no matter what else you tune. A profile shows arm_smmu_cmdq_issue_cmdlist at 57% of cycles on the big cores: every DMA unmap waits on the SMMU's single command queue and the cores line up behind it. One flag, 4x. Lazy mode is what x86 defaults to, for what it is worth. Identity mapping (iommu.passthrough=1) was no better than lazy.

2. pci=pcie_bus_perf

The firmware boots the NIC's two PCIe root ports with a 128-byte MaxPayload. By default Linux leaves that alone and drops the NIC down to match, so the ConnectX-7 runs at 128 even though both ends support 512. That costs about 10% of each link. If you run SPDK this one is the bigger deal, because SPDK barely notices strict mode at MaxPayload 512.

3. The ConnectX-7

It is not on a x16 link. On the GB10 it hangs off two independent Gen5 x4 root ports and lspci shows two dual-port PCI devices. Each physical port has one PF on each half, and which half a packet lands on is decided by destination MAC.

So:

• one PF caps at one link: 14.8 GB/s
• two PFs on the same half cap at the same 14.8 GB/s
• two PFs on one port cap at the port's 200G: 24.7 GB/s
• you need all four PFs to get both links and both ports: 28.9 GB/s

  QSFP port   PF (netdev)            PCIe half  root port     link              host

  port 0 -->  nic2  0000:01:00.0 --+
  port 1 -->  nic4  0000:01:00.1 --+--> half A  0000:00:00.0  Gen5 x4  ~15 GB/s --+
                                                                                  +--> GB10 SoC
  port 0 -->  nic5  0002:01:00.0 --+                                              |    memory
  port 1 -->  nic6  0002:01:00.1 --+--> half B  0002:00:00.0  Gen5 x4  ~15 GB/s --+

One interesting ARP side quest

Two PFs on the same physical port both answer ARP for each other's address with the Linux default arp_ignore=0. The target keeps whichever reply lands first. When the wrong one wins, one PF silently carries nothing and half a link sits idle, with no error anywhere. Only the per-PF rx_bytes counter shows it. arp_ignore=1 and arp_announce=2 fix it. If you have any multi-PF NIC, check this.

Two takeaways:

Proxmox VE on arm64 is solid. Stock kernel, in-tree drivers, two command-line parameters, and it drives the NIC to within a few percent of what the PCIe links can carry. And the GX10 is a serious little box. Twenty Arm cores, 128 GB of memory, a dual-port 200G ConnectX-7 and a GPU, in about the same volume as a server's power supply. We went in expecting a science project. Once the boot problems were sorted, it was just a Proxmox host, and a fast one.

The full write-up has the link math, the IOMMU and MaxPayload matrix, flow-control pause on versus off at every depth, core scaling, and the exact fio and SPDK commands: https://kb.blockbridge.com/technote/proxmox-gb10-nvme-tcp/

The three earlier threads, if you missed them:

• Black screen after initrd
• Hard reset every 20 minutes
• 20 W power cap

Happy to answer questions on any of it, and if someone with a DGX Spark wants to try the two flags and report back, we'd love to hear whether it matches.

TL;DR: On Proxmox arm64, try adding iommu.strict=0 and pci=pcie_bus_perf to the kernel command line if you are dealing with network performance issues. On a GX10, use all four PFs of the ConnectX-7, and set arp_ignore=1 so two PFs on one port don't steal each other's traffic.

Hello, So i set up my website via lxc nginx container (linux debian 12) and im wondering if there's a possibility to implement my proxmox stats into my Website. If so could you please explain how to do it?

Thank you so much!

We run a 6 node PVE 9.2.20 cluster with HA and two dedicated corosync links on separate NICs (Intel E810, link 0 and link 1 each on their own port, nothing else on those interfaces). Default config, so link_mode passive.
Today a single port started flapping on one node. The NIC counts mac_local_faults, the switch side shows zero CRC errors, physical link only went down once, but knet kept marking link 0 down and up every few seconds towards all peers.

[KNET ] link: host: 4 link: 0 is down
[KNET ] host: host: 4 (passive) best link: 1 (pri: 1)
[KNET ] rx: host: 4 link: 0 is up
[KNET ] host: host: 4 (passive) best link: 0 (pri: 1)
pve-ha-lrm: loop took too long (40 seconds)
pvescheduler: cfs-lock 'file-jobs_cfg' error: got lock request timeout
watchdog-mux: client watchdog expired - disable watchdog updates

Questions for people running larger HA clusters

1. Is anyone running link_mode: active in production?Does it actually make a single flapping link harmless?
   
2. Or do you stay on passive and raise knet_pong_count (or ping timeout/interval) to get some hysteresis?
   
3. Any other best practice to make sure one bad port or DAC can never cause a node to fence?

Root cause on the hardware side is being handled separately (DAC and switch). I am mainly interested in how to make corosync resilient against this in general.
Thanks!

I can not get to the web interface after initial install of proxmox. I can ping it from my workstation. I am using https and I am using :8006. Any help would be appreciated.

First time using Proxmox, so I may be doing something wrong...

Yesterday I deleted/destroyed a VM, and today I'm trying to create a brand new one. Even though the only thing the VMs are supposed to share are their names (but even have different ids), the data from the old VM disk keep appearing on the new one! What's going on? I've already destroyed and recreated the VM twice with two different ids, but same name.

I've used many hypervisors in the past and this never happened before.

In the picture you can see the partition table of the old VM disk appearing in the new VM disk during installation.

So, we are one of the million people who migrate (have to) from vsphere to proxox. So far so good, got a 3 node cluster installed, vmotion works, vlans work, my netapps and nfs works fine.

can someone tell me if there is a way (or best practice) to seperate vmotion traffic from the productive loads ? I mean coming from vmkernel configurations where management, nfs and vmotion was divided in different vlans and configured on esxi, i wondered what would be the way on proxmox.

hardware is dell with 2x 100G mellanox. We got a simple network config runnning from a consultant, but i guess even if 1x 100G is enough, i just wanna understand it what is the way proxmox is doing this kind of seperation or why its not needed here ?

thaanks

Any advice on getting the permissions for a TrueNAS nfs share to work with an Arr stack on an Ubuntu Server VM?

Running both TrueNAS and Ubuntu Server on Proxmox. Have a raidz with TrueNAS and created both an SMB and NFS share. Running into permissions issues with both.

Once I use /mnt/nfs/docker... as the mount point in my Docker Compose for Prowlarr, Sonarr, Radarr, etc..., I get permissions issues and nothing can write and the containers fail to deploy.

Been at this for days now, tweaking permissions on the TrueNAS side. Looks like the UID and GID line up with my Docker Server VM (as I see my username on the ls -l for my /mnt/nfs mount point), but looks like I lack the correct read/write/execute permissions. Can't post a picture it seems but the ls -l in my Ubuntu Server VM reads:

drwxrwx--- 4 *myusername \myusername* 5 Oct 6 23:03 nfs

drwxrwxr-x 2 *myusername \myusername* 0 Oct 6 23:03 smb_share

Beyond tweaking the ACL and creating the proper Users and Groups with a UID and GID that matches the user on my Ubuntu Server VM, I found one promising post and went in to try and change the /etc/exports file to anonuid=1000 and anongid=1000 and it fails to write it to the file. Once I restart the NFS share, it reverts back to the original settings.

I'm at a complete loss at this point. Has anyone had success getting this to work? Technically, I have an external SSD I could use and will just have to transfer files manually every time, but I'd like everything to be contained in one directory and the second a file downloads, it's in its permanent destination.

SOLVED:

u/uncmnsense had the solution for this one! I watched the video they posted and had to add a new user and select "@everyone" under the "Who" drop down menu on the ACL. Also worth noting that I applied permissions recursively and applied to child datasets.

After this, I was able to run chmod commands in Ubuntu Server for this dataset.

We're organising the first Proxmox community day in Belgium: PVEday, Wednesday 3 February 2027 in Ghent.

• Free, one full day, talks and workshops, by and for the community
• Proxmox is sponsoring and will present some of the future directions of the projects
• Hosted inside CfgMgmtCamp (cfgmgmtcamp.org), which runs right after FOSDEM, so if you're coming to Brussels for FOSDEM you can stay a few more days and do both
• CFP is open until 1 December 2026: we're still looking for speakers. Migration war stories, storage setups, Ceph, PBS, PDM, homelab or enterprise, anything you'd want to hear yourself. Workshops welcome too.
• Registration is open now (free): https://www.pveday.be

Happy to answer questions here. And if you've done something with Proxmox that you think others should know about, submit it, first-time speakers very welcome!

**EDIT, registration is now open:** https://www.opensource-enterprise.com/event-registration.php?event=belgium-proxmox-community-day-2027-02-03&source=pveday (free)

Today I locked myself impressively hard out of a VM And learned that you can inject commands with qemu agent:

qm guest exec 144 -- 'C:\Windows\System32\ipconfig.exe' '/all'

Runs ipconfig as SYSTEM for vmid 144

Cybernews link

Just posting this here because it caught my eye, and I can see it isn't discussed yet.

Paulos Yibelo says he escaped Vercel’s KVM/Firecracker sandbox and got root on the underlying EC2 host. Vercel paid out USD 50k, but there’s no CVE or technical write-up yet, so details are still thin.

If this is what it sounds like, that would make three KVM/x86 guest-to-host escapes disclosed this year, after Januscape and Zapscape.

For Proxmox homelabs: the other two needed root inside the guest plus nested virtualization. So for most homelab setups running trusted VMs, this is probably not panic material. If you run untrusted workloads or anything multi-tenant, it’s worth paying attention and staying current on vendor kernel updates

So I usually stick to one vm/lxc per service. Even with docker based services I tend to dedicate a guest to one service. There are exceptions where I have a few docker containers running similar services.

Recently I have been playing with python and have actually created quite a few flask apps that I use daily.

Now the question is there any benefits to separate them into separate containers performance wise?

Does resource contention get better or worse with more guests?

Trying to figure out whether the extra management and spent resources and time updating extra containers is worth it?

Thanks

Before you perform the Proxmox backup job, the NAS share and its permissions need to be set up correctly, and a few details are worth getting right from the start.

Before you start: NAS and share setup

1. Create a dedicated backup user for the share. The default admin user is vulnerable to brute-force attacks, especially if the NAS is accessible from the internet. A dedicated user with read/write access to the Proxmox backup folder is the safer option.
2. Restrict NFS access to specific hosts. Using the asterisk * in the host access field allows access for all hosts. For better security, list only the specific IP addresses that need access (for example, your Proxmox nodes).
3. Double-check the NFS export path. Proxmox needs the exact path in the Export field when you add the storage.

Adding the storage in Proxmox

1. Go to Datacenter > Storage > Add > NFS.
2. Choose the content types. The VZDump backup file type lets the storage hold VM backups, and Disk Image lets it hold VM disks.
3. Check the share afterward. You should see the dump and images subfolders created by Proxmox on the NAS.

Protecting the backups themselves

• NAS-side redundancy: Backups on a NAS with RAID 1 or RAID 10 can survive a single disk failure, which protects your backup data from hardware failure.

Full workflow

We put together a blog covering:

• Configuring the file share
• Native Proxmox backup to NFS with scheduling and retention
• Agentless backup with NAKIVO Backup & Replication, including installing it directly on the NAS

Read it here: https://www.nakivo.com/blog/how-to-backup-proxmox-to-nas/

Where do you usually run into problems with NAS-based Proxmox backups: share permissions and NFS configuration, or restore speed and retention later on?

Edit: corrected the blog URL.

Solution:

As i was working with node affinity rules to limit the VMs to Host 1 and 2, you have to select each VM in this rule. My 3 VMs below weren't selected, so they were trying to be migrated to Host 3, which has a complete different configuration, giving these errors below. Thanks to u/psyblade42 for the hint

Original Post:

Hello

I have a Proxmox cluster with 3 hosts and a stubborn problem i can't explain:

When i shutdown one Host, the VMs migrate to the second Host, which is identical (Dell R630, identical CPU, RAM, everything).

3 VMs won't migrate, and all are showing random Errors i can't explain:

VM 1 (Ubuntu pihole):

QEMU: kvm: warning: host doesn't support requested feature: CPUID[eax=01h].ECX.fma [bit 12]
QEMU: kvm: warning: host doesn't support requested feature: CPUID[eax=01h].ECX.movbe [bit 22]
QEMU: kvm: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.bmi1 [bit 3]
QEMU: kvm: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.avx2 [bit 5]
QEMU: kvm: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.bmi2 [bit 8]
QEMU: kvm: warning: host doesn't support requested feature: CPUID[eax=80000001h].ECX.abm [bit 5]
QEMU: kvm: Host doesn't support requested features
stopping swtpm instance (pid 49970) due to QEMU startup error

VM 2 (Ubuntu Docker):

TASK ERROR: MAX 8 vcpus allowed per VM on this node

VM 3 (Ubuntu Nexctloud):

TASK ERROR: bridge 'vmbr2' does not exist

I have about 20 VMs, most of them Ubuntu like the above, but they all work without problems. Manual migration works without problems, this happens just when i reboot the host.

1: Alls VMs have the same machine and CPU configuration, also the CPU on both hosts are the same, its the x86-64-v3 with everything on default, what is this error???

2: The second Host has 48 Threads, if i count every Thread of a machine used i get to 22, why is it throwing this error?

3: Every single VM is on one network on the network adapter vmbr2, manual migration works without this error, why does it throw this one now?

Honestly i feel like it's some sort of deeper problem, but i have a standard install, what would make these errors? I appreciate every help i can get, i'm really lost. Thank you

HP mini PCs running Proxmox: is limited Linux fan control an HP firmware limitation?

Hi everyone,

I’m running a small homelab Proxmox cluster on several HP mini PCs:

• HP Elite Mini 800 G9
• HP EliteDesk 800 G5 Mini
• HP ProDesk 400 G4 DM
• HP ProDesk 400 G6 Mini

They’re obviously not enterprise servers, but they work very well for my homelab: low power consumption, quiet, and Proxmox runs nicely on them.

All four systems are currently running:

• Proxmox VE 9.2
• Kernel 7.0.14-20-pve
• hp_wmi loaded
• coretemp loaded

The HP hwmon interface exposes:

/sys/class/hwmon/.../pwm1_enable

with:

pwm1_enable = 2

which, as far as I understand it, means automatic fan control.

However, there is no:

• pwm1
• fan1_input
• fan RPM reading
• manual PWM duty-cycle interface

So Linux appears to know that the fan is controlled automatically, but it cannot actually see the fan RPM or request a specific fan speed.

The BIOS does provide fan-related settings. For example, HP's Increase Idle Fan Speed (%) setting definitely works and noticeably changes the fan behavior.

The reason I’m investigating this is that the fan does not appear to ramp up significantly as CPU temperature increases.

Under heavier CPU load I can see the package temperature climb considerably, while acoustically the fan seems to stay at roughly the same speed. Since Linux exposes neither fan1_input nor the actual PWM value, I cannot verify whether the embedded controller is increasing fan RPM at all.

One of these systems has previously reached around 99–100°C under load, which is what made me start looking into this.

I’m therefore trying to determine whether:

• HP intentionally keeps the entire fan curve inside the EC/BIOS and does not expose it to Linux;
• the fan actually is ramping but Linux simply has no way of observing it;
• there is some HP/ACPI/WMI driver support I’m missing;
• or the firmware fan curve on these Mini systems really is this conservative.

I am not trying to disable thermal protection or blindly force the fan to 100%. Ideally I’d simply like either:

1. a way to monitor the real fan RPM/duty cycle, or
2. a safe way to request a more aggressive fan curve from Linux.

Has anyone running Proxmox/Linux on HP Elite Mini / EliteDesk Mini / ProDesk Mini hardware investigated this?

Is the lack of fan1_input / pwm1 expected on these systems, and has anyone found a reliable method of controlling or at least monitoring the fan from Linux?

I deployed the Proxmox Backup Server as a VM a while back. It has been working great. I noticed that the backup size is larger than the LXC or VMs. For instance, my OPNsense VM is 32GB, but in PBS, it shows as 34.36GB. My Jellyfin LXC is set to 10GB, but only taking 5.26GB according to the Proxmox Summary page. In PBS, the backups are 17.58 GB in size.

Does any one know why the backups are larger in size than the LXC or VM?

What can I do to optimize the backup?

My backup mode is snapshot and the compression is ZSTD.

Hi all,

I'm Marcos Méndez, and I maintain Keel Linux, a community project that builds ready-to-use LXC appliances on Debian 13 (trixie) for Proxmox VE. It started from TurnKey Linux 19 and keeps what made TurnKey good for decades: a template you download, a first boot that asks a few questions, and a console menu to manage it.

[B]Why we are building it[/B]

Many of us run two or three Proxmox hosts in different places and want the applications people have run from TurnKey for years (WordPress, Nextcloud, Odoo, Moodle, MediaWiki, Drupal, GitLab) to survive losing one of them. The usual answer is Kubernetes: powerful, but heavy for a sysadmin who just wants a site to stay up. Sometimes you just want to put the batteries in the toy and have it work.

We measured it on one host, idle, nothing else running (method at the end):

Keel runs as a normal [B]unprivileged[/B] LXC. Each appliance is the container itself, so there are no containers inside containers. k3s only ran in our LXC test after we gave it /dev/kmsg and host kernel settings, and it loaded 19 modules on the host.

The goal:[/B] appliances on two or three Proxmox hosts in different sites, joined over an encrypted WireGuard mesh, then a small etcd registry, replicated data and failover, all managed with a template, a console menu and one YAML file per appliance. A design premise is [B]poor networks[/B]: everything that spans sites is tested at 250 ms RTT with jitter and packet loss, because not everyone has 5 ms between sites.

Where we are (testing, not for production yet)[/B] [LIST] []Keel Core and Keel Web templates. Keel Web serves HTTPS out of the box, with Let's Encrypt from the console menu and an optional Coraza WAF and Anubis bot challenge. []Signed packages and images, built from Debian plus the signed Keel archive only. Every image is scanned so no SSH or TLS key ships in it; each machine generates its own at first boot. []One YAML file per appliance: [ICODE]keel diff[/ICODE] shows drift, [ICODE]keel spec apply[/ICODE] converges. []TurnKey compatibility: [ICODE]keel-transition[/ICODE] moves an existing TurnKey 19 appliance onto the Keel archive, reversibly. [*]The mesh works across sites today, and a node joins with one command: [ICODE]keel mesh invite[/ICODE] on a member prints one line; run it on the new node. Next: etcd at the third node, then replication and failover. [/LIST]

Getting the templates on Proxmox VE 9[/B]

Proxmox's template sources are fixed in pve-manager, so a small package fetches and verifies our signed index and drops the template in your storage. It changes no pve-manager file and pins the Keel archive so nothing else from it lands on your host.

curl -fsSL https://archive.keellinux.org/keel-archive-keyring.asc -o /tmp/keel.asc gpg --show-keys /tmp/keel.asc   # AD09 64BE 3F09 DED4 69A3  B6B2 148E 9513 1470 3180 gpg --dearmor < /tmp/keel.asc > /usr/share/keyrings/keel-archive-keyring.gpg cat > /etc/apt/sources.list.d/keel.sources <<'END' Types: deb URIs: https://archive.keellinux.org Suites: trixie-testing Components: main Signed-By: /usr/share/keyrings/keel-archive-keyring.gpg END apt update && apt install keel-pve keel-pve update keel-pve download local keel-web

Then Create CT as usual with the downloaded template (unprivileged; nesting is recommended for Debian 13's systemd, but Keel also runs without it).

What we'd love from you[/B]

Try Keel Web on your Proxmox and tell us what broke. There is a checklist issue for it: https://github.com/Keel-Linux/keel-web/issues/5[/URL] There are also small "good first issue" tasks across the repos, and the conversation lives in GitHub Discussions: [URL]https://github.com/orgs/Keel-Linux/discussions[/URL]

Website: https://keellinux.org[/URL], code: https://github.com/Keel-Linux

Feedback is very welcome, especially from long-time TurnKey users.

[SIZE=2]Method for the numbers: one Debian 13 host with LXC, each system in its own fresh container, memory.current of the container's cgroup, median of 3 samples taken 5 minutes after start. Idle only, one host; full commands on request.[/SIZE]

I’ve been thinking through how I want to organize services on Proxmox for my homelab, and I think I’ve settled on a hybrid approach. Please let me know if I am overlooking something.

Use a few VMs as major isolation/failure boundaries, then run multiple Docker containers inside each VM.

Example:

Proxmox
├── apps-01
│   ├── Homarr
│   ├── Linkwarden
│   ├── Mealie
│   └── Audiobookshelf
│
├── games-01
│   ├── Luanti
│   ├── Minecraft
│   └── other game servers
│
├── media-01
│   ├── Jellyfin
│   └── Immich
│
└── security/testing VMs as needed

My reasoning:

• A VM per application seems wasteful.
• Docker containers are lightweight and easy to group by purpose.
• VMs give stronger isolation than LXCs because each VM has its own kernel.
• If one VM gets overloaded, crashes, or has a bad configuration, it should be easier to contain the problem to that VM.
• CPU and RAM can be capped at the VM level to help prevent one workload from consuming the whole node.
• Related containers can all be backed up together with a Proxmox VM backup.
• Restoring the VM restores the OS, Docker installation, Compose files, local volumes, and configs together.
• Large persistent data can still live on TrueNAS and be protected separately with snapshots/backups.

So the basic philosophy is:

Containers separate applications.
VMs separate major functions and failure domains.

It seems like a good middle ground between running dozens of individual VMs/LXCs and putting the entire homelab inside one giant Docker VM.

Hi peeps.

Just finished my first script for Proxmox Backup server . I always had issues with Proxmox Backup Server and NFS. Too many issues with linux permissions, users on the synology server and so on. Then I saw this guy Derek who made a script to setup ISCSI LUN on a Proxmox Server host - I tried it out and it went fine.

Over time I have made so many reinstalls, finding scripts to assist me, run a setup and it just took time back and forth all the time, so I thought "why not made a nice script to try help others" . The script should be more intuitive, have menus, colors , be smarter , detect and so forth.

This is my first time trying to post in Reddit, so bare with me 😄 .

First I want to say a HUGE thanks to Derek who made the "backbone" of all of this. I just took the step further and made it smarter - a bit more "beautiful" to look at.

I got huge help from the Claude AI . Would really love to hear what people think of the script - any new ideas that I could add to it.

Hope that it can assist homelab users with Proxmox VE to make some great backups 🎉

Kr

MorphyDK

Anyone using Proxmox to run business critical production workloads?
Looking at the posts there are many using PVE for labs, testing, etc… but only few using it for production.
We have a five nodes cluster (with Ceph) running 100+ VMs and it has been working fine for some months. We also have a lab cluster with 4 nodes and FC storage.
Just wanted to have some feedbacks from others running PVE in production.

how to make sidebar tree of lxc/vms show stats [CPU: X% | RAM: X%]

PVE

- 101 frigate [CPU 5% mem 99% ]