From: "Max R. Carrara" <m.carrara@proxmox.com>
To: "Christian Süßenguth" <cs@sweetgood.de>,
"Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] Upstream contribution to ZFSPoolPlugin.pm possible?
Date: Tue, 05 Aug 2025 15:49:16 +0200 [thread overview]
Message-ID: <DBUJIOMSW0D9.3CA92J3PIK7XT@proxmox.com> (raw)
In-Reply-To: <06261024c4bd98bf9ab5d8939a110d968c675476@sweetgood.de>
On Tue Aug 5, 2025 at 2:39 PM CEST, =?utf-8?B?Q2hyaXN0aWFuIFPDvMOfZW5ndXRo?= wrote:
> Hi Max,
>
> sure thing, here's my request without any signature:
>
> Dear PROXMOX devs,
>
> I have a quick question regarding an upstream contribution to ZFSPoolPlugin.pm.
>
> Currently I'm "maintaining" the following patch which allows migration of encrypted ZFS datasets: https://forum.proxmox.com/threads/allow-migration-and-replication-of-disks-on-zfs-encrypted-storage.117227/
Ah, interesting! Thanks for sharing. Let me answer your questions first:
>
> What steps would I have to take to have this implemented upstream?
In short:
1. Check out the general developer documentation if you haven't
already: https://pve.proxmox.com/wiki/Developer_Documentation
2. You will need to sign a CLA if you haven't yet. For more
information, see: https://proxmox.com/en/about/open-source/developers
3. Work on your patch series
4. Send the series to this mailing list once you're satisfied
5. Wait for feedback / review
6. Eventually have your patch series applied once it passes review
and testing; otherwise goto 3. if changes are requested
Of course, depending on the scope and size of the patch series, this can
take a little while, but don't let this discourage you. We always
welcome contributions and are happy to review and test them! :)
> Or is there something from dev side which speaks against implementing this at all?
In general, there's nothing that speaks against implementing this;
it's rather that it would require some more thorough testing and
careful planning on how the feature should be integrated overall, as
storage is something very fundamental in PVE.
Before I elaborate on this, I want to note that we're soon going to
publish a storage plugin development guide on the wiki; it's best to
keep an eye on this page: https://pve.proxmox.com/wiki/Storage_Plugin_Development
Anyhow, to implement this particular feature, I would first suggest
thinking about how it integrates with the rest of PVE and how it will
behave with existing zpools and guest volumes. For example, what will
the user have to do in order to create an encrypted volume? Can existing
volumes be encrypted? Can an existing pool allow encrypted volumes? Or
would it make more sense to have zpools either allow unencrypted
volumes, *or* encrypted volumes, but not both? And so on and so forth.
It's (obviously) also very important that existing storage setups don't
break, including replication jobs.
Another big topic is how the encryption keys are handled--for example,
will there be multiple keys or just one per storage? Since both nodes
need to have access to the same key when migrating an encrypted volume,
the key would have to be stored in a place where both nodes can access
it. pmxcfs (so, /etc/pve) is usually the place to go for this. Note
what we recently added support for custom sensitive parameters as well:
https://git.proxmox.com/?p=pve-storage.git;a=commit;h=db5c50c079aba2d94726fefe40fe6506029a7774
The upcoming guide will also explain how to use and handle sensitive
parameters in general.
Even though all of this might be a bit much up front--and it's all I
could think of off the top of my head right now, so there's probably a
lot more to consider--I hope that I could provoke some thought here. If
you need some more concrete pointers on where (or with what) to start,
let us know! :)
Kind regards,
Max
>
> Thanks in advance,
> Christian
>
> sweetgood.de
>
> ---
>
>
> Am 5. August 2025 um 14:36 schrieb "Max R. Carrara" <m.carrara@proxmox.com mailto:m.carrara@proxmox.com?to=%22Max%20R.%20Carrara%22%20%3Cm.carrara%40proxmox.com%3E >:
>
> >
> > On Mon Aug 4, 2025 at 11:45 AM CEST, Christian Suessenguth - sweetgood.de/en via pve-devel wrote:
> >
> > Hmm, seems like your mail didn't make it through, I can only see the
> > signature you attached ... could you try again? Seems like it's related
> > to storage.
> >
> > >
> > > _______________________________________________
> > > pve-devel mailing list
> > > pve-devel@lists.proxmox.com mailto:pve-devel@lists.proxmox.com
> > > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> > >
> >
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-08-05 13:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-04 9:45 Christian Suessenguth - sweetgood.de/en via pve-devel
2025-08-05 12:36 ` Max R. Carrara
2025-08-05 12:39 ` Christian Süßenguth via pve-devel
[not found] ` <06261024c4bd98bf9ab5d8939a110d968c675476@sweetgood.de>
2025-08-05 13:49 ` Max R. Carrara [this message]
2025-08-05 14:56 ` Max R. Carrara
2025-08-05 20:24 ` Christian Süßenguth via pve-devel
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=DBUJIOMSW0D9.3CA92J3PIK7XT@proxmox.com \
--to=m.carrara@proxmox.com \
--cc=cs@sweetgood.de \
--cc=pve-devel@lists.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