This message was deleted.

I'm still really stuck on this. I'll try to expand on what's wrong. For one, dhcp options don't seem to work at all. There's multiple VM networks in Harvester, all of which can get dhcp to VMs, There doesn't seem to be any indicator or documentation of exactly which networks the LB will use to get a LB address. There is an option for that within the IP Pools. However the IP addresses aren't reachable from outside of the node (

arping

or

ip neigh

only shows a result on 1 node) Other IP addresses from the same VLAN/VM Network can be reached from inside/outside the cluster. I would have guessed that that would qualify as "*you must provide a route from outside to the LB address*" but clearly it's not working. What does "The VM LB Address is exposed withing the same network as the Harvester Hosts" mean? The mgmt network? VM Networks? Something else?

that sounds like the management network. It seems like it's a general statement that's normal for any machine hosting a service on a private network.

There's also host networks, but in other places in the docs it's pretty clear when they mean the mgmt network vs others. Also confusing as most of the issues with the LB reference external IPs.

.

I think it’ll be easier to illustrate those sentences with a concrete example. Let’s say my Harvester hosts reside on

192.168.0.0/24

, and the VM Network is

192.168.10.0/24

. When I create a load balancer with DHCP IPAM selected, a macvlan interface is created by kube-vip to get an IP address via DHCP. kube-vip, by default, works on the host’s network interface with a default gateway configured, which is

mgmt-br

. That means the retrieved IP address will be in the

192.168.0.0/24

subnet. On the other hand, if I create a load balancer with Pool IPAM selected (assume the pool range is

192.168.20.0/24

), the allocated IP address will be added to

mgmt-br

. So the potential problem is that if someone outside of the premises wants to access the LB IP address, the routes must be configured correctly; otherwise, they’ll get a “host unreachable” error. That’s for the Pool IPAM case and only applies when you use a subnet different from the Harvester hosts.