[pve-devel] [PATCH pve-container 1/1] Adding new mount point type named 'zfs' to let configure a ZFS dataset as mount point for LXC container

[Konstantin]

Hello,

 > most tools have ways to exclude certain paths ;)

Yeah - and every time when this "need to be excluded datasets" 
list/names changed we need to update exclude options for this tools as 
well. It seems that just make this datasets not visible to host is 
simpler, isn't it?

 > you could "protect" the guest:

I know about this option - but sometimes it isn't applicable. For 
example I often use the following scenario when need to upgrade an OS on 
container: save configs from container, destroy the container (dataset 
with my data isn't destroyed because it's non PVE), deploy the new one 
from updated template (dataset with my data just reattached back), 
restore configs and it's ready to use. Maybe the following option will 
be useful if you're insist on using Proxmox managed storage - introduce 
the ability to protect a volume? If so - it probably will be acceptable 
way for me.

 > but like I said, it can be implemented more properly as well

In a couple with volume protection capability it could be an option - 
make a possibility for PVE managed ZFS dataset to have a legacy 
mountpoint instead of mandatory mount on host. But as I said - it's the 
only (and working) method which I've found for me and I'm just proposing 
it as starting point for possible improvement in such use cases like 
mine. If you can propose a better solution for that - ok, let's discuss 
in details how it can be done.

Best regards,

Konstantin.


On 11.05.2023 15:25, Fabian Grünbichler wrote:
>> Konstantin <frank030366 at hotmail.com> hat am 11.05.2023 13:56 CEST geschrieben:
>>
>>
>> Hello,
>>> nit: for single patches, there is no need to add a coverletter. also, please include relevant information in the commit message!
>> I'm new here, so sorry - will follow rules in future.
> no worries! check out https://pve.proxmox.com/wiki/Developer_Documentation if you haven't already :)
>
>>> could you give a reason why you want to hide the container contents from the host?
>> I'll try to explain my points. I'm using Proxmox as a base for my home NAS in addition with possibility to setup some test environments to play around. So one LXC container is playing NAS role - it has all required software installed (samba/ftp/etc) and have a big volume mounted for data storage (8-10TB). If it will be created and configured as proxmox builtin storage volume (using ZFS storage provider) I have at least 3 points which I'm not comfortable with:
>> - this big dataset will be mounted to PVE host and will be visible and accessible from host so every (for example) file search operation will be affected by this dataset. I would like to narrow any such file operation only to host related stuff, not to my NAS data;
> most tools have ways to exclude certain paths ;)
>
>> - in addition while operating on host I have a probability to accidentally affect or destroy my NAS data so I'd like to avoid this possibility anyway;
> IMHO that's what backups are for, but I get the point.
>
>> - simple "pct destroy" command will destroy all proxmox storage provided mount points as well. I'd like to avoid such possibilty anyway.
> you could "protect" the guest:
>
> $ pct set XXXX -protection 1
> $ pct destroy XXXX
> can't remove CT XXXX - protection mode enabled
>
>
> another alternative would be to use a (protected) VM - no regular ZFS dataset, no visibility on the host.
>
>> As I see in pve-container code - only bind mount and block device mount can be used as non-proxmox volume. But bind mount isn't acceptable for me according to points above. ZFS dataset isn't a block device - so it cannot be mounted using standard notation in LXC config. That's why I'm proposing this patch - it adds the capality to use ZFS filesystem as mount point for LXC container. With this functionality I can just add the following line (or configure with pct) to LXC container config:
>> mp1: tank/nas-data,mp=/data
>> And after that ZFS dataset "tank/nas-data" will be mounted inside container and will not be exposed to host (of course mountpoint=legacy should be set for this dataset). Maybe other more elegant ways possible to implement this but this the only way I've found.
> the two existing special cases besides PVE-managed volumes have a rather big use case - passing through existing hard disks or partitions (shared with VMs, which have the same feature), and passing in host directories. this would be a very niche feature only applying to one specific storage type, so changing the syntax (and adding checks all over the place) would not be worth it.
>
> but like I said, it can be implemented more properly as well - currently we say "a non-snapshot ZFS volume managed by PVE is always mounted on the host and can be bind-mounted", but we could just as well say "a non-snapshot ZFS volume is mounted directly via mount", either in general, or opt-in via flag in storage.cfg, or just for mountpoint=legacy/none mountpoints (e.g., where PVE::Storage::path returns a special value? or ..). nothing with regards to the container config syntax would change, just the mountpoint handling in pve-container (and the part in pve-storage that currently does the host-side mounting in activate_volume).
>