Guide
    Proxmox Content Hub

    Proxmox: LUKS vs ZFS Encryption for Non-Root VM Disks

    Proxmox LUKS encryption for extra VM disks: compare LUKS inside the guest via passthrough with LUKS or ZFS on the host, plus pros and cons.

    Two storage stacks for adding encrypted HDDs to a Proxmox VM: LUKS inside the VM after disk passthrough, or LUKS on the host with a ZFS pool and a virtual disk, with pros and cons of each
    The two options differ in which layer holds the encryption. For most Proxmox users the page recommends encrypting on the host and giving the VM virtual disks.

    Your scenario

    - VM already stored on encrypted dataset

    - Adding two HDDs for storage

    - Planning to use mergerfs inside VM

    - Disks must be encrypted

    - No RAID0 (avoid losing both disks if one fails)

    Option 1: Pass through disks and use LUKS inside the VM

    - Raw disk passthrough to VM

    - Encrypt each disk with LUKS inside VM

    - Use mergerfs normally inside guest

    - Encryption keys managed by VM OS

    Pros:

    - Clear separation between host and guest

    - Portability (VM can move to another host)

    - Simple mental model

    Cons:

    - Encryption overhead handled by VM

    - Less efficient CPU scheduling under load

    - Host cannot easily manage disk state

    Option 2: LUKS on the host, a ZFS pool and a virtual disk for the VM

    - Encrypt physical disks with LUKS on host

    - Create ZFS pool on unlocked block devices

    - Present virtual disk(s) to VM

    - Encryption handled by host

    Pros:

    - Host-level resource management

    - Better I/O scheduling and contention control

    - Easier backups and snapshots

    - No double encryption stack

    Cons:

    - Slightly more complex host configuration

    - VM portability tied to host pool

    ZFS native encryption vs LUKS

    ZFS native encryption works at dataset level and integrates cleanly with snapshots and replication. Performance overhead on modern CPUs is typically minimal and often goes unnoticed on HDD-based storage.

    On spinning disks the bottleneck is usually the disk speed itself, and encryption overhead rarely matters.

    About mergerfs and disk failure

    Since you want independent disks (not RAID0), mergerfs is fine if:

    - You accept manual recovery if a disk fails

    - Each disk stores independent files

    - You maintain proper backups

    Encryption method does not conflict with mergerfs as long as disks are unlocked before mounting.

    Recommended approach

    For most Proxmox users:

    - Use LUKS or ZFS encryption on the host

    - Create storage pool from unlocked devices

    - Expose virtual disks to the VM

    This allows the host to manage I/O scheduling and avoids nested encryption overhead inside the VM.

    Frequently asked questions

    Is there a huge performance drop with ZFS encryption?

    On modern CPUs the performance impact is minimal, especially on HDDs.

    Is double encryption a problem?

    It works, but it adds overhead and complexity you do not need.

    If one disk dies, will the other survive?

    Yes, as long as you are not using RAID0 or striped ZFS vdevs.

    Should encryption be managed by host or guest?

    Host-level encryption is generally cleaner and more efficient in Proxmox environments.

    Need help with Proxmox?

    Use the form below to get in touch about migrations, troubleshooting, and Proxmox design work.