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