Description of problem: I have a Windows virtual machine connected to the host by a virtual network (named "default") with NAT forwarding. For this libvirt creates a network interface (virbr0) on the host and runs a DHCP server (dnsmasq) listening on it. Unfortunately the MAC address of the interface is not what I want, so the Windows guest asks me to what kind of network it's connected - home, work or public. Version-Release number of selected component (if applicable): libvirt-5.6.0-4.fc31.src.rpm How reproducible: Every time Steps to Reproduce: 1. Create a virtual network with NAT forwarding similar to this: <network> <name>default</name> <uuid>df9804c1-827d-4b2b-b836-10a00ee5343e</uuid> <forward mode="nat"> <nat> <port start="1024" end="65535"/> </nat> </forward> <bridge name="virbr0" stp="on" delay="0"/> <mac address="52:54:00:e7:29:fa"/> <ip address="192.168.122.1" netmask="255.255.255.0"> <dhcp> <range start="192.168.122.2" end="192.168.122.254"/> </dhcp> </ip> </network> 2. Start the network Actual results: 9: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether fa:b8:9b:41:4d:ad brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 10: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:e7:29:fa brd ff:ff:ff:ff:ff:ff Expected results: The network interface virbr0 should have the MAC address specified in the XML (XPath /network/mac/@address), i.e. 52:54:00:e7:29:fa. Additional info: kernel-5.3.5-300.fc31.x86_64 I had no problems until last week when I upgraded from Fedora 30 to Fedora 31 (with dnf-plugin-system-upgrade).
I have enabled the @virtmaint-sig/virt-preview COPR (libvirt-5.8.0-1.fc31.src.rpm), yet the issue persists.
I think this is caused by systemd turning on MACAddressPolicy=persistent for virtual devices like bond/bridges/etc, see: https://github.com/systemd/systemd/blob/master/NEWS#L499 https://github.com/systemd/systemd/issues/3374
# systemctl status systemd-networkd.service ● systemd-networkd.service - Network Service Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: disabled) Active: inactive (dead)
(In reply to Cristian Ciupitu from comment #3) > # systemctl status systemd-networkd.service > ● systemd-networkd.service - Network Service > Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; > disabled; vendor preset: disabled) > Active: inactive (dead) It doesn't matter, the MAC change is performed by udev. To verify if the issue is related to MACAddressPolicy, you can add a file /etc/systemd/network/98-bridge-inherit-mac.link containing: [Match] Type=bridge [Link] MACAddressPolicy=none This should restore the old behavior.
That's interesting information, but if it's going to take a modification to restore previous behavior, then libvirt will just need to explicitly set the MAC address rather than relying on it being set to the lowest numbered MAC of attached devices. Back in 2011 when we first encountered the problem reported by Cristian, the ability to explicitly set a MAC address for a bridge device was very new, and not many of the distros supported by libvirt yet supported that feature. Since attaching a dummy tap device with the desired MAC address worked properly for all distros, we chose to implement it that way. In 2019, upstream libvirt no longer supports even RHEL6, which was newly released at the time the bug was fixed, and which *did* have the ability to explicitly set the bridge MAC address. So I think now it is safe to set the MAC address in this way (although I think we will have to keep the virbrN-nic "dummy tap" device around for IPv6 DAD anyway). I've tried a couple different patches (one that provides the mac address in the netlink message that creates it, another that separately sets the MAC after creation). Both work, and I'm going to figure out the cleanest way to deal with it and send a patch upstream. Once it's in, we should see if we can get it added into F31 before GA, so that users with Windows guests aren't surprised by the "New Network Connection" dialog after upgrading.
I just posted a two patch series to fix this to libvir-list: https://www.redhat.com/archives/libvir-list/2019-October/msg01146.html
Pushed upstream, will be in libvirt-5.10.0: commit b596d6c106cd87d6d452c5dd4ad923a034544fbf Author: Laine Stump <laine> Date: Wed Oct 16 14:06:54 2019 -0400 util: allow sending mac addr to virNetNewLink without ifindex commit 13ec827052fcd79a4350f499aab5f4aa20ea83fa Author: Laine Stump <laine> Date: Thu Oct 17 21:12:30 2019 -0400 util: set bridge device MAC address explicitly during virNetDevBridgeCreate
Cole, what's the accepted method of getting patches into a Fedora build these days? The upstream maintenance branches seem to have fallen out of favor. (This should get into F31 as soon as reasonably possible, since it's going to create problems for anyone with Windows guests when they upgrade).
(In reply to Laine Stump from comment #8) > Cole, what's the accepted method of getting patches into a Fedora build > these days? The upstream maintenance branches seem to have fallen out of > favor. > > (This should get into F31 as soon as reasonably possible, since it's going > to create problems for anyone with Windows guests when they upgrade). Process is set the bug to POST and reference the upstream commit, and I'll scoop it up eventually. If it's timely then additionally a ping in the bug or IRC/mail is good too I'll do a build for this today
What about the copr.fedorainfracloud.org/group_virtmaint-sig/virt-preview repository? Can the patch get there sooner?
FEDORA-2019-8a6d24ceec has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-8a6d24ceec
libvirt-5.6.0-5.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-8a6d24ceec
libvirt-5.6.0-5.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.