[SOLVED] [ZFS] How much space does Proxmox actually need on its boot pool to function correctly?

Sep 1, 2022
266
50
33
40
Hello,

I'm installing Proxmox on a new production node soon in my home office. The hardware is powerful enough for my needs, but there's only one NVME slot, so the boot NVME will have to be a single-disk ZFS stripe. Not ideal, but sadly my effort of will has not manifested additional PCIe lanes and a second NVME slot on this board.

At the very minimum, I need to install Proxmox on an NVME and have enough room left over for a TrueNAS VM. The TrueNAS VM will be getting real physical HDDs and a pair of large NVME via PCIe passthrough. This VM will come up before anything else and act as shared storage for my cluster. So, I need the OS disk to be big enough to keep Proxmox itself happy and also support a TrueNAS OS-only virtual disk.

How much space do I need for that?
I've got a 128 GB PCIe 3.0x4 NVME (consumer grade, but nice, and also never, ever used, so it has plenty of endurance)* and a 480 GiB Firecuda PCIe 3.0x4 NVME (much higher endurance, and known to work well as I've had it in service elsewhere for years).

My hesitation with the FireCuda is that I have two of them, and I'd rather keep them both free for setting up a mirror pool again some day. It's nice to have a pair of matched high quality drives available.

Either way, I'll be getting a syslog server set up, so I won't be logging directly on to the OS drive. Between that and only having a TrueNAS VM on it (which itself doesn't write to its boot disk that much, by my understanding), writes to the VM should be minimal.

Here's the info on the 128 GB (119.2 GiB?) disk:

Code:
~% sudo lspci -nn -vvvv -s 57:00
[sudo] password for johntdavis:
57:00.0 Non-Volatile memory controller [0108]: Phison Electronics Corporation PS5013 E13 NVMe Controller [1987:5013] (rev 01) (prog-if 02 [NVM Express])
        Subsystem: Phison Electronics Corporation PS5013-E13 PCIe3 NVMe Controller (DRAM-less) [1987:5013]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 18
        IOMMU group: 18
        Region 0: Memory at 85400000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [80] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 10W
                DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
                        MaxPayload 256 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
                LnkCap: Port #1, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L1 unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 8GT/s, Width x1 (downgraded)
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
               ...
        Kernel driver in use: nvme
        Kernel modules: nvme

Thanks for any advice. :)
 
How much space do I need for that?

While I can not give a definitive answer I can tell you that my PVE's (all ZFS based) use less than 12 GB for "rpool/ROOT". But this is part of a much larger pool.

If I had to establish a hard border I would opt for 32 GB or so, just for the OS, without VMs. Without further optimization this filesystem needs to have space for temporary files, e.g. for uploading an .iso - and these tend to be multi-Gigabyte. I am not sure if there are other mechanism using temporary storage capacity.

Interestingly enough: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_system_requirements doesn't give us a hint...

---

Once again back to your statement "At the very minimum, I need to install Proxmox on an NVME and have enough room left over for a TrueNAS VM. " Wouldn't that VM live in a virtual disk? If that is the case PVE/local-zfs should get the complete 128GB. I am sure the space is enough for multiple virtual TrueNAS's, without the data-disks.

One last hint, probably you know that: TrueNAS should get a Controller passed-through.
 
I think the system requirements don't really give much detail about this because, like you said, there's no a right answer. You can theoretically run Proxmox on a ZimaBoard. It won't run well for anything but testing with very small LXC or VMs, but still.

That said, I am curious what its minimum install footprint is and how much free space it needs before it starts to have problems. I think the right answer is (1) whatever a Debian install without the GUI subsystem looks like, combined with (2) however much space the Proxmox install itself takes up, plus (3) some amount of free space to avoid choking on itself. It's that last one that I'm not sure about, officially.

I just checked my install:
Code:
rpool/ROOT                                 798G  5.20G        0B     96K             0B      5.20G
rpool/ROOT/pve-1                           798G  5.20G        0B   5.20G             0B         0B

I've added a few CLI utilities and installed the libraries to do SR-IOV iGPU passthrough and VirGL, but I think you're right that 32 GiB should definitely be enough.

I hadn't thought about the temporary storage for ISOs and templates, but my permanent storage for those is on a NAS. As long as it's actually deleting ISOs and LXC templates, that should be fine. Thanks for catching that.

Once again back to your statement "At the very minimum, I need to install Proxmox on an NVME and have enough room left over for a TrueNAS VM. " Wouldn't that VM live in a virtual disk? If that is the case PVE/local-zfs should get the complete 128GB. I am sure the space is enough for multiple virtual TrueNAS's, without the data-disks.

Right. :) My concern was that after I installed PVE, and then gave TrueNAS 32 or 64 GiB or whatever, there wouldn't be enough left over for the Proxmox rpool, but I didn't realize how small it is.

The 128 GiB disk should work just fine.
 
  • Like
