From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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 ; 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 ; 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: 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" , "pve-devel@lists.proxmox.com" , "t.lamprecht@proxmox.com" References: <20230908134304.2009415-1-s.hanreich@proxmox.com> <2fd1071602ad075d4580d62565fc757e4bd92a91.camel@groupe-cyllene.com> <3e766920-35e9-4acf-a9fa-f3b56fe0408e@proxmox.com> <7980640a-da18-9da7-88cb-f8602c9339d4@proxmox.com> <5708827d07ec44793cccda18d75a66562a093bc0.camel@groupe-cyllene.com> <30aa87542f4b615aa9f1295b170f26eb8c146ba6.camel@groupe-cyllene.com> <87490886980ba3d102cbfa3b40c858fcd9ffdbe7.camel@groupe-cyllene.com> <3105e957-706e-d512-36f5-6ba558b347ef@proxmox.com> From: Stefan Hanreich In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.