Le mercredi 13 septembre 2023 à 10:54 +0200, Stefan Hanreich a écrit : > Sorry for my late reply, I was a bit busy the last two days and I > also > wanted some time to think about your suggestions. > > On 9/11/23 05:53, DERUMIER, Alexandre wrote: > > Hi, > > > > I think we should think how we want to attribute ips to the vms > > before > > continue the implementation. > > > I think they are 2 models: > > > > 1) > > > > - we want that dhcp server attribute itself ips && leases from the > > subnets/ranges configured. > > > > That mean that leases need to be shared across nodes. (from the > > same > > cluster maybe with /etc/pve tricks, but in real world, it should > > also > > works across multiple clusters, as it's not uncommon to shared > > subnets > > in differents cluster, public network,...) > > > > So we don't have that 2 differents vms starting on the same time on > > 2 > > differents cluster, receive the same ips. (so dhcp servers need to > > use > > some kind of central lock,...) > > > > This is also something I have thought about, but I assume dnsmasq is > not > really built in mind with multiple instances accessing the same > leases file. > > This problem would be solved by using distributed DHCP servers like > kea. > kea on the other hand has the issue that it we need to set up a SQL > database or other external storage. Alternatively we need to write a > new > backend for kea that integrates with our pmxcfs.
using pmxcfs could be great for 1 cluster, but if you are multiple clusters sharing same subnet it'll not work. Maybe, for cross-cluster, only ip reservations should be used. and for (dynamic|ephemeral) ip using a subnet specific to the cluster? > > This is partly why I think Thomas mentioned implementing our own DHCP > server, where we have the flexibility of handling things as we see > fit. > > Then we can just recommend the dnsmasq plugin for simple setups (e.g. > single node setups), while more advanced setups should opt for other > DHCP backends. > > > > > 2) > > > > The other way (my preferred way), could be to use ipam. (where we > > already have local ipam, or external ipams like netbox/phpipam for > > sharing between multiple cluster). > > > > > > The ip is reserved in ipam (automatic find next free ip at vm > > creation > > for example, or manually in the gui, or maybe at vm start if we > > want > > ephemeral ip), then registered dns, > > and generated dhcp server config with mac-ip reserversation. (for > > dhcp > > server config generation, it could be a daemon pooling the ipam > > database change for example) > > > > Like this, no need to handle lease sharing, so it can work with any > > dhcp server. > > > > Implementing this via IPAM plugins seems like a good idea, but if we > want to use distributed DHCP servers like kea (or our own > implementation) then this might not be needed in those cases. It also > adds quite a bit of complexity. > > With dnsmasq there is even the possibility of running scripts (via > --dhcp-script, see the docs [1]) when a lease is added / changed / > deleted. But as far as I can tell this can not be used to override > the > IP that dnsmasq provides via DHCP, so it is probably not really > useful > for our use-case. > > ------ (I have sent another mail with more detail of what I was thinking to implement) > > Another method that I had in mind was providing a DHCP forwarding > plugin > that proxies the DHCP requests to another DHCP server (that can then > even be outside the cluster). This way there is only one DHCP server > that handles keeping track of the leases and you do not have the > issue > of having to handle sharing a lease database / using IPAM. So, for > instance, you have a DHCP server running on one node and the other > nodes > just proxy their requests to the one DHCP server. > > I was also thinking we could implement setting the IP for a specific > VM > on interfaces where we have a DHCP server, since we can then just > provide fixed IPs for specific MAC-addresses. This could be quite > convenient. > > I'm always a little bit afraid to use a central dhcp (or a couple in HA) for my production. Because if a problem occur on dhcp when vms are starting after a major outage for example. Personnally, I'm still using static ips in my vms for this. (And also, I'm using multiple datacenters, with public ips range, so 1 central dhcp is really not possible ) > > [1] > https://antiphishing.cetsi.fr/proxy/v3?i=d09ZU0Z5WTAyTG85WWdYbIX9F1yND7gsvpr6o9NYFYg&r=UTEzTUpQcktwRVdhdEg1TKCFOzhw8CGaAiMfyFTpTR_LTspF9zP2JS-LN0ctA-XBzHeMG-sD1OqL3ihNxDMXJg&f=TmtFVlNVNmxSYnFaWFhxYgWRqBlL4orB2JX8m5oXcL1BuLSwOjOIAbslpc0EWkZJ&u=https%3A//thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html&k=DWI7 > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
