Description of problem: Original bug: https://github.com/kubevirt/kubevirt/issues/1494 When you create a bridge device it initially has a MAC address of all zeros, and when you add NIC devices to the bridge, its MAC address gets update to the numerically lowest MAC address of all the NICs. The problem is that when the kernel assigns MAC addresses randomly, one of these random MAC address might be numerically lower than the bridge's current MAC address. So the effect is that when you start/stop guests, and their TAP devices get added/removed from the bridge, the bridge's own MAC address will occassionally change which is a bad thing. So deal with this, libvirt will set all guest TAP devices so that they have a MAC address with 0xFE as the first byte. The real physical NIC added to the bridge is thus guaranteed to have a smaller MAC address, and so the bridge will permanently use the MAC address of the physical NIC, which is what we want. For bridges which do not have any physical NIC, libvirt will create a dummy TAP device, not connected to any guest, and give it a small MAC address. This ensures again ensures the bridge MAC address won't change when guests start/stop. With ovs-cni, we create a pod interface (later connected to the bridge) with random MAC address. If this address happens to start with FE:, qemu fails. Version-Release number of selected component (if applicable): ovs-cni 0.1 How reproducible: Raceful. One need to get "lucky" to get MAC with fe: prefix. Steps to Reproduce: 1. KubeVirt, Multus and OVS CNI installed 2. Start VM with ovs-cni network requested 3. In some cases it should "randomly" fail Actual results: qemu process fails to start. Error: unsupported configuration: Unable to use MAC address starting with reserved value 0xFE Pod interface MAC address starting with reserved value 0xFE. Expected results: Pod interface should get MAC outside this reserved pool and qemu should start successfully. Additional info: Fixed with https://github.com/kubevirt/ovs-cni/pull/19
This happens in 2% of cases when starting VMI with secondary network. It blocks VMI startup right at the beginning, so recreating should be enough to start successfully. Lowering severity. And setting target release to 1.2.1.
Meni, as https://trello.com/c/vibfiWGo/198-epic-l2-connectivity-ovs-cni-exculde-fe-mac-from-veth-range was accepted, I think this should be declared VERIFIED
Agree.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:3776