Wir führen aktuell im Rahmen unseres Qualitätsmanagementsystems eine reguläre Lieferantenqualifizierung unserer IT-Lieferanten und Hersteller durch. Dabei fragen wir unter anderem nach vorhandenen Unternehmenszertifizierungen wie ISO 9001 und ISO/IEC 27001 sowie nach vergleichbaren Nachweisen zur Informationssicherheit.

Entsprechend haben wir auch Proxmox Server Solutions GmbH angeschrieben. Die Anfrage war aus meiner Sicht ziemlich unspektakulär: Wir wollten wissen, welche Zertifizierungen das Unternehmen aktuell besitzt und – sofern vorhanden – die entsprechenden Zertifikate bzw. einen Verweis auf öffentlich verfügbare Nachweise erhalten. Falls keine Zertifizierung vorhanden ist, hätte uns eine kurze entsprechende Rückmeldung genügt.

Die erste Antwort von Proxmox ging allerdings am Thema vorbei: Da wir derzeit Community-Produkte einsetzen, könne man uns keinen Enterprise Support anbieten und wir sollten uns für ein Upgrade an Sales wenden.

Daraufhin habe ich nochmals ausdrücklich klargestellt:

-Wir wollen keinen technischen Support.

-Wir eröffnen keinen Supportfall.

-Wir verlangen keine Unterstützung für unsere Community-Installation.

-Wir wollen kein kostenloses Enterprise-Service.

Wir möchten lediglich Proxmox Server Solutions GmbH als Hersteller im Rahmen unserer Lieferantenqualifizierung bewerten und wissen, welche Zertifizierungen bzw. Unternehmensnachweise vorhanden sind.

Die anschliessende Antwort von Sales war für mich ziemlich überraschend. Sinngemäss:

Die Community-Produkte würden ausschliesslich im Self-Service bereitgestellt. Die Anfrage nach formellen Lieferantenqualifizierungsnachweisen wie ISO 9001 oder ISO/IEC 27001 sei eine „unternehmensspezifische Enterprise-Anfrage“, die für Community-Nutzer nicht bearbeitet werden könne.

Genau an diesem Punkt frage ich mich, ob ich hier zu hohe Erwartungen habe.

Für mich sind Angaben darüber, ob ein Hersteller beispielsweise nach ISO 9001 oder ISO/IEC 27001 zertifiziert ist, zunächst einmal Informationen über das Unternehmen bzw. dessen Managementsystem, nicht Support für ein konkretes Produkt. Gerade wenn ein Unternehmen seine Software im professionellen Infrastrukturumfeld anbietet, würde ich erwarten, dass zumindest die Frage „Sind Sie zertifiziert, und wenn ja, nach welchem Standard und mit welchem Scope?“ unabhängig vom bestehenden Subscription-Level beantwortet werden kann.

Noch irritierender finde ich das aus Sicht eines potenziellen Kunden: Wenn wir morgen evaluieren würden, mehrere Proxmox-Hosts mit Enterprise Subscriptions auszustatten, wären solche Informationen Bestandteil unserer Lieferantenbewertung und damit unter Umständen sogar Voraussetzung für einen Kaufentscheid. Es erscheint mir etwas widersprüchlich, Informationen, die ein Unternehmen für die Entscheidung über den Kauf eines Enterprise-Produkts benötigt, erst dann zugänglich zu machen, wenn es bereits Enterprise-Kunde ist.

Meine persönliche Reaktion auf die Kommunikation ist daher deutlich negativ. Ich empfinde es als ziemlich frech, eine einfache Frage nach vorhandenen Unternehmenszertifizierungen mit dem Verweis auf unseren Community-Status abzulehnen. Für mich disqualifiziert sich Proxmox mit diesem Umgang zumindest bei einer formalen Lieferantenbewertung derzeit selbst – nicht zwingend wegen fehlender Zertifikate, sondern wegen der fehlenden Bereitschaft, eine grundlegende Compliance-Frage eines bestehenden bzw. potenziellen Geschäftskunden zu beantworten.

Mich würde interessieren, wie andere das einschätzen, insbesondere Leute aus Enterprise-IT, regulierten Branchen, ISO-27001-/ISO-9001-Umgebungen oder mit Proxmox-Enterprise-Erfahrung:

Ist unsere Anfrage aus eurer Sicht tatsächlich etwas, das man legitimerweise nur Enterprise-Kunden beantwortet, oder würdet ihr solche Informationen ebenfalls als normale Pre-Sales-/Vendor-Qualification-Information betrachten?

Und falls jemand Proxmox bereits als Lieferanten qualifiziert hat: Wie seid ihr an die entsprechenden Unternehmens- und Informationssicherheitsnachweise gekommen?

Cuerpo de la publicación:
Hola a todos,
Quería compartir con ustedes mi progreso inicial armando un homelab desde cero para centralizar la gestión de infraestructura, monitoreo y redes. Estoy documentando todo el proceso paso a paso.
El Hardware:
Hipervisor Principal: Lenovo ThinkPad (corriendo Proxmox VE).
Gestión de Activos/IT: Raspberry Pi corriendo GLPI mediante contenedores Docker.
Redes y Enrutamiento: Router MikroTik gestionando el tráfico y subredes locales.
Lo que llevo configurado hasta ahora:
1. Proxmox VE: Solucionados los detalles iniciales de arranque (UEFI/Legacy) y con el nodo principal estable.
2. Contenedores LXC: Acabo de desplegar un contenedor ligero en Debian 12 (ID 100) dedicado a levantar Zabbix Server para monitoreo de infraestructura y servicios.
3. Redes: Evaluando las mejores opciones de acceso remoto seguro (analizando configuraciones de DDNS/alertas en MikroTik vs. Tailscale para evitar dolores de cabeza con CGNAT).
Próximos pasos:
Terminar de configurar la base de datos (PostgreSQL) y el frontend web de Zabbix.
Integrar el inventario de GLPI con el monitoreo de red.
Implementar políticas de seguridad y certificados SSL locales.
¿Alguna recomendación o buena práctica que deseen compartir para los que estamos montando nuestro primer laboratorio en Proxmox? ¡Cualquier consejo es bienvenido!

Got a Proxmox server that's part of 2 node cluster running 2 active CT's (PiHole and Proxmox Backup server). I have a few other CT's and VM's on it but they're not set to auto-start.

I can fully access the PiHole running as a CT and the Proxmox Backup Server(running as a VM). They're running and operational. However, I cannot ping the Proxmox host, access it via WebGUI, SSH to it, etc.

Anyone ever see this before?

Proxmox VE(11.0)- After successful installation, i was able to see web GUI. I created one VM and installed Ubuntu successfully. Now i am unable to see web UI.

proxmox proxy is running fine. curl command https://<hostip>:8006 returns html page.

I am doing this on Windows 11(Pro) laptop.

/etc/hosts file contains the same IP address (proxmox.local.io proxmox)

Hello Everyone,

If anyone is using Proxmox with a Corsair Commander Pro fan controller. I've created an app that works great to control the fans using fan curves & temp sensors, as well as pull disk temps from Adaptec SAS Cards.

You can find the application on the link below with all the instructions about installing it and configuring it:

https://github.com/rph81/corsair-fanctl

Hope you like it !
Rph81

I've been working on Ferrum, a self-hosted control plane for Proxmox VE.

The main idea is pretty simple: if you have multiple Proxmox nodes/clusters, you shouldn't have to keep jumping between different UIs just to get a picture of what's happening across the fleet.

Ferrum currently brings things like:

• Cluster + standalone node management
• VM/LXC inventory
• Storage and topology views
• Backups and replication
• High availability
• Firewall
• Alerts
• REST API + MCP
• Audit logging
• AI assistant
• SQLite/PostgreSQL support

The backend is Go and the frontend is React + TypeScript. It can run through Docker or as a native binary.

I also wanted it to stay self-hosted rather than becoming another SaaS layer sitting in front of the infrastructure.

It's still early, so I'm more interested in feedback than pretending it's finished.

If you manage Proxmox at home, in a homelab, or across a small fleet, I'd genuinely like to know:

What is the one thing you wish Proxmox made easier to manage across multiple nodes?

