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 D5003BF2D for <pve-devel@lists.proxmox.com>; Wed, 13 Sep 2023 15:05:11 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B58FF1E93A for <pve-devel@lists.proxmox.com>; Wed, 13 Sep 2023 15:05:11 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Wed, 13 Sep 2023 15:05:10 +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 CC5EA46EC0; Wed, 13 Sep 2023 15:05:09 +0200 (CEST) Message-ID: <e2293496-8e93-d42a-bf7a-316ac6b8ee8e@proxmox.com> Date: Wed, 13 Sep 2023 15:05:09 +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> From: Stefan Hanreich <s.hanreich@proxmox.com> In-Reply-To: <5708827d07ec44793cccda18d75a66562a093bc0.camel@groupe-cyllene.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.189 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: Wed, 13 Sep 2023 13:05:11 -0000 On 9/13/23 14:50, DERUMIER, Alexandre wrote: > Le mercredi 13 septembre 2023 à 13:50 +0200, Stefan Hanreich a écrit : >> >> >> That way we could also easily add a IP configuration section to the >> VM > > > I really don't known if it's the best/easiest way to have ip both in > ipam && vm config. > > I have sent ipam vm|ct 1 or 2 year ago, and their are a lot of corner > cases (snapshots / backup restore with an ip different than ipam for > example). > > > But it's avoid to call ipam at vm_start. (and could be used for > firewall to auto generate ip filtering) > Maybe setting it there could just be an interface for setting it in the IPAM manually? But yes, the snapshots / backup cases certainly requires some thought. Another thing I was thinking about: When we create a mapping on start / stop we will also have to consider DHCP lease time and cannot immediately re-use the IP (which is actually quite likely if IPAM always just returns the next IP in the list). We will have to take into account the DHCP lease time in our pve IPAM implementation and reserve the IP accordingly. For dnsmasq, the dhcp hookscripts might come in handy in that case so we know the exact expiration time. As Thomas already mentioned, time drift in VMs (e.g. after hibernation) can also cause real issues here.. We would also need some kind of mechanism for cleaning expired entries automatically, otherwise local pve IPAM becomes cluttered. As far as I can tell, Kea + NetBox integration already supports DHCP reservations, so we should be fine on that front.