From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 492F61FF15C for <inbox@lore.proxmox.com>; Wed, 26 Mar 2025 12:42:22 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9F25535A29; Wed, 26 Mar 2025 12:42:15 +0100 (CET) Message-ID: <b94f52e3-c579-456a-9ed9-684ddb03fde0@proxmox.com> Date: Wed, 26 Mar 2025 12:41:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Dominik Csapak <d.csapak@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20250325151421.3182493-1-d.csapak@proxmox.com> <8c06736a-abaf-42d5-9c56-cca185d30aee@proxmox.com> <8af44d26-f1ea-4272-b94a-d6540d02249f@proxmox.com> Content-Language: en-US From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <8af44d26-f1ea-4272-b94a-d6540d02249f@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.040 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/manager v3] allow upload & import of qcow2 in the web UI X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> Am 26.03.25 um 11:47 schrieb Dominik Csapak: > On 3/26/25 11:37, Fiona Ebner wrote: >> Am 25.03.25 um 16:14 schrieb Dominik Csapak: >>> most of the building blocks are already there: >>> * we can have qcow2 files in an import storage >>> * we can import qcow2 files via the api from such a storage >>> >>> this series fills in the missing bits & pieces: >>> * allow uploading qcow2 files into an import storage via the webgui >>> * adding the possibility to select such a file when creating a vm/disk >>> >>> We could maybe also allow this for raw/vmdk if we want to, but IMHO >>> we can start out with qcow2 and add the others as necssary. >>> >>> (if wanted, I can of course also add the others in a next version or as >>> a follow up) >> >> >> Yes, please! It would be nice to have all three at the same time. Or is >> there any specific reason why you limit it to qcow2? Otherwise, users >> will just ask why support for these is missing right away. > > No specific reason, it was just easier/quicker to implement one first. > When we also allow raw files, > should we also allow other extensions than '.raw'? not sure if there is > one that > is often used (since I think '.raw' is more a PVE thing) > Right, raw is actually a bit of a headache because of that :P We could either: 1) have a list of common extensions for raw: .raw/.img/etc 1b) also treat files without extension as raw? 2) have a list of known extensions that are not raw and treat everything else as raw, while logging an informational message I'd prefer 1), because we already require specific extensions for other uploads. And likely we want to rename after/during upload, so images that are raw for us always have a ".raw" extension? Otherwise, we need to be careful enough to enforce the very same rules when parsing the import volume name and thus mostly also have them set in stone for the future. The advantage of the latter would be for the use case where one wants to manually make accessible their already existing image folders without using the API. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel