I think that's definitively an important topic. The PDM is certainly a "lucrative" target due to being a single point of entry to one's whole Proxmox infrastructure, that's actually a big reason for it's a pull based design, i.e., the PDM can be...
We're very excited to present the first stable release of our new Proxmox Datacenter Manager!
Proxmox Datacenter Manager is an open-source, centralized management solution to oversee and manage multiple, independent Proxmox-based environments...
After wiping the 4th node, reinstalling, and then adding it to the cluster with the transport: udpu setting already in place, it worked great. No issues at all and now my 4 node cluster is working. So it turns out the issue was the switch not...
I was able to set Transport: udpu but I also needed to set crypto_cipher and crypto_hash to none in order for corosync to start back up. By making these changes to the corosync.conf file, I was able to get the 3 nodes connected. I'm currently...
A few stray checksum errors right after replacing a bad cable can be normal — ZFS is still verifying and repairing blocks that were previously affected.
Run another zpool scrub and monitor if the CKSUM count stays stable or resets to zero.
If...
Yeah — that behavior pretty much screams Corosync identity or network conflict, not hardware.
When two nodes work fine but adding a third (or fourth) causes the whole cluster to fall apart, it’s usually one of these:
1. Duplicate nodeid or...
Thanks a lot. I have switched to another usb port and turned off Intel Dynamic Power Technology, also turned on Power on usb on S4/S5 state and it worked. Dunnno which one helped but one of this for sure. Thanks a lot readyspace!!
@verishare : just note that ZFS adds a lot of capabilities/features *I* don't want to live without: https://forum.proxmox.com/threads/fabu-this-is-just-a-small-setup-with-limited-resources-and-only-a-few-disks-should-i-use-zfs-at-all.160037/
Of...
Yep, that’s actually normal — it’s how unprivileged LXC containers isolate files. The container’s root is mapped to a high UID range on the host (like 101000+), so files written from inside can look “hidden” or owned by unknown users outside...
Looks like the issue is caused by volatile EFI/TPM devices — OVMF loses the TPM state after save, so Secure Boot and attestation can’t complete. Please try recreating both efidisk0 and tpmstate0 on a persistent storage pool (not volatile:)...
And forgot to reply I got it working a few minutes after this post.
TY so much @readyspace couldn't have done it without you, for real! onto the next problem now :D