TrueNAS - Add Certificate via ACME

Mon, 01 Jan 0001 00:00:00 +0000

TrueNAS - Add Certificate via ACME Link to heading

Problem Link to heading

I need TrueNAS to have a valid certificate for use by democratic-csi (for iSCSI and NFS) and for use on the UI.

Solution Link to heading

Official Documentation

Go to Cloudflare > My Profile > API Tokens and create a new Edit zone DNS Token.
Go to Credentials > Certificates
Click Add next to ACME DNS-Authenticators, fill in the API Token generated on step 1 and save.
Add a new Certificate Signing Request (CSR)
Click the wrench icon next to the new CSR to create the new certificate with ACME.
Set the GUI SSL Certificate by going to System > General Settings and click Settings in the GUI widget.

TrueNAS - VM Sizing and Configuration Best Practices

Mon, 01 Jan 0001 00:00:00 +0000

TrueNAS - VM Sizing and Configuration Best Practices Link to heading

Running TrueNAS (CORE or SCALE) as a virtual machine (VM) in a hypervisor like ProxmoxVE requires careful sizing and configuration to ensure stability, performance, and data integrity. This note outlines key best practices.

1. Memory (RAM) Allocation Link to heading

Minimum: TrueNAS CORE officially states 8GB of RAM as a minimum. TrueNAS SCALE also benefits from at least 8GB.
ZFS ARC: The most critical consumer of RAM is the ZFS Adaptive Replacement Cache (ARC). A common rule of thumb is 1GB of RAM per 1TB of raw storage capacity for optimal ARC performance, though this can vary based on workload. More RAM for ARC generally means better read performance.
Services: Account for RAM needed by TrueNAS services (SMB, NFS, iSCSI, Jails, Plugins, Apps, etc.).
Static Allocation: Crucially, assign a static amount of RAM to the TrueNAS VM.
Disable Memory Ballooning: As detailed in ProxmoxVE - TrueNAS VM - Disable Memory Ballooning, this feature is detrimental to ZFS ARC performance and stability.
Avoid dynamic memory or memory overcommitment for the TrueNAS VM.
ECC RAM: While this applies to the host hardware, if TrueNAS is critical, the host system should ideally use ECC RAM to protect ZFS data integrity from memory errors.

2. CPU Allocation Link to heading

Cores: A minimum of 2 CPU cores is generally recommended. More cores can be beneficial if running many services, plugins/apps, or handling high network throughput, especially with encryption (e.g., SMB encryption, VPNs).
CPU Type: Modern CPUs with AES-NI support are beneficial if using ZFS encryption or other cryptographic workloads.
Host Passthrough (Optional but Recommended): If your hypervisor supports it (like ProxmoxVE's host CPU type), passing through the host CPU model can provide better performance and access to all CPU features.
Avoid Over-Allocation: While ZFS itself isn't always CPU-bound for basic NAS tasks, services running on TrueNAS can be. Monitor CPU usage and avoid excessive over-allocation that could lead to contention on the host.

3. Storage Configuration Link to heading

Disk Passthrough (HBA Passthrough): This is the highly recommended method. Pass an entire HBA (Host Bus Adapter) directly to the TrueNAS VM.
Benefits: TrueNAS gets direct, unimpeded access to the raw disks. This allows ZFS to manage SMART data, disk health, and perform its functions optimally. It's the most reliable and performant method.
Requires VT-d/AMD-Vi enabled on the host.
Individual Disk Passthrough (RDM, Virtual Disks): If HBA passthrough isn't feasible, passing individual disks as raw device mappings (RDMs) or as virtual disks (e.g., VMDK, qcow2) is an alternative.
Raw Disks (e.g. virtio-scsi with scsiblock=true in Proxmox): Generally preferred over file-backed virtual disks for performance.
File-backed Virtual Disks: Can work, but may introduce a slight performance overhead and abstract SMART data. If used, ensure they are preallocated/thick-provisioned for better performance and to avoid issues with thin provisioning on the ZFS layer.
Boot Drive: The TrueNAS boot drive can be a small virtual disk (e.g., 16-32GB SSD-backed virtual disk is fine). It does not need to be part of the main storage pool HBA passthrough.
ZFS Pool Design: Standard ZFS pool design principles (RAIDZ levels, mirroring, vdevs) apply within the VM, regardless of how disks are presented.

4. Network Configuration Link to heading

Virtual NIC: Use a performant virtual network interface, such as virtio (common in KVM/Proxmox).
Dedicated Physical NIC (Optional): For high-performance needs, consider passing through a dedicated physical NIC to the TrueNAS VM, or using SR-IOV if available.
Jumbo Frames: If your physical network supports it and you need maximum throughput for large file transfers, configure jumbo frames (MTU 9000) consistently across the TrueNAS VM, hypervisor, physical switches, and clients.

5. Hypervisor-Specific Settings (Example: ProxmoxVE) Link to heading

BIOS: OVMF (UEFI) is generally recommended for modern OSes like TrueNAS.
Machine Type: q35 is a common modern choice.
SCSI Controller: For virtual disks or passthrough disks not on a dedicated HBA, VirtIO SCSI single (with iothread=1 enabled on the disk) can offer good performance.
QEMU Guest Agent: Install and enable the QEMU guest agent in the TrueNAS VM for better integration with the hypervisor (e.g., clean shutdowns, IP address reporting).

6. Backup and Snapshots Link to heading

Hypervisor Snapshots vs. ZFS Snapshots:
ZFS Snapshots: Use ZFS's native snapshot capabilities within TrueNAS for your data pools. These are efficient and application-consistent for ZFS.
Hypervisor Snapshots: Be cautious with hypervisor-level snapshots of a running TrueNAS VM, especially if it's actively performing I/O. While often safe, there's a small risk of issues if the snapshot doesn't perfectly capture in-flight I/O. If used, ensure the QEMU guest agent is running to help quiesce the filesystem. For the data pools themselves, ZFS snapshots are superior.
Backups: Plan a robust backup strategy for your TrueNAS data, independent of hypervisor snapshots (e.g., ZFS replication to another TrueNAS instance or a cloud provider).

TrueNAS on Wael Nasreddine