kubevirt: Multicast traffic cannot pass through bridge of virt-launcher pod.
Is this a BUG REPORT or FEATURE REQUEST?:
Uncomment only one, leave it on its own line:
/kind bug
/kind enhancement
What happened: Multicast traffic can not pass from/to VM via virt-launcher pod network. What you expected to happen: All kind of traffic can pass transparently from/to VM via virt-launcher pod network How to reproduce it (as minimally and precisely as possible): Create 2 VM and configure direct L2 link between them, use connection type ‘bridge’ and configure some multicast protocol(LLDP for example). You will see that traffic goes out of VM but doesn’t pass via virt-launcher pod. Anything else we need to know?: Possible solution is to add following flag into virt-launcher pod bridge echo 65528 > /sys/class/net/virbr0/bridge/group_fwd_mask Environment:
- KubeVirt version (use
virtctl version): Client Version: version.Info{GitVersion:“v0.16.0”, GitCommit:“06d91198bededc7a9353ac774221c83580ee3373”, GitTreeState:“clean”, BuildDate:“2019-04-05T15:24:49Z”, GoVersion:“go1.11.5”, Compiler:“gc”, Platform:“linux/amd64”} Server Version: version.Info{GitVersion:“v0.16.0-gb37c22bbf”, GitCommit:“$Format:%H$”, GitTreeState:“”, BuildDate:“2019-04-18T08:47:30Z”, GoVersion:“go1.11.5”, Compiler:“gc”, Platform:“linux/amd64”} - Kubernetes version (use
kubectl version): [root@zeus06 cnv-tests]# kubectl version Client Version: version.Info{Major:“1”, Minor:“10+”, GitVersion:“v1.10.0+d4cacc0”, GitCommit:“d4cacc0”, GitTreeState:“clean”, BuildDate:“2018-12-06T18:30:39Z”, GoVersion:“go1.11.2”, Compiler:“gc”, Platform:“linux/amd64”} Server Version: version.Info{Major:“1”, Minor:“12+”, GitVersion:“v1.12.4+0ba401e”, GitCommit:“0ba401e”, GitTreeState:“clean”, BuildDate:“2019-03-31T22:28:12Z”, GoVersion:“go1.10.8”, Compiler:“gc”, Platform:“linux/amd64”} - VM or VMI specifications: VM-A
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
metadata:
name: vma
namespace: myproject
spec:
running: false
template:
spec:
domain:
devices:
disks:
- name: containerdisk
disk:
bus: virtio
- name: cloudinitdisk
disk:
bus: virtio
interfaces:
- name: default
bridge: {}
- name: br1
bridge: {}
resources:
requests:
memory: 1G
cpu:
cores: 2
volumes:
- name: containerdisk
containerDisk:
image: kubevirt/fedora30-cloud-container-disk-demo:latest
- name: cloudinitdisk
cloudInitNoCloud:
userData: |-
#cloud-config
password: fedora
chpasswd: { expire: False }
networks:
- name: default
pod: {}
- multus:
networkName: br1
name: br1
VM-B
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
metadata:
name: vmb
namespace: myproject
spec:
running: false
template:
spec:
domain:
devices:
disks:
- name: containerdisk
disk:
bus: virtio
- name: cloudinitdisk
disk:
bus: virtio
interfaces:
- name: default
bridge: {}
- name: br1
bridge: {}
resources:
requests:
memory: 1G
cpu:
cores: 2
volumes:
- name: containerdisk
containerDisk:
image: kubevirt/fedora30-cloud-container-disk-demo:latest
- name: cloudinitdisk
cloudInitNoCloud:
userData: |-
#cloud-config
password: fedora
chpasswd: { expire: False }
networks:
- name: default
pod: {}
- multus:
networkName: br1
name: br1
- Cloud provider or hardware configuration: Hardware
- OS (e.g. from /etc/os-release): cat /etc/os-release NAME=Fedora VERSION=“29 (Twenty Nine)” ID=fedora VERSION_ID=29 VERSION_CODENAME=“” PLATFORM_ID=“platform:f29” PRETTY_NAME=“Fedora 29 (Twenty Nine)” ANSI_COLOR=“0;34” LOGO=fedora-logo-icon CPE_NAME=“cpe:/o:fedoraproject:fedora:29” HOME_URL=“https://fedoraproject.org/” DOCUMENTATION_URL=“https://docs.fedoraproject.org/en-US/fedora/f29/system-administrators-guide/” SUPPORT_URL=“https://fedoraproject.org/wiki/Communicating_and_getting_help” BUG_REPORT_URL=“https://bugzilla.redhat.com/” REDHAT_BUGZILLA_PRODUCT=“Fedora” REDHAT_BUGZILLA_PRODUCT_VERSION=29 REDHAT_SUPPORT_PRODUCT=“Fedora” REDHAT_SUPPORT_PRODUCT_VERSION=29 PRIVACY_POLICY_URL=“https://fedoraproject.org/wiki/Legal:PrivacyPolicy”
- Kernel (e.g.
uname -a): 5.0.6-200.fc29.x86_64 #1 SMP Wed Apr 3 15:09:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux - Install tools:
- Others:
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 17 (17 by maintainers)
Update: I take a look on this and the problem is because the pod is not privileged we can’t change the file
group forward maskfor the bridge.error output:
I think we should consider to back into @rmohr Idea to move the network preparation into the virt-handler. PR: https://github.com/kubevirt/kubevirt/pull/1404
@vladikr @booxter @phoracek @dankenigsberg what you think about that?