Reactions: UdoB
size of disk is not important. size of boot partition (assuming you havent moved /var or /home or the other usual suspects to other partitions) should be no less then 16GB. this isnt a hard number- I've operated ok with 8 but you run the risk of overrunning your boot part and you dont want to do that. With 5.2gb... yeah you're not going to have a good time.
 
size of disk is not important. size of boot partition (assuming you havent moved /var or /home or the other usual suspects to other partitions) should be no less then 16GB. this isnt a hard number- I've operated ok with 8 but you run the risk of overrunning your boot part and you dont want to do that. With 5.2gb... yeah you're not going to have a good time.
Thanks for the additional info. :)
For the system I'm setting up with the 128 GB boot drive, I'm going to give the TrueNAS VM 32 GiB and otherwise don't plan on running any other VMs on the system. I'll stick to LXCs for anything else I want to run there until I can afford to add additional storage.

I don't know what the actual ZFS boot partition size is on my current node…I assume it can grow as large as it needs to. That 5.2 GiB number was just what it's currently using.
 
you have no free space left.
I can not recognize which command was used. "zfs list" produces only three columns, not four (with numbers). Perhaps it was something like this?
Code:
~# zfs list -o space -r rpool | head -n 4
NAME                              AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
rpool                             1024G   131G        0B    104K             0B       131G
rpool/ROOT                        1024G  5.25G        0B     96K             0B      5.25G
rpool/ROOT/pve-1                  1024G  5.25G        0B   5.25G             0B         0B
So... the third column with numbers means "in Snapshots"...
 
I can not recognize which command was used. "zfs list" produces only three columns, not four (with numbers). Perhaps it was something like this?
Code:
~# zfs list -o space -r rpool | head -n 4
NAME                              AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
rpool                             1024G   131G        0B    104K             0B       131G
rpool/ROOT                        1024G  5.25G        0B     96K             0B      5.25G
rpool/ROOT/pve-1                  1024G  5.25G        0B   5.25G             0B         0B
So... the third column with numbers means "in Snapshots"...
Thanks, @UdoB . Kind of exhausted yesterday and forgot to post the command. Sorry for all the confusion.

I'm still learning zfs commands, and I did use an example that added an option , without really understanding what it did. I thought it would make it easier to read.

Here's a straight up ZFS list, for comparison:

Code:
# zfs list
NAME                                       USED  AVAIL  REFER  MOUNTPOINT
rpool                                      101G   798G   104K  /rpool
rpool/ROOT                                5.20G   798G    96K  /rpool/ROOT
rpool/ROOT/pve-1                          5.20G   798G  5.20G  /
rpool/data                                95.6G   798G   112K  /rpool/data
rpool/data/ctStore0                       4.91G   798G    96K  /rpool/data/ctStore0
rpool/data/ctStore0/subvol-99901-disk-0   4.91G  6.48G  1.52G  /rpool/data/ctStore0/subvol-99901-disk-0
rpool/data/vmStore16k                     47.6M   798G    96K  /rpool/data/vmStore16k
rpool/data/vmStore16k/vm-99902-disk-0     47.5M   798G  37.4M  -
rpool/data/vmStore64k                     90.6G   798G    96K  /rpool/data/vmStore64k
rpool/data/vmStore64k/base-100001-disk-0   112K   798G   104K  -
rpool/data/vmStore64k/vm-2001-disk-0      1.25M   798G   124K  -
rpool/data/vmStore64k/vm-2001-disk-1      75.2G   798G  26.7G  -
rpool/data/vmStore64k/vm-2001-disk-2       896K   798G    64K  -
rpool/data/vmStore64k/vm-2003-disk-0       108K   798G   108K  -
rpool/data/vmStore64k/vm-2003-disk-1      8.53G   798G  8.53G  -
rpool/data/vmStore64k/vm-2003-disk-2       161M   798G   161M  -
rpool/data/vmStore64k/vm-99001-disk-0     1.16M   798G   104K  -
rpool/data/vmStore64k/vm-99001-disk-1     2.46G   798G  1.25G  -
rpool/data/vmStore64k/vm-99001-disk-2      116M   798G  96.7M  -
rpool/data/vmStore64k/vm-99902-disk-0     1.21M   798G   104K  -
rpool/data/vmStore64k/vm-99902-disk-1     4.16G   798G  1.52G  -
rpool/data/vmStore64k/vm-99902-disk-2     8.26M   798G  4.61M  -
rpool/data/vmStore64k/vm-99902-disk-3     2.90M   798G   360K  -
rpool/var-lib-vz                            96K   798G    96K  /var/lib/vz

Here's the command I used forgot to post. As someone still learning ZFS, I like the extra info so I start learning why and how things work the way they do, but it certainly leads to confusion without the header row.