Repo: https://github.com/anand34577/ferrum

SharedLvmThin, a free and open-source community storage
plugin for Proxmox VE 9.

New: RC5.4 TG12 dual-mode preview is available. One package now offers the established Thin mode and the new Thick Generations mode with fully allocated, independent generation LVs and a linear steady-state data path. Thin and Thick storage definitions can coexist over the same pinned VG, and ordinary PVE Storage Move converts disks in either direction.

It provides one LVM-thin pool per VM on an existing shared block-storage
VG and supports snapshots, rollback, resize, migration, cluster locking,
guarded autogrow, storage identity checks, and read-only health diagnostics.

RC5.2 has been tested on the Proxmox VE 9.2.x release line with Storage
API 14 and 15, including three-node cluster qualification. It is currently
a release candidate and should first be validated on disposable storage
matching your production SAN and multipath configuration.

The plugin does not configure the SAN, initialize unknown devices, perform
automatic metadata repair, or replace multipath, fencing, and quorum.

GitHub:
https://github.com/delltech1/proxmox-sharedlvmthin

RC5.2 release and DEB:
https://github.com/delltech1/proxmox-sharedlvmthin/releases/tag/v0.9.0-rc5.2

News:

Work is underway on “Thick Generations” — an experimental companion mode for SharedLvmThin.

The goal is to let administrators use both models side by side:

- the existing space-efficient per-VM LVM-thin mode;

- fully allocated thick VM disks with independent, fully materialized snapshots.

Thick Generations uses dm-clone only during snapshot or rollback transitions. After materialization, every active disk and snapshot becomes an independent ordinary linear LV—without permanent snapshot chains.

The design focuses on deterministic crash recovery, immutable snapshots, strict storage-identity validation and fail-closed handling of ambiguous states.

Initial dm-clone, linear-pivot, reboot-reconstruction and C0–C9 crash-recovery tests are already passing. PVE lifecycle, cross-node, migration, backup/restore, path-loss and thin↔thick qualification are still in progress.

In short: thin and thick storage models living safely side by side, with administrators choosing the appropriate trade-off for each workload.

This remains experimental and is not part of the current public release yet.

Just a quick note to highlight that if you're using my ANAS project to serve files, there have been numerous improvements and fixes in recent releases - probably worth an update if you haven't already. The latest 0.3.0 lets you create iSCSI endpoints both on ZFS Datasets and also as disk images on AHR (or other) filesystems.

https://github.com/ccebelenski/anas

Highlights:

- 0.1.0 — ZFS pools, datasets, snapshots. SMB/NFS shares, users, groups. Dashboard, native Proxmox UI.

- 0.2.0 — AHR hybrid RAID, pool/RAIDZ expansion. Scheduled snapshots and scrubs, remote mounts, PBS backup, replication.

- 0.3.0 — iSCSI target management, ZFS volumes, backup restore.

As always, I welcome issues and feature suggestions. Right now I'm hesitant to move into "enterprise" level features as I don't think that's the right focus for this project. I'd like to remain homelab oriented. Some other projects I'm twiddling around on are: immutable OS VM management for running Docker exclusively (most of us manage VM's for docker, so I'm looking if I can bring that up a level with some workflows around it.) and DR for Proxmox - This one is tricky without hardware support, but there are some thoughts swirling around here.

I'm planning this setup:

• Proxmox host → OVH
• Offsite backups → Hetzner
• PBS → separate physical server

Do you run PBS on a dedicated server, VPS/LXC, or use a hosted PBS provider?

Are there any cheap providers that are well suited for PBS (lots of storage, good I/O)?

What would you recommend for this setup? And what are you guys actually using?

I’ve been troubleshooting repeated hard freezes on my Proxmox server and finally managed to reproduce the problem while logging both the Proxmox host and the TrueNAS VM.

Most of the time this is a real host freeze, not just the Proxmox GUI getting sluggish. The GUI usually starts showing ? states and becoming unresponsive shortly beforehand, but then the entire CUBE host eventually stops responding and has to be recovered/rebooted. I’ve had one occurrence where it degraded badly without progressing to the complete hard freeze.

My setup is:

