Bug 1760851
Summary: | incorrect MAC address for host virtual bridge network interface (virbr0) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Cristian Ciupitu <cristian.ciupitu> |
Component: | libvirt | Assignee: | Laine Stump <laine> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 31 | CC: | agedosier, berrange, bgalvani, clalancette, crobinso, itamar, jforbes, laine, libvirt-maint, mleitner, richard.poettler, veillard, virt-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-5.6.0-5.fc31 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-11-16 00:23:26 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Cristian Ciupitu
2019-10-11 13:29:54 UTC
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. |