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 BEEE21FF173 for <inbox@lore.proxmox.com>; Mon, 10 Mar 2025 15:40:21 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A51321C0F1; Mon, 10 Mar 2025 15:40:12 +0100 (CET) Message-ID: <32fea49a-33fb-4cc2-bb45-d4a8f586a960@proxmox.com> Date: Mon, 10 Mar 2025 15:40:09 +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: <20250213131716.3062383-1-d.csapak@proxmox.com> <20250213131716.3062383-17-d.csapak@proxmox.com> <ad55dab2-8218-4063-9e8b-1a76963d6fe8@proxmox.com> <ccfe0047-532a-438c-99d4-10d98e7f86f6@proxmox.com> <1d517e49-f23a-445f-9918-3dedc11115ee@proxmox.com> <7fcbda4d-008d-4642-8174-cfa16ba6896b@proxmox.com> <52d449b0-01a9-49c4-8ec1-b1b8747ea264@proxmox.com> Content-Language: en-US From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <52d449b0-01a9-49c4-8ec1-b1b8747ea264@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.041 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 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 manager v6 3/5] bulk migrate: include checks for live-migratable local resources 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 10.03.25 um 14:58 schrieb Dominik Csapak: > On 3/10/25 14:21, Fiona Ebner wrote: >> Am 10.03.25 um 13:52 schrieb Dominik Csapak: >>> hmm i can try that, but i have a question on how to handle some >>> situations: >>> >>> there are the following possibilities (if I didn't forget one): >>> * non-mapped hostpci device -> local resource >>> * mapped hostpci device with no live migration capabilities -> local >>> resource + mapped >> >> I'd only add it to local resources if $state is set too, i.e. if it is a >> live migration. If it's mapped and if it's an offline migration, don't >> add it. >> >>> * mapped hostpci device with live migration capabilities -> mapped only >>> >>> did I understand you correctly? >>> >> >> I.e. local resources should only contain the config keys that are actual >> blockers for the migration at hand, which differs when it's online or >> offline. > > > ok makes sense, did a quick test here, and it seems the UI handles it > already gracefully, > (we ignore the local_resources for mapped devices alread) but wouldn't > that be a 'breaking' change, > since we did return the devices in the 'local_resources' list until now? > > I'm not saying that the change would be bad, but the current description > and results would not > indicate to an api user that it's only for blocking migrations, as the > current description is > "List local resources e.g. pci, usb" It comes down to arguing what "local" means in this context. One could argue that a mapped device is a logical abstraction over equivalent devices on multiple nodes and thus not local in that sense. Looking at the API endpoint naively, I would intuitively expect local_resources and mapped-resources to be disjoint. Regarding breakage, you do have a point. If a consumer is relying only on local_resources and not looking at the mappings, or using the keys from local resources to try to iterate over the mappings, the precondition check would be wrong in the case of missing mappings. IMHO we can go for this, as it's only the precondition check, migration will just fail later for such API consumers. We can make the description more precise, i.e. mention these are the local resources that cannot be migrated, do not include mapped resources and they can be different for offline vs. online. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel