From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <s.hanreich@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 6B9BFE8E4 for <pve-devel@lists.proxmox.com>; Tue, 26 Sep 2023 16:12:37 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 54CA62816 for <pve-devel@lists.proxmox.com>; Tue, 26 Sep 2023 16:12:37 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Tue, 26 Sep 2023 16:12:36 +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 1E08F48D4C; Tue, 26 Sep 2023 16:12:36 +0200 (CEST) Message-ID: <a5f92162-2608-52d3-404f-e91a3bae7d78@proxmox.com> Date: Tue, 26 Sep 2023 16:12:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Content-Language: en-US To: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>, "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>, "t.lamprecht@proxmox.com" <t.lamprecht@proxmox.com> References: <20230908134304.2009415-1-s.hanreich@proxmox.com> <2fd1071602ad075d4580d62565fc757e4bd92a91.camel@groupe-cyllene.com> <d047f4fd-bdba-c7d9-64b6-5dfd5e5faccb@proxmox.com> <3e766920-35e9-4acf-a9fa-f3b56fe0408e@proxmox.com> <7980640a-da18-9da7-88cb-f8602c9339d4@proxmox.com> <5708827d07ec44793cccda18d75a66562a093bc0.camel@groupe-cyllene.com> <e2293496-8e93-d42a-bf7a-316ac6b8ee8e@proxmox.com> <30aa87542f4b615aa9f1295b170f26eb8c146ba6.camel@groupe-cyllene.com> <87490886980ba3d102cbfa3b40c858fcd9ffdbe7.camel@groupe-cyllene.com> <3105e957-706e-d512-36f5-6ba558b347ef@proxmox.com> <cef49dd992e40135c64ffef0e7f9f572784900bc.camel@groupe-cyllene.com> From: Stefan Hanreich <s.hanreich@proxmox.com> In-Reply-To: <cef49dd992e40135c64ffef0e7f9f572784900bc.camel@groupe-cyllene.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.161 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 -1.473 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 Subject: Re: [pve-devel] [RFC cluster/manager/network 0/6] Add support for DHCP servers to SDN 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> X-List-Received-Date: Tue, 26 Sep 2023 14:12:37 -0000 > Yes, this is my main concern, as it'll be my case in production, as I > managing multiple clusters, on differents location, with subnets > sharing. > > for me, it's ok if ipam is down when allocating a new ip or vm. > But for vm start/stop, I think we should have at minimum some cache > somewhere. (I'm think about a disaster recovery or big network problem, > where you want to fast restart all vms without need to call the ipam). > > Maybe a way, could be to use the local pve ipam, as a local mirror of > the external ipam ? (and don't store ip in vm config, but only in > pve ipam, the source of truth) > Yes, I think this would be preferrable over the VM config. This also means we would have to sync from netbox to local PVE IPAMs? > I'm a bit busy currently on other stuff and I would like to finish them > first. > > So if you have a little bit time to work on this, it could be great :) > > I have send some patches in 2021 for ipam integration in qemu/lxc, if > you want to take some inspiration. (without the ip in the vm config, it > should be a lot easier) > I'll try to get on it then, I'll still be here for 2,5 weeks until I go on a longer vacation. Hopefully I'll get something workable ready until then. I will look into your patches - thanks for the hint! > Yes,admin should be able to see allocated ip. (like a real ipam). > > I was thinking about other stuff for later, but maybe it could be great > for an admin to be able to reserve ips and put them in a pool. > Then user could choose ip from this pool. > > (Usecase is public ip addresses, where a customer could buy some of > them, > then allocated them like he want) > That sounds like a great feature for hosters, I'll certainly look into that.