public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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).




  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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal