No worries. And don’t misunderstand: I think proxmox is great, I’ve simply moved on to a different way of doing thing.

I’ve moved to all containers and I’m gradually automating everything. The metaphor for orchestration and provisioning is much clearer in incus than it was in lxd, and makes way more sense than proxmox.

Proxmox is fine, I’ve used it for going on 8 years now, I’m still using it, in fact. But it’s geared toward a “safe” view of abstraction that makes lxc containers seem like virtual machines, and they absolutely aren’t, they are much, much more flexible and powerful than vms.

There are also really annoying deficiencies in proxmox that I’ve taken for granted for a long time as well:

• horrible builtin resource usage metrics. And I’m happy to run my influxdb/grafana stack to monitor, but users should be able to access those metrics locally and natively, especially if they’re going to be exported by the default metrics export anyway.
• weird hangovers from early proxmox versions on io delay. Proxmox is still making users go chase down iostat rabbit holes to figure out why io_wait and “io delay” are not the same metric, and why the root cause is almost always disk, yet proxmox shows the io_wait stat as if it could be “anything”
• integration of pass through devices is a solved problem, even for lxc, yet the bulk of questions for noobs is about just that. Pass through is solved for so many platforms, why proxmox just doesn’t have that as a GUI option for lxc is baffling.
• no install choices for zfs on root on single disk (why???)
• etc

Ultimately, I have more flexibility with a vanilla bookworm install with incus.

Migrating from proxmox to incus, continued.

• got a manually-built wireguard instance rolling and tested, it’s now “production”
• setting up and testing backups now
• going to export some NFS and iscsi to host video files to test playback over the network from jellyfin
• building ansible playbooks to rebuild instances
• looking into ansible to add system monitoring, should be easy enough

Lots of fun, actually!

dd if=/dev/null of=<mount-point>/test.file bs=1G count=10 status=progress

/dev/null tests from dd are not an accurate indicator of performance unless you only have one disk in your pool. fio is a much more accurate tool for zfs pool testing.

Eh… Maybe for learning.

Although they technically support vt-d, performance on 13-year-old machines will be pretty abysmal by today’s standards.

Lots of variables here, we would need to pare them down:

• architecture of zfs pool? This can be done well or very poorly, zfs gives you a lot of rope, if you know what I mean.
• memory?
• have you tuned samba ?
• are you trying to do anything fancy like jumbo frames ?
• what networking equipment lies between the two?
• do you have the correct and correctly configured 2.5gb driver for linux ? Intel 2.5 NICs had some issues for a while.
• what does the windows net hardware look like?

In troubleshooting transfer speeds , there are solo many variables, as you can see.

Start with the network and reduce variables until you have a likely source of the problem.

Love that for you.

However, that is not everyone’s experience and doesn’t really answer op’s question.