From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 9EEB21FF165 for ; Thu, 17 Jul 2025 17:41:05 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 917F43F681; Thu, 17 Jul 2025 17:42:10 +0200 (CEST) Date: Thu, 17 Jul 2025 16:42:06 +0100 To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" References: <20250709162202.2952597-1-alexandre.derumier@groupe-cyllene.com> <45f99f85-19e2-497e-96b4-c22b9a33de6a@proxmox.com> <1fddff1a-b806-475a-ac75-1dd0107d1013@eurotux.com> <47b76678f969ba97926c85af4bf8e50c9dda161d.camel@groupe-cyllene.com> In-Reply-To: <47b76678f969ba97926c85af4bf8e50c9dda161d.camel@groupe-cyllene.com> MIME-Version: 1.0 Message-ID: List-Id: Proxmox VE development discussion List-Post: From: Tiago Sousa via pve-devel Precedence: list Cc: Tiago Sousa X-Mailman-Version: 2.1.29 X-BeenThere: pve-devel@lists.proxmox.com List-Subscribe: , List-Unsubscribe: , List-Archive: Reply-To: Proxmox VE development discussion List-Help: Subject: Re: [pve-devel] [PATCH-SERIES v8 pve-storage/qemu-server] add external qcow2 snapshot support Content-Type: multipart/mixed; boundary="===============7715644060426480248==" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" --===============7715644060426480248== Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: pve-devel@lists.proxmox.com Delivered-To: pve-devel@lists.proxmox.com 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 64F5BCA34E for ; Thu, 17 Jul 2025 17:42:09 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 457DF3F627 for ; Thu, 17 Jul 2025 17:42:09 +0200 (CEST) Received: from eurotux.com (mail.eurotux.com [185.98.249.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 17 Jul 2025 17:42:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by eurotux.com (Postfix) with ESMTP id 0E21930C830E; Thu, 17 Jul 2025 16:42:08 +0100 (WEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eurotux.com; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject :user-agent:mime-version:date:date:message-id; s=default; t= 1752766927; x=1754581328; bh=/WpGRGXWGFJup/c+YjdPzdeaHQVDKVscRqI HvIQP7jo=; b=BIm3ek0BRcCzAA9D6fDuQRehLEwIWQ5nIuw36ZKBLdqBrjFeUC/ WMWmBPI2wmfQHlWzWXKk/egtxd6irPtGGGnCUspOizlNsZhrw5Ed0LLqkANnSY5b YAyzRCH7Sv85MhaqynOY7HVcidGnepHS+obya4zPUiDqm+YYvuyvFMSSbGmRCBOH nZaAizJ9/YhTtsm7FM6kuf1CfcXwZ3EBldbnA9Wee4jEVCFH/owaPjaSAaBXWSsH lMedkM1AMvmPzltL1u8dWhi5hZeq+5x+x0szcc+f9TkIy8MLQhuUos3HRI+xyvLF E0d0W1PK1ZY5tFTeln7PRcMEhmUMScRVokg== X-Virus-Scanned: amavisd-new at mail.prd.eurotux.pt Received: from eurotux.com ([127.0.0.1]) by localhost (mail.prd.eurotux.pt [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6jAHbnHK26TG; Thu, 17 Jul 2025 16:42:07 +0100 (WEST) Received: from [192.168.1.213] (unknown [161.230.225.89]) (Authenticated sender: joao.sousa@eurotux.com) by eurotux.com (Postfix) with ESMTPSA id 39ACA30CCA6B; Thu, 17 Jul 2025 16:42:07 +0100 (WEST) Message-ID: <58c2db18-c2c2-4c91-9521-bdb42a302e93@eurotux.com> Date: Thu, 17 Jul 2025 16:42:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [pve-devel] [PATCH-SERIES v8 pve-storage/qemu-server] add external qcow2 snapshot support To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" References: <20250709162202.2952597-1-alexandre.derumier@groupe-cyllene.com> <45f99f85-19e2-497e-96b4-c22b9a33de6a@proxmox.com> <1fddff1a-b806-475a-ac75-1dd0107d1013@eurotux.com> <47b76678f969ba97926c85af4bf8e50c9dda161d.camel@groupe-cyllene.com> Content-Language: en-US From: Tiago Sousa In-Reply-To: <47b76678f969ba97926c85af4bf8e50c9dda161d.camel@groupe-cyllene.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.101 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_MSPIKE_H2 0.001 Average reputation (+2) 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_PASS -0.001 SPF: HELO matches SPF record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [eurotux.com] On 7/17/25 16:08, DERUMIER, Alexandre wrote: >>> >>> However I have some questions: >>> >>> 1. When qmeventd receives the BLOCK_WRITE_THRESHOLD event, should the >>> extend request (writing the nodename to the extend queue) be handled >>> directly in C, or would it be preferable to do it via an API call >>> such >>> as PUT /nodes/{node}/qemu/{vmid}/extend_request, passing the nodename >>> as >>> a parameter? > > I think that qemevent should be as fast as possible. For my first > version, I was doing an exec of "qm extend ....", but I think it should > be even better if qmevent is simply write vmid/diskid in a text file > somewhere in /etc/pve. (the the other daemon can manage the queue) Ok, are you thinking of having a local queue for each node as well? since if there was a single queue for all nodes how would you manage the concurrency of writes of each node? (is there a similar function to cfs_lock_file but for C code?) >>> 2. If we use a local daemon for each node how is it decided which >>> node >>> will preform the extend operation? >>> Another option is to use a centralized daemon (maybe on the quorum >>> master) that performs every extend. > The local daemon where the vm is running should resize the lvm, because > if the resize is done on another node, the lvm need to be > rescan/refresh to see the new size. AFAIK, It's not done automatically. Ok, at first I was thinking of doing a FIFO like cluster wide queue where the extends would be done in the order of arrival. But if I'm understanding correctly, by doing a local queue and extend daemon, the extends would be done in order but not in a global cluster sense right? Where each extend daemon would be competing to acquire the storage lock to proceed with the next extend. Please let me know if I'm understanding your idea correctly. >>> 3. Is there any specific reason for the event only be triggered at >>> 50% >>> of last chunk, in your implementation? I was thinking of implementing >>> it >>> with 10% of the current provisioned space to be safe. Any options on >>> this? > > I have use same implementation than redhat, but it could be some > tunable value. It's really depend of how much fast is your storage. > as far I remember, it's was 50% of the size of the chunk (1GB). > so when you have 500MB free, it should add another 1GB. > > of course, if you have fast nvme, and you write 2GB/s, it'll be too > short. > > > if you go with 10% of provisionned, if you have 2TB qcow2, it'll > increase when 200GB is free. (and how much do we want to increase ? > another 10% ? ) > > but if you want 2GB qcow2, it'll increase when 200MB is free. > so, we a fast nvme, it could not work with small disk, but ok with big > disk. > I think that's why redhat use percent of fixed chunksize (that you can > configure depending of your storage speed) You're right that way makes the most sense. --===============7715644060426480248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel --===============7715644060426480248==--