This message was deleted.

Is there any DHCP server for your vlan network? If not, it should be ok to manually configure that interface on the guest VM.

There is, but it only provides IPs in the 50-150 range. So I figure I should be okay with setting a manual IP with .20 for example

I don’t need to create another cluster network for the second vlan in order to use it?

Yeah, I think so. I am not sure about how to avoid the DHCP in your case. cc @red-king-19196, @faint-art-23779 did you have any thoughts?

The really weird bit is that when I create the cluster network, I need to add 2 configs since the 2 nodes have differently named interfaces. But the moment I add the network config, the interface stops working - in the sense that from the node, I cannot ping the gateway (for example) And unlike the mgmt-br interface, which "claims" eth0 and takes the IP from it, the newclusterntwrk-br interface doesn't claim the ethernet port

Hi @powerful-easter-15334 Could you attach the support bundle file so we can examine your network setup, including the cluster network and other relevant configurations? If the new cluster network’s bridge does not contain the uplink interface, it cannot form a “cluster-wide” network.

Hello. Yep, I'll take care of that in a moment

I’m currently loading the support bundle into my simulator. In the meantime, I’d like to clarify some points:

Now I have a VM running which got an IP from the DHCP server (even though I set it to manual, but whatever, doesn’t matter)

If I understand correctly, you’re saying you created a VM Network with the

manual

route mode selected. This, by design, has nothing to do with the external DHCP server. Harvester is incapable of managing the DHCP server running outside of the cluster. The

manual

here is just a way for the user to provide the route information about the to-be-created VM Network. So IMO it’s expected that the VM still gets the IP address from the DHCP server. From the output of the

ip link

command provided above, it looks like all the network interfaces and devices were created correctly. It seems you’re performing manual configurations against the network that the Harvester network controller should manage. Would you please describe what you want to achieve? I’d like to know about it and see how we can help, at least with the existing capability of the Harvester network controller without any manual configs.

Ohh, so that's what manual means in this scenario. Okay, the manual config was because when I created the cluster network, and affiliated network configs, I expected harvester to auto-create the configs for eno4, and the trunk-br and trunk-bo interfaces. I found it weird that it didn't so I tried a workaround. Now I copied the eno1 and mgmt-br/bo configs, and the connection appears to be working. I will try creating a VM and namespaces, and more things to test in a minute - lunch takes priority 🙂

Hmm, that’s odd. When you create the

trunk

ClusterNetwork and associated VlanConfig objects (equivalent to the “Network Config” on the dashboard), behind the scenes, the Harvester network controller will set the uplink interface’s master to

trunk-bo

and attach it to the

trunk-br

. You don’t have to manually create and configure them. Do you mean the above did not happen?

It created them, yes. But there was no IP. With the mgmt network, 'ip a' shows the IPs associated with the mgmt-br (or bo, I forgot) interface. There was no IP associated with the corresponding trunk interface

I see. Other than the

mgmt-br

, bridges created by the Harvester network controller won’t have any IP addresses assigned. This is by design and is expected. Harvester constructs L2 networks that span all nodes so that VMs can run on top of them. If you want to let the VMs on a specific VM Network communicate freely with the management network, you’ll have to make these two networks “routable” in your network infrastructure, and this is out of Harvester’s control. For instance, when the VM wants to communicate with the Harvester VIP, the traffic should be sent from the VM, through the L2 VM Network, and routed by the gateway, to the management network. We architected the cluster network like this, so there’s no need to bind IP addresses on bridges other than

mgmt-br

.

Alright, it got very complex very fast. Is there a particular reason why the trunk-* networks might show as Down when I run 'ip a"

It’s okay. Do you mean the command output you posted above?

Okay okay. Thank you very much for your explanations, I'm understanding a lot more of what Harvester does and why I'll test quickly with my manual config just for sanity, then wipe it back to default and go from there again

Sure, if you find something weird, just ask in the channel. We’re glad to help 🙂

Thank you so much for the help

Things are getting better 😄 So, the route connectivity of the VM Network is

inactive

, which is the culprit for the communication issue between the VM and the host. The VM Network must be routeable from the management network via the gateway. Is the gateway outside the Harvester cluster? Or is it another VM running on the Harvester cluster? Regarding the VLAN, is it a tagged (trunk mode) or untagged (access mode) VLAN on the switch side? If it’s the latter one, no matter what the VLAN ID is in your physical network, you’ll need to create the VM Network with VLAN ID 1 (or choose the “Untagged Network” type).

The gateway is outside the cluster. I have H1 and H2 on 10.5.106.10 and 11 respectively. The gateway is .254 I have the DHCP to give VMs .50-150 I tried both with tagged and untagged networks - same result (though maybe I should delete the tagged when testing untagged) And finally, it should be fine to just have that VM network, and not have the mgmt network at all?

And finally, it should be fine to just have that VM network, and not have the mgmt network at all?

If you’re not planning to use the Rancher Integration and load balancer features, then yes, you can totally ignore the route connectivity issue.

@red-king-19196 I got back to the office to bother my network guy. Thank you a ton, it works great now!