From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Konstantin <frank030366@hotmail.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [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
Date: Thu, 11 May 2023 14:25:34 +0200 (CEST) [thread overview]
Message-ID: <1950349103.4373.1683807934502@webmail.proxmox.com> (raw)
In-Reply-To: <PAWPR02MB9056A83118D3E0A23AC28759BF749@PAWPR02MB9056.eurprd02.prod.outlook.com>
> Konstantin <frank030366@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).
next prev parent reply other threads:[~2023-05-11 12:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230510000830.1851-1-frank030366@hotmail.com>
[not found] ` <mailman.224.1683710297.359.pve-devel@lists.proxmox.com>
2023-05-11 8:27 ` Fabian Grünbichler
[not found] ` <PAWPR02MB9056A83118D3E0A23AC28759BF749@PAWPR02MB9056.eurprd02.prod.outlook.com>
2023-05-11 12:25 ` Fabian Grünbichler [this message]
[not found] ` <PAWPR02MB9056D6A844C3A636D8B5597CBF799@PAWPR02MB9056.eurprd02.prod.outlook.com>
2023-05-17 7:50 ` Fabian Grünbichler
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=1950349103.4373.1683807934502@webmail.proxmox.com \
--to=f.gruenbichler@proxmox.com \
--cc=frank030366@hotmail.com \
--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