(copied verbatim from the patch that fixes the bug) Back in July 2010, commit 6ea90b84 (meant to resolve https://bugzilla.redhat.com/571991 ) added code to set the MAC address of any tap device to the associated guest interface's MAC, but with the first byte replaced with 0xFE. This was done in order to assure that 1) the tap MAC and guest interface MAC were different (otherwise L2 forwarding through the tap would not work, and the kernel would repeatedly issue a warning stating as much). 2) any bridge device that had one of these taps attached would *not* take on the MAC of the tap (leading to network instability as guests started and stopped) A couple years later, https://bugzilla.redhat.com/798467 was filed, complaining that a user could configure a tap-based guest interface to have a MAC address that itself had a first byte of 0xFE, silently (other than the kernel warning messages) resulting in a non-working configuration. This was fixed by commit 5d571045, which logged an error and failed the guest start / interface attach if the MAC's first byte was 0xFE. Although this restriction only reduces the potential pool of MAC addresses from 2^46 (last two bits of byte 1 must be set to 10) by 2^32 (still 4 orders of magnitude larger than the entire IPv4 address space), it also means that management software that autogenerates MAC addresses must have special code to avoid an 0xFE prefix. Now after 7 years, someone has noticed this restriction and requested that we remove it, i.e. they want libvirt to permit guest interfaces with a MAC address that starts with 0xFE.
The fix is that when we check for an FE prefix in the guest MAC address, instead of failing, we should instead just use a prefix of 0xFA for the tap device. A fix has been pushed upstream, and will be in libvirt-5.7.0: commit a60ee914009aa7f1a27fc0563337ded08b09247f Author: Laine Stump <laine> Date: Sun Aug 11 16:21:42 2019 -0400 util: allow tap-based guest interfaces to have MAC address prefix 0xFE
Reproduce on libvirt-5.0.0-12.module+el8.0.1+3755+6782b0ed.x86_64: 1. Start vm: # virsh dumpxml rhel | grep "<mac" <mac address='fe:54:00:58:48:ed'/> # virsh start rhel error: Failed to start domain rhel error: unsupported configuration: Unable to use MAC address starting with reserved value 0xFE - 'fe:54:00:58:48:ed' - 2. hotplug: prepare a running vm, hotplug an interface with mac address with prefix as "FE" # virsh attach-interface rhel network default --mac fe:54:00:58:48:ed error: Failed to attach interface error: unsupported configuration: Unable to use MAC address starting with reserved value 0xFE - 'fe:54:00:58:48:ed' - Test on libvirt-5.6.0-2.module+el8.1.0+4015+63576633.x86_64: 1. Start vm: # virsh dumpxml rhel | grep "<mac" <mac address='fe:54:00:70:58:07'/> # virsh start rhel Domain rhel started # virsh dumpxml rhel | grep "<mac" -A2 <mac address='fe:54:00:70:58:07'/> <source network='default' portid='a5d3c662-4c87-45a4-a086-cfce1539195e' bridge='virbr0'/> <target dev='vnet0'/> # ip addr | grep vnet0 -A2 98: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr0 state UNKNOWN group default qlen 1000 link/ether fa:54:00:70:58:07 brd ff:ff:ff:ff:ff:ff inet6 fe80::f854:ff:fe70:5807/64 scope link 2. hotplug: # virsh attach-interface rhel network default --mac fe:54:00:70:58:09 Interface attached successfully # virsh dumpxml rhel | grep "<mac" -A2 .. <mac address='fe:54:00:70:58:09'/> <source network='default' portid='7f1a8de4-6551-464e-9170-b328fa1faeb6' bridge='virbr0'/> <target dev='vnet1'/> # ip addr | grep vnet1 -A2 101: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr0 state UNKNOWN group default qlen 1000 link/ether fa:54:00:70:58:09 brd ff:ff:ff:ff:ff:ff inet6 fe80::f854:ff:fe70:5809/64 scope link And check the network function works well, set the bug to be verified.
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/RHBA-2019:3723