[BUG] The bridge MTU is not changed

[yaocw2020]

Describe the bug

To set the MTU to 9000, but the Harvester is defaulting to 1500.

To Reproduce
Steps to reproduce the behavior:

1. Create a cluster network and add a network config where the MTU of the uplink is set as 9000.
2. Create a VM network under this cluster network.
3. Create a VM using the VM network.
4. Check the related bridge. You will see the MTU of the bridge is still 1500 but the bond's is 9000.

Expected behavior

The bridge MTU should be the configured value.

Support bundle

Environment

• Harvester ISO version: v1.1.2
• Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): Baremetal with Dell PowerEdge R630

Additional context
Add any other context about the problem here.

[harvesterhci-io-github-bot]

added backport-needed/1.1.3 issue: #4364.

[guangbochen]

@yaocw2020 please help create a new enhancement issue to track the proposed design changes in v1.3.0(may consider backporting to v1.2.1)

[yaocw2020]

@yaocw2020 please help create a new enhancement issue to track the proposed design changes in v1.3.0(may consider backporting to v1.2.1)

#4355

[harvesterhci-io-github-bot]

Pre Ready-For-Testing Checklist

* [ ] If labeled: require/HEP Has the Harvester Enhancement Proposal PR submitted?
The HEP PR is at:

• Where is the reproduce steps/test steps documented?
  The reproduce steps/test steps are at: [BUG] The bridge MTU is not changed #4353 (comment)

• Is there a workaround for the issue? If so, where is it documented?
  The workaround is at: [BUG] The bridge MTU is not changed #4353 (comment)

• Have the backend code been merged (harvester, harvester-installer, etc) (including backport-needed/*)?
  The PR is at: Sync MTU value to NAD network-controller-harvester#87

  • Does the PR include the explanation for the fix or the feature?

  * [ ] Does the PR include deployment change (YAML/Chart)? If so, where are the PRs for both YAML file and Chart?
  The PR for the YAML change is at:
  The PR for the chart change is at:

* [ ] If labeled: area/ui Has the UI issue filed or ready to be merged?
The UI issue/PR is at:

* [ ] If labeled: require/doc, require/knowledge-base Has the necessary document PR submitted or merged?
The documentation/KB PR is at:

* [ ] If NOT labeled: not-require/test-plan Has the e2e test plan been merged? Have QAs agreed on the automation test case? If only test case skeleton w/o implementation, have you created an implementation issue?
- The automation skeleton PR is at:
- The automation test case PR is at:

* [ ] If the fix introduces the code for backward compatibility Has a separate issue been filed with the label release/obsolete-compatibility?
The compatibility issue is filed at:

[harvesterhci-io-github-bot]

Automation e2e test issue: harvester/tests#909

[yaocw2020]

Workaround:

Case1: select the cluster network as the storage network.

1. stop all VMs since we need to update the storage network
2. backup the storage-network setting

   kubectl get settings.harvesterhci.io storage-network -oyaml > storage-setting.yaml
   

3. check its NAD name and save the related NAD to a yaml file. The NAD name is like storagenetwork-xxxxx.

   kubectl get network-attachment-definition -n harvester-system | grep storagenetwork
   kubectl get network-attachment-definition -n harvester-system $nad -o yaml > storage-nad.yaml
   

4. disable storage network
   a. wait for the longhorn-system's instannce-manager-e , instannce-manager-r and backing image pods to be ready after restart
   b. wait for the pod on cattle-monitoring-system to be ready
   c. the MTU should be reset back to 9000 and you can check it on the host
5. modify the file storage-nad.yaml. Add the MTU to the spec.config and apply the file. The value will be like:

   '{"cniVersion":"0.3.1","type":"bridge","dns":{},"bridge":"test-br","mtu":9000,"promiscMode":true,"vlan":1,"ipam":{"type":"whereabouts","range":"192.168.70.0/24"}}
   

   kubectl apply -f storage-nad.yaml
   

6. delete the fields metadata.creationTimestamp,metadata.generation,metadata.resourceVersion,metadata.uid and status in storage-setting.yaml. Then apply storage-setting.yaml.

   kubectl apply -f storage-setting.yaml
   

7. wait for the longhorn-system and cattle-monitoring-system pods are restarted successfully, and check the host MTU again by ip a| grep storage

Case2: The cluster network is only used for VMs

1. Stop all the VMs.
2. Modify all the VM networks under the cluster network to add MTU value in the spec.config filed.
3. Restart all the VMs.

[albinsun]

Tested in v1.2.0-rc5, close as fixed.

Warning
Test do not cover 1.1.3 backport since not merge yet.
Trace in #4364

Environment

• Harvester
  • Version: v1.2.0-rc5
  • Profile: QEMU/KVM, 3 nodes (8C/16G/250G)
  • ui-source: Auto

Test Cases

Note Click "►" to expand details.

1. Create a cluster network and network config uplink w/ customized MTU. ${~~~\color{green}\textsf{V}}$

   

2. Create a VM network (VLAN & Untagged) under this cluster network. ${~~~\color{green}\textsf{V}}$

   • VLAN 1 & Untagged
     
3. Create vm1/vm2 using the VLAN/Untagged network. ${~~~\color{green}\textsf{V}}$

   • vm1
     
   • vm2
     
4. Check the MTU of the bridge should be the customized value ${~~~\color{green}\textsf{V}}$

   • vm1
     
   • vm2