From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: pve-devel@lists.proxmox.com, Stoiko Ivanov <s.ivanov@proxmox.com>
Subject: applied-series: [RFC docs/storage/zfsonlinux 0/4] allow replication/migration with zfs native encryption
Date: Thu, 07 May 2026 10:44:44 +0200 [thread overview]
Message-ID: <1778143461.uw5fmhb4sg.astroid@yuna.none> (raw)
In-Reply-To: <20260318124659.374754-1-s.ivanov@proxmox.com>
zfsonlinux bumped, rest just pushed for now.
thanks!
On March 18, 2026 1:40 pm, Stoiko Ivanov wrote:
> OpenZFS recently got support for suppressing the encryption options while
> sending with -Rp[0]. This patchset adds the (userland only) patch to our
> zfsonlinux repository and uses the functionality to enable
> volume_export and volume_import for encrypted ZFS datasets.
>
> My initial (quite limited) tests indicates that it works as intended
> (storage-replication/migration of containers, live and offline migration of a
> VM).
>
> As is the functionality is quite versatile - guests can be send from encrypted
> to unencrypted storages and vice versa. The encryption state of a guest-disk/
> volume is solely defined by the storage on each node, it is not a property
> of the guest-disk, and not enforced.
>
> The main caveat I currently see is that the patches need to be present
> on the receiving node before the first encrypted guest-disk is received:
> Without the addition of `-x encryption` for `zfs recv` the disk would
> get created/received without encryption, even if the root-dataset of the
> storage is encrypted. As storage-migration is currently broken for encrypted
> ZFS pools in any case this seems acceptable. Users would need to upgrade
> all nodes to versions with these patches before migrating/replicating
> the first guest disk on an encrypted zpool.
>
> the second patch for pve-storage is optional - I'm not sure if always printing
> the warning helps or would raise more questions than it answers.
>
> For the whole series:
> Suggested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
>
> [0] https://github.com/openzfs/zfs/pull/18240
> zfsonlinux:
>
> Stoiko Ivanov (1):
> cherry-pick patch for unencrypted send
>
> ...0015-Add-no-preserve-encryption-flag.patch | 306 ++++++++++++++++++
> debian/patches/series | 1 +
> 2 files changed, 307 insertions(+)
> create mode 100644 debian/patches/0015-Add-no-preserve-encryption-flag.patch
>
>
> pve-storage:
>
> Stoiko Ivanov (2):
> fix #2350: zfspool: send without preserving encryption
> zfspool: export: skip hardcoded warning about no-preserve-encryption
> flag
>
> src/PVE/Storage/ZFSPoolPlugin.pm | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
>
> pve-docs:
>
> Stoiko Ivanov (1):
> storage: zfspool: add documention on encryption
>
> pve-storage-zfspool.adoc | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
>
> Summary over all repositories:
> 4 files changed, 343 insertions(+), 3 deletions(-)
>
> --
> Generated by murpp 0.10.0
>
>
>
>
>
prev parent reply other threads:[~2026-05-07 8:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 12:40 [RFC docs/storage/zfsonlinux 0/4] allow replication/migration with zfs native encryption Stoiko Ivanov
2026-03-18 12:40 ` [PATCH zfsonlinux 1/4] cherry-pick patch for unencrypted send Stoiko Ivanov
2026-03-18 12:40 ` [PATCH storage 2/4] fix #2350: zfspool: send without preserving encryption Stoiko Ivanov
2026-04-23 10:26 ` m.loderer
2026-03-18 12:40 ` [PATCH storage 3/4] zfspool: export: skip hardcoded warning about no-preserve-encryption flag Stoiko Ivanov
2026-03-18 12:40 ` [PATCH docs 4/4] storage: zfspool: add documention on encryption Stoiko Ivanov
2026-05-07 8:44 ` Fabian Grünbichler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1778143461.uw5fmhb4sg.astroid@yuna.none \
--to=f.gruenbichler@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=s.ivanov@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox