Nico

> My problem is with the API itself: Putting the VMID range into cluster id works for your usecase, but other people may have different use cases. The only sensible...

> @rybnico what is missing here! From my point of view, everything is done. @65278 requested a change [here](https://github.com/ionos-cloud/cluster-api-provider-proxmox/pull/286#pullrequestreview-2324931288), I'm still waiting for feedback.

> However, I noticed the Control plane machines starts from `start+1` I tested again with the following settings: Control plane: ```yaml vmIDRange: end: 1009 start: 1000 ``` Worker nodes: ```yaml...

> after your last commit the `vmidRange` doesn't even work now, I have renamed all occurrences of `vmidRange` to `vmIDRange` - did you adjust the CRDs and CRs before your...

> that's what i got. I cannot reproduce the issue. When I create a new VM, the controller reliably picks the first free VM ID from the `vmIDRange`, on both...

@mcbenjemaa Have you had a chance to test this again with debug output enabled? Is there anything I can do to help you test this branch?

> Testing with VMIDRanges is okay. But, without ranges, there's something strange! Ok, I will also test without VMIDRanges. Can you be a bit more specific about "something strange"?

@mcbenjemaa I can't see from the logs why the e2e tests failed. The logs from the Proxmox cluster would be interesting, though: > STEP: Dumping logs from the "capmox-e2e-rzk79z" workload...

> I never faced such issue before. With the `TrafficPolicy: Cluster` k8s automatically marks a pod as unavailable, and traffic is redirected by the node's kube-proxy to another node. If...

> A new pool member receives the traffic immediately independently on the healthcheck results. This is true for OpenStack Amphora and for F5 Octavia backends/drivers. Other backends/drivers should follow the...