* [pve-devel] Upstream contribution to ZFSPoolPlugin.pm possible?
@ 2025-08-04 9:45 Christian Suessenguth - sweetgood.de/en via pve-devel
2025-08-05 12:36 ` Max R. Carrara
0 siblings, 1 reply; 6+ messages in thread
From: Christian Suessenguth - sweetgood.de/en via pve-devel @ 2025-08-04 9:45 UTC (permalink / raw)
To: pve-devel; +Cc: Christian Suessenguth - sweetgood.de/en
[-- Attachment #1: Type: message/rfc822, Size: 4162 bytes --]
[-- Attachment #1.1.1: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] Upstream contribution to ZFSPoolPlugin.pm possible?
2025-08-04 9:45 [pve-devel] Upstream contribution to ZFSPoolPlugin.pm possible? 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>
0 siblings, 2 replies; 6+ messages in thread
From: Max R. Carrara @ 2025-08-05 12:36 UTC (permalink / raw)
To: Proxmox VE development discussion; +Cc: Christian Suessenguth - sweetgood.de/en
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
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] Upstream contribution to ZFSPoolPlugin.pm possible?
2025-08-05 12:36 ` Max R. Carrara
@ 2025-08-05 12:39 ` Christian Süßenguth via pve-devel
[not found] ` <06261024c4bd98bf9ab5d8939a110d968c675476@sweetgood.de>
1 sibling, 0 replies; 6+ messages in thread
From: Christian Süßenguth via pve-devel @ 2025-08-05 12:39 UTC (permalink / raw)
To: Max R. Carrara, Proxmox VE development discussion
Cc: Christian Süßenguth
[-- Attachment #1: Type: message/rfc822, Size: 5730 bytes --]
[-- Attachment #1.1.1: Type: text/plain, Size: 1270 bytes --]
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/
What steps would I have to take to have this implemented upstream? Or is there something from dev side which speaks against implementing this at all?
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
> >
>
[-- Attachment #1.1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] Upstream contribution to ZFSPoolPlugin.pm possible?
[not found] ` <06261024c4bd98bf9ab5d8939a110d968c675476@sweetgood.de>
@ 2025-08-05 13:49 ` Max R. Carrara
2025-08-05 14:56 ` Max R. Carrara
0 siblings, 1 reply; 6+ messages in thread
From: Max R. Carrara @ 2025-08-05 13:49 UTC (permalink / raw)
To: Christian Süßenguth, Proxmox VE development discussion
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] Upstream contribution to ZFSPoolPlugin.pm possible?
2025-08-05 13:49 ` Max R. Carrara
@ 2025-08-05 14:56 ` Max R. Carrara
2025-08-05 20:24 ` Christian Süßenguth via pve-devel
0 siblings, 1 reply; 6+ messages in thread
From: Max R. Carrara @ 2025-08-05 14:56 UTC (permalink / raw)
To: Max R. Carrara, Christian Süßenguth,
Proxmox VE development discussion
On Tue Aug 5, 2025 at 3:49 PM CEST, Max R. Carrara wrote:
> 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.
There's another thing I wanted to mention that one of my coworkers
(thanks Aaron!) just pointed out to me: This bug here has been open
since quite a while:
https://bugzilla.proxmox.com/show_bug.cgi?id=2350
Since it has also been referenced in the forum thread you linked above,
I assume you're already aware of it; but anyhow, this issue might be a
blocker in general, unfortunately. I'm not sure if there have been any
recent improvements upstream in that regard.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] Upstream contribution to ZFSPoolPlugin.pm possible?
2025-08-05 14:56 ` Max R. Carrara
@ 2025-08-05 20:24 ` Christian Süßenguth via pve-devel
0 siblings, 0 replies; 6+ messages in thread
From: Christian Süßenguth via pve-devel @ 2025-08-05 20:24 UTC (permalink / raw)
To: Proxmox VE development discussion; +Cc: Christian Süßenguth
[-- Attachment #1: Type: message/rfc822, Size: 8619 bytes --]
[-- Attachment #1.1.1: Type: text/plain, Size: 3209 bytes --]
Hi Max,
at first a big thank you for giving me such a detailed answer and also for pointing me to this bugzilla issue.
I hope I find time to get through all this and if it's feasible for me to contribute the way you described i will do.
So this is just a quick "thanks" from my side. Will report back as soon as there are any updates on this.
Thanks,
Christian
---
Am 5. August 2025 um 16:56 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 Tue Aug 5, 2025 at 3:49 PM CEST, Max R. Carrara wrote:
>
> >
> > 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.
> >
> There's another thing I wanted to mention that one of my coworkers
> (thanks Aaron!) just pointed out to me: This bug here has been open
> since quite a while:
> https://bugzilla.proxmox.com/show_bug.cgi?id=2350
>
> Since it has also been referenced in the forum thread you linked above,
> I assume you're already aware of it; but anyhow, this issue might be a
> blocker in general, unfortunately. I'm not sure if there have been any
> recent improvements upstream in that regard.
>
> _______________________________________________
> 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
>
[-- Attachment #1.1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-08-08 14:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-08-04 9:45 [pve-devel] Upstream contribution to ZFSPoolPlugin.pm possible? 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
2025-08-05 14:56 ` Max R. Carrara
2025-08-05 20:24 ` Christian Süßenguth via pve-devel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.