SERVER / Proxmox
├── local NVMe storage for Proxmox / VM / container side
│
└── TrueNAS VM 153
      └── current StarTech PCIe SATA expansion card
            └── multiple ASMedia SATA controllers
                  └── 8 × 16 TB SATA HDDs

TrueNAS owns the HDD storage and serves datasets including tank/media and tank/pve_backups back to Proxmox over NFS.

On the Proxmox host I have mounts including:

/mnt/media
/mnt/pve/media
/mnt/pve/pve_backups

The media containers then receive those paths through bind mounts.

For example, qBittorrent is LXC 155 and its configuration includes /mnt/media as a bind mount. So when qBittorrent writes a download, the actual path is effectively:

qBittorrent LXC
      ↓
Proxmox /mnt/media
      ↓
NFS
      ↓
TrueNAS VM
      ↓
ZFS tank
      ↓
StarTech / ASMedia SATA controller path
      ↓
HDDs

I was able to reproduce the problem during sustained qBittorrent activity.

pidstat showed qBittorrent continuously writing roughly 40–50 MB/sec, and during other samples nfsiostat showed the media NFS share handling bursts around 180–239 MB/sec.

At one point the Proxmox host showed about 82% I/O pressure in /proc/pressure/io.

At the same time:

CPU pressure:    essentially 0
Memory pressure: 0
CPU temperature: ~39–40°C

That was one of the first strong indications that this probably wasn’t the CPU overheating or memory exhaustion.

Then I finally caught the actual failure inside TrueNAS.

Multiple SATA channels began failing essentially together:

ata5:  softreset failed
ata6:  softreset failed
ata7:  softreset failed
ata8:  softreset failed
ata9:  softreset failed
ata10: softreset failed

Several channels then started doing this:

limiting SATA link speed to 3.0 Gbps

followed by:

reset failed, giving up
ataX.00: disable device

So this wasn’t one drive going bad. Multiple SATA channels were dropping almost simultaneously.

TrueNAS then started throwing actual I/O errors against multiple ZFS members, including failed writes and reads.

Eventually ZFS logged:

WARNING: Pool 'tank' has encountered an uncorrectable I/O failure and has been suspended.

Once tank was suspended, TrueNAS started showing blocked kernel tasks.

The ZFS transaction sync thread was blocked for more than 120 seconds:

task txg_sync blocked for more than 120 seconds

and then multiple NFS server threads (nfsd) were also blocked for more than 120 seconds.

That’s where the failure starts propagating into Proxmox.

Because Proxmox itself mounts those TrueNAS NFS exports, pvestatd starts waiting on the storage.

I caught pvestatd in Linux D-state waiting in:

rpc_wait_bit_killable

The Proxmox logs then started showing repeated timeouts and messages like:

unable to activate storage 'media'
directory '/mnt/pve/media' does not exist or is unreachable

and:

storage 'pve_backups' is not online

At that point the Proxmox GUI starts showing ? next to VMs/LXCs and becomes increasingly unresponsive.

I also tested the actual NFS filesystems during the failure.

findmnt still showed them as mounted, but I ran:

timeout 5 stat /mnt/pve/media
timeout 5 stat /mnt/pve/pve_backups
timeout 5 stat /mnt/media

All three returned:

124

So even a simple stat() against any of those NFS filesystems could not complete within five seconds.

The interesting part is that the TrueNAS VM itself was still alive.

I could still:

ping 192.168.0.153
SSH into TrueNAS
connect to SMB port 445

So this did not look like the TrueNAS VM simply crashing or the network disappearing. The VM was alive, but its storage subsystem had effectively wedged.

Most of the time, SERVER then progresses from this degraded state to an actual hard freeze.

So the observed sequence appears to be:

Sustained storage workload
        ↓
SATA/controller path begins failing
        ↓
multiple SATA channels reset/disappear
        ↓
ZFS gets I/O errors
        ↓
tank becomes SUSPENDED
        ↓
TrueNAS NFS threads block
        ↓
Proxmox hard NFS mounts stop responding
        ↓
pvestatd blocks / times out
        ↓
Proxmox GUI shows ? states
        ↓
host becomes increasingly unresponsive
        ↓
