I'm starting to play with a 3-node cluster (installed from the Proxmox ISO) to evaluate it as a potential VMware replacement (like half of the world, it seems...)
Since the purpose of the cluster so far is just to test the installation process and get a feel for the UI, I created 3 VMs on our existing VMware stack. Each of the VMs I created with a 16GB virtual drive as I plan to host the VMs and ISO storage on a separate iSCSI/NFS NAS to be shared by the cluster.
Proxmox installed fine and without complaint on the 16GB drive. The first hint of trouble was when I tried to upload a 5GB Windows Server 2025 ISO; the upload hung part-way through, silently. I didn't wait longer than 5 minutes to see if it would elegantly time out or not.
That's when I discovered the documentation mentions that uploads are first received and staged on the host locally in /var/tmp before being moved to the final destination, so even though there's 300GB free in the NFS export, the 3.1GB free in /var/tmp is a limiting factor. Sure enough, the root filesystem was 100% full. Luckily I already had an SSH session open to the host so I could clear it out.
Ok, no problem; the point of this whole exercise is to learn things like this. I can just bump up the size of the virtual disks for the hosts and start over... but it got me thinking: on other systems I've worked on, there have been both official and sometimes less-official policies about creating different mountpoints on their own devices/logical volumes so that a filesystem filling up doesn't grind the whole system to a halt. The usual suspects that come to mind are: /home, /tmp, /var/log, (/var/log/audit on RHEL).
What are your thoughts on the best way to make the filesystem as resilient to these sorts of problems? I would love to have a way to customize the disk layout more than the few options presented by the installer; should I try to go the "install Debian or Ubuntu then install the packages necessary for Proxmox" route?
Since the purpose of the cluster so far is just to test the installation process and get a feel for the UI, I created 3 VMs on our existing VMware stack. Each of the VMs I created with a 16GB virtual drive as I plan to host the VMs and ISO storage on a separate iSCSI/NFS NAS to be shared by the cluster.
Proxmox installed fine and without complaint on the 16GB drive. The first hint of trouble was when I tried to upload a 5GB Windows Server 2025 ISO; the upload hung part-way through, silently. I didn't wait longer than 5 minutes to see if it would elegantly time out or not.
That's when I discovered the documentation mentions that uploads are first received and staged on the host locally in /var/tmp before being moved to the final destination, so even though there's 300GB free in the NFS export, the 3.1GB free in /var/tmp is a limiting factor. Sure enough, the root filesystem was 100% full. Luckily I already had an SSH session open to the host so I could clear it out.
Ok, no problem; the point of this whole exercise is to learn things like this. I can just bump up the size of the virtual disks for the hosts and start over... but it got me thinking: on other systems I've worked on, there have been both official and sometimes less-official policies about creating different mountpoints on their own devices/logical volumes so that a filesystem filling up doesn't grind the whole system to a halt. The usual suspects that come to mind are: /home, /tmp, /var/log, (/var/log/audit on RHEL).
What are your thoughts on the best way to make the filesystem as resilient to these sorts of problems? I would love to have a way to customize the disk layout more than the few options presented by the installer; should I try to go the "install Debian or Ubuntu then install the packages necessary for Proxmox" route?
