Would be nice to share our homelabs, might interest new users:

I'll begin:

1 pool with 2x Protectli VP6670 (64GB and 96GB RAM) (2x 10G bonded for VM network, 1x 2,5G for management network).
Both with Internal 1TB SSD as local ext4 SR, 1TB nvme for OS and SR.
NFS-SR on QNAP TBS-h574TX (10G connection) and QNAP TVS-h1288X for backups (10G connection, NFS).

2 switches:
Mikrotik CRS312-4C+8XG for 10G network
Mikrotik CRS328-24P-4S for 1G and POE

Netgate 8200 pfsense for firewall
ODROID-N2+ for HomeAssistant, Uptime Kuma moitoring

@gduperrey 1 HomeLab-Pool (via cli: yum update and reboot), 3 Business-Pools (via RPU), total 7 servers updated without issues.

@florent Updated.

Did a backup job: OK
Did the mirror job: OK

Great!

@Prilly Man you need to calm down. Your post(s) with shit here shit there has bad "tone".

I don't think this will get a lot of help/attention from Vates.

And they are more than helpful, even without payed support.

@olivierlambert The units are top notch!

I still have 1 FW6C 2 FW6E's (had them running proxmox before, xcp-ng after that but switched to the VP6670 because of 10G network).

NEVER ever had one single issue with them. Also bios updates are easy.

@bleader All pools updated via RPU without issues.

@bleader 2 production polls updated via RPU without issues.

@gskger XCP-NG on ARM/Ampere will be huge!!!!
The running cost of those machines is a big win over x86. Power is expensive in Europe. Hetzner is in full swing on that front.
And not everything runs in Windows I guess it's only the smaller fraction of all the VM's in the world.

Just ordered my 2nd VP6670 for my main pool. You can now select it with xcp-ng preinstalled

@florent Pls advise here when it's fixed, so that I can retry. I will hold back until then.
Backups are essential.

@Greg_E From 6 Windows Server 2022 VM's this happened on 3 here.

@peo Nope. Remote has no issue whatsoever.
The issue is with the backup code because this is what changed. Worked before for many months without issues.
And it's still working at the office on stable XOA.

@peo I don't have this setting set. The errors appear inconsistently.

@peo @olivierlambert

I get the same error now. This started with the new backup code, has been working the whole time before.
Latest XO, remote nfs storage (reachable over internet via IP).

Backup jobs are delta.

Same jobs to local/LAN nfs storage works without issues. It's only the remote nfs gives problems (sometimes works).

@tjkreidl True. VM's that can't be shutdown you'll have to shutdown manually.
I find that this takes a lot less time than migrating the VM's around. But if they need to be running then there's no other way ¯_(ツ)_/¯

@DustinB Actually you don't have to migrate VM's if you're fine with them shutting down.
Just update the missing slaves by "yum update" and reboot them. VM's will be shut down and restarted (following their start settings in advanced)...

@olivierlambert Nope, that was not on my mind! I KNOW you are taking care of this.

I just wanted to add my practical experience to someone asking theoretically if there is an issue. And for us there is one during backups, not during normal operations.

Backups taking 2-3 times longer on EPYC than on Intel might be an issue for someone thinking on deploying on "fairly large multi-datacenter environment".

No harm meant and no finger was pointed. Just a honest my 2 cents.

@olivierlambert OK, won't comment any more... You can delete my comment at your leisure.

@olivierlambert Just added my pratical experience, which might interest. AND that was not a shot AGAINST xcpng. FAR FROM IT.

Switch, do it, tomorrow! Just don't choose EPYC.

@olivierlambert Biggest issue is when it presents itself during backup, which are SLOW compared to Intel.

We've been at that since the beginning of our Vmware-XCPNG switch. Unfortunately (in a hindsight we chose AMD EPYC. Huge mistake!!)