From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 7DCE01FF183 for ; Wed, 30 Jul 2025 11:13:33 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D71EA37760; Wed, 30 Jul 2025 11:14:56 +0200 (CEST) Date: Wed, 30 Jul 2025 11:14:50 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20250729111557.136012-1-w.bumiller@proxmox.com> <20250729111557.136012-9-w.bumiller@proxmox.com> In-Reply-To: <20250729111557.136012-9-w.bumiller@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1753866745.g9x7g1ei7p.astroid@yuna.none> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1753866883239 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.046 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH storage 08/26] prepare for vm-vol and ct-vol content and vtypes 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: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On July 29, 2025 1:15 pm, Wolfgang Bumiller wrote: > Prepares the stoplevel PVE::Storage API updates as well as adding the > new vtype subdirs to the base plugin's vtype subdir hash. > > The new types are "vm-vol" and "ct-vol". They represent VM and > container volumes, respectively. The "images" and "rootdir" types are > considered legacy/deprecated, as the "rootdir" type was not properly > used, and container volumes were technically of type "images", with > the "rootdir" case "hacked in" by checking the existing VMs. > > To more easily transition, the "images" type is now also a "supertype" > of "vm-vol", and the "rootdir" type a "supertype" of "ct-vol". > > - `get_images_dir()` is replaced by `get_vm_volume_dir()` > - `get_private_dir()` is dropped as it is an openvz leftover > - `get_ct_volume_dir()` is added its stead > > We now also unify the vtypes and content types. As such, > `content-dirs` can now include separate dirs for `vm-vol` and > `ct-vol`. > This is now also taken into account in `path_to_volume_id()` which > tries to match file system paths to a storage and content type. > > The following subs also get a $vtype parameter: > - `vdisk_alloc()` alloc requires it > - `vdisk_clone()` > - `volume_import()` these two don't. should we make vdisk_clone also require it? or should we remove it altogether and always use the vtype of the base volume? for import we probably want to make it optional for now to support old nodes triggering it.. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel