From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 0400FE478 for ; Tue, 18 Jul 2023 14:56:44 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D99951B08C for ; Tue, 18 Jul 2023 14:56:43 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 18 Jul 2023 14:56:43 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id CF0C042BF6 for ; Tue, 18 Jul 2023 14:56:42 +0200 (CEST) Message-ID: <71659238-9805-1489-9ad8-1d640f8bca0f@proxmox.com> Date: Tue, 18 Jul 2023 14:56:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: Proxmox VE development discussion , Markus Frank References: <20230706105421.54949-1-m.frank@proxmox.com> From: Friedrich Weber In-Reply-To: <20230706105421.54949-1-m.frank@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.226 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.097 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [qemu.pm, cluster.pm, memory.pm, dir.pm, mapping.pm, qemuserver.pm] Subject: Re: [pve-devel] [PATCH cluster/guest-common/qemu-server/manager v6 0/11] virtiofs X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2023 12:56:44 -0000 Tested the following: * created a mapping on a 3-node cluster, added mapping to PVE8 VM, offline-migrated VM between cluster nodes, checked that `mount` inside the VM mounts the correct host directory * checked that `xattr=1` makes xattrs available in the guest, and `acl=1` makes acls available in the guest * added a non-privileged user with different combinations of Mapping.Audit/Use/Modify and played around with modifying/using directory mappings Overall, it's working fine and I did not encounter major issues. Here are a few things I noticed (somewhat sorted by priority in descending order): * after having started and stopped a VM with a shared filesystem a few times, I noticed quite some zombie virtiofsd processes, I guess they would need to be cleaned up: ``` root 11121 0.0 3.5 251260 140924 ? S 14:23 0:00 task UPID:cl2:00002B6C:00056BEE:64B68425:qmstart:100:fred@pve: root 11125 0.0 0.0 0 0 ? Z 14:23 0:00 \_ [virtiofsd] root 12064 0.0 3.5 251180 140980 ? S 14:28 0:00 task UPID:cl2:00002F1D:0005E581:64B6855D:qmstart:100:fred@pve: root 12067 0.0 0.0 0 0 ? Z 14:28 0:00 \_ [virtiofsd] ... ``` * is it intended that the virtiofsd process is started as a child of the qmstart task process, causing the task process to stay around as long as the VM is up? This seemed a bit unexpected to me when I first read the `ps` output, but also I don't know if there is a good alternative. * in the GUI, the Add->Shared Filesystem button is greyed out if I do not have the Sys.Console privilege, but via the API I can create the shared filesystem without Sys.Console and with just (I think) VM.Config.Disk and Mapping.Use. I'm not sure, but it seems like the GUI permission check is too strict and Sys.Console should not be required? * in the GUI, I can add multiple shared directories with the same tag but different dirids to a VM. In a quick test, it looked like the first one took precedence. Not sure if there should be some kind of validation logic here checking that no two virtiofs entries use the same tag? * in the GUI, if I add a shared filesystem, the dialog title is "Add: Filesystem passthrough", this should probably be "Add: Shared Filesystem" for consistency with the button text. On 06/07/2023 12:54, Markus Frank wrote: > cluster: > > Markus Frank (1): > add mapping/dir.cfg for resource mapping > > src/PVE/Cluster.pm | 1 + > src/pmxcfs/status.c | 1 + > 2 files changed, 2 insertions(+) > > > guest-common: > > Markus Frank (1): > add DIR mapping config > > src/Makefile | 1 + > src/PVE/Mapping/DIR.pm | 175 +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 176 insertions(+) > create mode 100644 src/PVE/Mapping/DIR.pm > > > qemu-server: > > v6: > * added virtiofsd dependency > * 2 new patches: > * Permission check for virtiofs directory access > * check_local_resources: virtiofs > > v5: > * allow numa settings with virtio-fs > * added direct-io & cache settings > * changed to rust implementation of virtiofsd > * made double fork and closed all file descriptor so that the lockfile > gets released. > > v3: > * created own socket and get file descriptor for virtiofsd > so there is no race between starting virtiofsd & qemu > * added TODO to replace virtiofsd with rust implementation in bookworm > (I packaged the rust implementation for bookworm & the C implementation > in qemu will be removed in qemu 8.0) > > v2: > * replaced sharedfiles_fmt path in qemu-server with dirid: > * user can use the dirid to specify the directory without requiring root access > > Markus Frank (3): > feature #1027: virtio-fs support > Permission check for virtiofs directory access > check_local_resources: virtiofs > > PVE/API2/Qemu.pm | 18 +++++ > PVE/QemuServer.pm | 167 ++++++++++++++++++++++++++++++++++++++- > PVE/QemuServer/Memory.pm | 25 ++++-- > debian/control | 1 + > 4 files changed, 204 insertions(+), 7 deletions(-) > > > manager: > > v6: completly new except "ui: added options to add virtio-fs to qemu config" > > Markus Frank (5): > api: add resource map api endpoints for directories > ui: add edit window for dir mappings > ui: ResourceMapTree for DIR > ui: form: add DIRMapSelector > ui: added options to add virtio-fs to qemu config > > PVE/API2/Cluster/Mapping.pm | 7 + > PVE/API2/Cluster/Mapping/DIR.pm | 299 ++++++++++++++++++++++++++++ > PVE/API2/Cluster/Mapping/Makefile | 3 +- > www/manager6/Makefile | 4 + > www/manager6/Utils.js | 1 + > www/manager6/dc/Config.js | 10 + > www/manager6/dc/DIRMapView.js | 50 +++++ > www/manager6/form/DIRMapSelector.js | 63 ++++++ > www/manager6/qemu/HardwareView.js | 19 ++ > www/manager6/qemu/VirtiofsEdit.js | 120 +++++++++++ > www/manager6/window/DIRMapEdit.js | 186 +++++++++++++++++ > 11 files changed, 761 insertions(+), 1 deletion(-) > create mode 100644 PVE/API2/Cluster/Mapping/DIR.pm > create mode 100644 www/manager6/dc/DIRMapView.js > create mode 100644 www/manager6/form/DIRMapSelector.js > create mode 100644 www/manager6/qemu/VirtiofsEdit.js > create mode 100644 www/manager6/window/DIRMapEdit.js >