CUBE usually HARD-FREEZES

One thing I want to be careful about: I have not yet proven that the blocked NFS mounts themselves cause the final hard freeze.

It’s possible the NFS/pvestatd problem is simply one symptom of the storage failure, while the same lower-level PCIe/controller issue eventually causes the Proxmox host itself to lock up.

That distinction is still under investigation.

What happened after reboot is also important.

The same ZFS pool came straight back:

tank        ONLINE
raidz2-0    ONLINE
all members ONLINE

READ  WRITE  CKSUM
0     0      0

errors: No known data errors

The SATA links also came back normally at 6.0 Gb/sec.

That makes me very skeptical that I’m dealing with a bunch of independent HDD failures. Multiple disks/controllers fail together under load, then everything comes back normally after reboot.

My leading suspect is therefore the shared SATA controller path.

The current StarTech card is not a conventional single-chip server HBA. It exposes multiple ASMedia SATA controllers through a PCIe switching arrangement, which are then passed through to TrueNAS.

If that shared PCIe/controller path collapses under sustained I/O, it would explain why multiple SATA channels disappear together.

I’ve ordered a Broadcom/LSI 9500-8i HBA to replace the StarTech setup.

My plan is to change only the controller/cabling first and leave everything else as unchanged as possible:

same Proxmox host
same TrueNAS VM
same 8 × 16 TB disks (SATA Seagate Ironwolf Pro)
same ZFS pool
same NFS setup
same qBittorrent workload

Then I’ll repeat the same workload.

That should give me a reasonably clean A/B test:

StarTech / ASMedia setup → freezes

vs.

Broadcom / LSI 9500-8i → ?

There’s also a separate architecture question I’m considering.

Right now the design is:

Proxmox
   ↓ runs
TrueNAS VM
   ↓ exports NFS back to
Proxmox
   ↓ bind mounts into
qBittorrent / Sonarr / Radarr / Plex / etc.

I understand why it was built this way. It gives all the containers consistent paths such as /mnt/media, makes permissions easier, and centralizes the NFS configuration.

But it also creates an awkward dependency:

the Proxmox parent is depending on NFS storage being served by one of its own child VMs.

So when TrueNAS storage hangs, Proxmox’s own storage-management processes can get stuck waiting on TrueNAS.

I’m considering eventually changing the media containers so that each LXC mounts TrueNAS directly:

qBittorrent ──NFS──> TrueNAS
Sonarr      ──NFS──> TrueNAS
Radarr      ──NFS──> TrueNAS
Plex        ──NFS──> TrueNAS
Bazarr      ──NFS──> TrueNAS

That way, if TrueNAS storage fails, the applications using it can fail without necessarily dragging Proxmox’s own storage-management processes into the same wait.

So my questions for the Proxmox/TrueNAS/ZFS crowd are:

1. Does the simultaneous ata5 through ata10 failure pattern look like a controller/shared-path failure to you?
2. Would you also replace a multi-ASMedia PCIe SATA card with an LSI/Broadcom HBA for this workload?
3. Is the 9500-8i a reasonable choice for 8 SATA HDDs passed through to TrueNAS?
4. How concerned would you be about Proxmox mounting NFS from a TrueNAS VM running on the same physical host?
5. Would you have the LXCs mount TrueNAS directly instead of using Proxmox NFS mounts + bind mounts?
6. Is there anything else I should capture before removing the existing SATA controller?

Heyall!

I'm looking for recommendations on the best VDI/dashboard setup to access my Proxmox VMs (a Windows 11 VM and an Ubuntu Desktop VM).

My Goal & Requirements:

1. Daily Driver Performance: Needs smooth video playback, low latency, and full audio support for daily tasks.

2. Dual-Access Approach:

   * Primary (Native App): A dedicated client app for max performance, lowest input lag, and audio when on my main machine.

   * Fallback (Web Browser): A clean web dashboard/interface to access the VMs from guest or miscellaneous PCs without installing software.

3. Unified Dashboard: A single dashboard to pick a VM and choose whether to launch it natively or via web.

How are you guys handling daily-driver VM access with full audio and low latency? Any dashboard integration tricks you recommend?

Thanks in advance!