Code:
root@andromeda2:~# sudo zfs list -o space
NAME                                      AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
rpool                                      798G   101G        0B    104K             0B       101G
rpool/ROOT                                 798G  5.20G        0B     96K             0B      5.20G
rpool/ROOT/pve-1                           798G  5.20G        0B   5.20G             0B         0B
rpool/data                                 798G  95.6G        0B    112K             0B      95.6G
rpool/data/ctStore0                        798G  4.91G        0B     96K             0B      4.91G
rpool/data/ctStore0/subvol-99901-disk-0   6.48G  4.91G     3.39G   1.52G             0B         0B
rpool/data/vmStore16k                      798G  47.6M        0B     96K             0B      47.5M
rpool/data/vmStore16k/vm-99902-disk-0      798G  47.5M     10.1M   37.4M             0B         0B
rpool/data/vmStore64k                      798G  90.6G        0B     96K             0B      90.6G
rpool/data/vmStore64k/base-100001-disk-0   798G   112K        8K    104K             0B         0B
rpool/data/vmStore64k/vm-2001-disk-0       798G  1.25M     1.13M    124K             0B         0B
rpool/data/vmStore64k/vm-2001-disk-1       798G  75.2G     48.5G   26.7G             0B         0B
rpool/data/vmStore64k/vm-2001-disk-2       798G   896K      832K     64K             0B         0B
rpool/data/vmStore64k/vm-2003-disk-0       798G   108K        0B    108K             0B         0B
rpool/data/vmStore64k/vm-2003-disk-1       798G  8.53G        0B   8.53G             0B         0B
rpool/data/vmStore64k/vm-2003-disk-2       798G   161M        0B    161M             0B         0B
rpool/data/vmStore64k/vm-99001-disk-0      798G  1.16M     1.05M    104K             0B         0B
rpool/data/vmStore64k/vm-99001-disk-1      798G  2.46G     1.20G   1.25G             0B         0B
rpool/data/vmStore64k/vm-99001-disk-2      798G   116M     18.9M   96.7M             0B         0B
rpool/data/vmStore64k/vm-99902-disk-0      798G  1.21M     1.11M    104K             0B         0B
rpool/data/vmStore64k/vm-99902-disk-1      798G  4.16G     2.64G   1.52G             0B         0B
rpool/data/vmStore64k/vm-99902-disk-2      798G  8.26M     3.65M   4.61M             0B         0B
rpool/data/vmStore64k/vm-99902-disk-3      798G  2.90M     2.55M    360K             0B         0B
rpool/var-lib-vz                           798G    96K        0B     96K             0B         0B
 
I went and reread the thread since realizing you had zfs list output and not df ;)

so... what exactly is the actual problem? when you have a zfs root fs its all thin provisioned by default. The only elements that get a size limit are zvols- for file systems you'd need to use quotas to limit their size. If you check df /, you'll see the entirety of the pool free space available to the root filesystem.

In general, you want to avoid using the same disk for your OS AND payload, especially if you overprovision your storage (eg, set a higher cap limit on the guest zvols then you have available on the disk) because it can lead to a no space available situation and that would be both bad (zfs doesnt like being full resulting in rapidly degrading write performance) and worse (a full zfs pool doesnt allow you to delete anything since there is no room for the journal, necessitating the need for some ugly trickery to recover from.) As I understood it, you have two disks available- use your 480gb for virtual disks and leave the 128GB for pve. I understand you want to use what you have and use it to the fullest, but that comes with pitfalls you may not enjoy.
 
I went and reread the thread since realizing you had zfs list output and not df ;)

so... what exactly is the actual problem? when you have a zfs root fs its all thin provisioned by default. The only elements that get a size limit are zvols- for file systems you'd need to use quotas to limit their size. If you check df /, you'll see the entirety of the pool free space available to the root filesystem.

In general, you want to avoid using the same disk for your OS AND payload, especially if you overprovision your storage (eg, set a higher cap limit on the guest zvols then you have available on the disk) because it can lead to a no space available situation and that would be both bad (zfs doesnt like being full resulting in rapidly degrading write performance) and worse (a full zfs pool doesnt allow you to delete anything since there is no room for the journal, necessitating the need for some ugly trickery to recover from.) As I understood it, you have two disks available- use your 480gb for virtual disks and leave the 128GB for pve. I understand you want to use what you have and use it to the fullest, but that comes with pitfalls you may not enjoy.

I was more confusing than I thought. I've got a 128 GiB NVME available, and a 1.7 TiB enterprise SATA SSD in a USB enclosure. My only PCIe slot is occupied by a NIC, so I'm stuck with this setup for now … unless I get rid of one of my mirror vdevs and devote two SATA ports to a boot mirror pool.

Honestly, at the beginning, I didn't realize how small the actual boot pool OS install is. I was concerned about running out of room on a 128 GiB disk. That doesn't sound like it'll be a problem.

I know running VMs on rpool is not ideal, but at this point I'll either have to do that or do USB/Thunderbolt for a VM storage pool. That wouldn't be the end of the world, but losing 12 TB of space would be a bit frustrating. More than that, it would complicate my setup, as I'd no longer just be able to pass both SATA controllers to TrueNAS from Proxmox; I'd have to retain one of the controllers on Proxmox and pass two of its disks, which is a big no for virtualizing TrueNAS.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!