Re: [PATCH storage 2/4] fix #2350: zfspool: send without preserving encryption

["m.loderer@proxmox.com" <m.loderer@proxmox.com>]

I applied the patches and tested:

I have this running on a test cluster with one VM and one CT. I tested the 
following over about a week with active replication:

- Start/Stop
- Live migration
- Offline migration
- Snapshots + migrations
- Rebooting cluster nodes
- Waiting after reboot of a node to the VMs start-timeout, to rule out zfs 
mounting problems with subvols
- Bidirectional replication of the CT and the VM at the same time

It's working perfectly so far!!

Tested-by: Mario Loderer <m.loderer@proxmox.com>

---

Am Mittwoch, 18. März 2026, 13:40:15 Mitteleuropäische Sommerzeit schrieb 
Stoiko Ivanov:
> OpenZFS recently merged support for `zfs send`ing datasets, without
> their encryption properties[0]. Setting the new option in
> `volume_export` makes it possible to use storage migration for
> replication and migration when the guest-disk is encrypted through ZFS
> native encryption, without using raw sends.
> Raw sends explicitly set the encryption properties (keys, passphrases)
> on the destination side - breaking inheriting them from the parent
> datasets there (thus you'd need to load the keys for each guest
> disk/volume, instead of inherting them from the encryption root).
> 
> In order to not always receive and create the datasets as unencrypted
> the encryption properties need to be excluded on receive (via
> `-x encryption`).
> 
> The approach is quite flexible in allowing for sending encrypted
> and unencrypted datasets and have the target define the encryption
> state (e.g. remote-migrating to a location where encryption is needed
> from one where it has not been set up).
> 
> The receiving node needs to have the patches applied before initial
> receiving to prevent accidentally creating the dataset without
> encryption (despite the parent dataset/pool being encrypted).
> 
> This needs a versioned dependency bump on zfsutils-linux.
> 
> Tested minimally with containers and a VM with migration/replication
> on 2 machines with:
> * pools without encryption on both sides
> * encrypted pools on both sides
> * one encrypted and an unecrypted pool each
> 
> [0] https://github.com/openzfs/zfs/pull/18240
> 
> Fixes: https://bugzilla.proxmox.com/show_bug.cgi?id=2350
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
>  src/PVE/Storage/ZFSPoolPlugin.pm | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/src/PVE/Storage/ZFSPoolPlugin.pm
> b/src/PVE/Storage/ZFSPoolPlugin.pm index 3b3456b..eaeeb9d 100644
> --- a/src/PVE/Storage/ZFSPoolPlugin.pm
> +++ b/src/PVE/Storage/ZFSPoolPlugin.pm
> @@ -817,7 +817,7 @@ sub volume_export {
>      # For zfs we always create a replication stream (-R) which means the
> remote # side will always delete non-existing source snapshots. This should
> work # for all our use cases.
> -    my $cmd = ['zfs', 'send', '-Rpv'];
> +    my $cmd = ['zfs', 'send', '-RpvU'];
>      if (defined($base_snapshot)) {
>          my $arg = $with_snapshots ? '-I' : '-i';
>          push @$cmd, $arg, $base_snapshot;
> @@ -879,7 +879,10 @@ sub volume_import {
>          $zfspath = "$scfg->{pool}/$dataset";
>      }
> 
> -    eval { run_command(['zfs', 'recv', '-F', '--', $zfspath], input =>
> "<&$fd") }; +    eval {
> +        run_command(['zfs', 'recv', '-F', '-x', 'encryption', '--',
> $zfspath], +            input => "<&$fd");
> +    };
>      if (my $err = $@) {
>          if (defined($base_snapshot)) {
>              eval { run_command(['zfs', 'rollback', '-r', '--',
> "$zfspath\@$base_snapshot"]) };