Bug 2124443

4.18.0-393.el8.x86_64 with qemu-kvm-6.2.0-14.module+el8.7.0+15289+26b4351e don't hit this issue.

(In reply to aihua liang from comment #1)
> 4.18.0-393.el8.x86_64 with qemu-kvm-6.2.0-14.module+el8.7.0+15289+26b4351e
> don't hit this issue.

Test again with the kernel and qemu version for many times, also hit this issue.

(In reply to aihua liang from comment #3)
> (In reply to aihua liang from comment #1)
> > 4.18.0-393.el8.x86_64 with qemu-kvm-6.2.0-14.module+el8.7.0+15289+26b4351e
> > don't hit this issue.
> 
> Test again with the kernel and qemu version for many times, also hit this
> issue.

This look like a NetworkManager issues, so changed the coponent to "NetworkManager". Please correct me if I'm wrong.

Thanks
Lei

Please set level=TRACE in the [logging] section of /etc/NetworkManager/NetworkManager.conf, execute "systemctl restart NetworkManager", reproduce the problem and then attach the output of "journalctl -u NetworkManager -b". Thank you

What happens is that when the VM is started, a tap interface is added to the bridge. A bridge always gets the lowest MAC address of all ports attached to it, and so the MAC of the bridge changes. To fix bug 2110000, now NM restarts DHCP when the MAC changes, therefore the IP changes.

RHEL9.2 has the issue either. Yihuang and I hit the issue on RHEL9.2.
Bridge's MAC address is assigned like comment#7 explained. Yihuang
and I sorted out the workaround, not blocking the testing at least.

   (1) before guest is started
       br0's MAC addr:  f4:6b:8c:55:68:3d
   (2) start guest with command line
       -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown    \
       -device e1000e,bus=pcie.5,netdev=net0, mac=52:54:00:f1:26:a0
   (3) after guest is started
       br0's MAC addr:  7e:bc:c5:79:d2:96                <<< br0 and tap0 have same MAC address
       tap0's MAC addr: 7e:bc:c5:79:d2:96

In /etc/qemu-ifup, to specify tap0's MAC address, which is high enough.
The bridge's MAC and IP address aren't changed after guest boots up.

  #!/bin/sh
  ip link set dev $1 address f4:6b:8c:55:68:80          <<< to have high MAC address for 'tap0'
  ip link set $1 up 
  ip link set dev $1 master br0
  ip link set br0 type bridge forward_delay 0
  ip link set br0 type bridge stp_state 0

I don't think this is expected from NM. We decided that we want to revert the patch for bug 2110000 to go back to the previous behavior.

Created attachment 1914537 [details]
Reproducer with iproute2

The reproducer in attachment shows that the IP address of the bridge changes when a new port is attached:

dnsmasq-dhcp: DHCPDISCOVER(veth1) 4a:37:01:56:9d:ae 
dnsmasq-dhcp: DHCPOFFER(veth1) 172.25.1.150 4a:37:01:56:9d:ae 
dnsmasq-dhcp: DHCPREQUEST(veth1) 172.25.1.150 4a:37:01:56:9d:ae 
dnsmasq-dhcp: DHCPACK(veth1) 172.25.1.150 4a:37:01:56:9d:ae 

* Initial address:
83: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 4a:37:01:56:9d:ae brd ff:ff:ff:ff:ff:ff
    inet 172.25.1.150/24 brd 172.25.1.255 scope global dynamic noprefixroute br0
       valid_lft 111sec preferred_lft 111sec

dnsmasq-dhcp: DHCPDISCOVER(veth1) 172.25.1.150 00:00:00:00:22:44 
dnsmasq-dhcp: DHCPOFFER(veth1) 172.25.1.151 00:00:00:00:22:44 
dnsmasq-dhcp: DHCPDISCOVER(veth1) 172.25.1.150 00:00:00:00:22:44 
dnsmasq-dhcp: DHCPOFFER(veth1) 172.25.1.151 00:00:00:00:22:44 
dnsmasq-dhcp: DHCPREQUEST(veth1) 172.25.1.151 00:00:00:00:22:44 
dnsmasq-dhcp: DHCPACK(veth1) 172.25.1.151 00:00:00:00:22:44 

* Final address:
83: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:00:00:00:22:44 brd ff:ff:ff:ff:ff:ff
    inet 172.25.1.151/24 brd 172.25.1.255 scope global dynamic noprefixroute br0

This seems a serious regression, I think we should fix this in 8.7.z.

I hit this issue on 

root@dell-per440-11 /home $ rpm -qa|grep Network
NetworkManager-adsl-1.40.2-1.el8.x86_64
NetworkManager-wwan-1.40.2-1.el8.x86_64
NetworkManager-1.40.2-1.el8.x86_64
NetworkManager-wifi-1.40.2-1.el8.x86_64
NetworkManager-tui-1.40.2-1.el8.x86_64
NetworkManager-config-server-1.40.2-1.el8.noarch
NetworkManager-team-1.40.2-1.el8.x86_64
NetworkManager-libnm-1.40.2-1.el8.x86_64
NetworkManager-bluetooth-1.40.2-1.el8.x86_64


Red Hat Enterprise Linux release 8.8 Beta (Ootpa)
4.18.0-437.el8.x86_64
qemu-kvm-6.2.0-22.module+el8.8.0+16816+1d3555ec.x86_64
seabios-bin-1.16.0-3.module+el8.8.0+16781+9f4724c2.noarch


cmd line:
/usr/libexec/qemu-kvm \
     -name 'avocado-vt-vm1'  \
     -machine q35,memory-backend=mem-machine_mem \
     -device pcie-root-port,id=pcie-root-port-0,multifunction=on,bus=pcie.0,addr=0x1,chassis=1 \
     -device pcie-pci-bridge,id=pcie-pci-bridge-0,addr=0x0,bus=pcie-root-port-0  \
     -nodefaults \
     -device VGA,bus=pcie.0,addr=0x2 \
     -m 8g \
     -object memory-backend-ram,size=8g,id=mem-machine_mem  \
     -smp 10,maxcpus=10,cores=5,threads=1,dies=1,sockets=2  \
     -cpu 'Cascadelake-Server',ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on,pschange-mc-no=on,tsx-ctrl=on,hle=off,rtm=off,kvm_pv_unhalt=on \
     -device pcie-root-port,id=pcie-root-port-1,port=0x1,addr=0x1.0x1,bus=pcie.0,chassis=2 \
     -device qemu-xhci,id=usb1,bus=pcie-root-port-1,addr=0x0 \
     -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
     -object '{"qom-type": "iothread", "id": "iothread0"}' \
     -object '{"qom-type": "iothread", "id": "iothread1"}' \
     -blockdev '{"node-name": "file_image1", "driver": "file", "auto-read-only": true, "discard": "unmap", "aio": "threads", "filename": "/home/kvm_autotest_root/images/rhel880-64-virtio.qcow2", "cache": {"direct": true, "no-flush": false}}' \
     -blockdev '{"node-name": "drive_image1", "driver": "qcow2", "read-only": false, "cache": {"direct": true, "no-flush": false}, "file": "file_image1"}' \
     -device pcie-root-port,id=pcie-root-port-2,port=0x2,addr=0x1.0x2,bus=pcie.0,chassis=3 \
     -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,write-cache=on,bus=pcie-root-port-2,addr=0x0,iothread=iothread0 \
     -device pcie-root-port,id=pcie-root-port-3,port=0x3,addr=0x1.0x3,bus=pcie.0,chassis=4 \
     -device virtio-net-pci,mac=9a:ae:3b:5d:65:a9,id=iddrLgMU,netdev=idhOgMai,bus=pcie-root-port-3,addr=0x0  \
     -netdev tap,id=idhOgMai \
     -vnc :5  \
     -monitor stdio \
     -qmp tcp:0:5955,server,nowait \
     -rtc base=utc,clock=host,driftfix=slew  \
     -boot menu=off,order=cdn,once=c,strict=off \
     -enable-kvm \
     -device pcie-root-port,id=pcie_extra_root_port_0,multifunction=on,bus=pcie.0,addr=0x3,chassis=5 \
     \
     -chardev socket,id=socket-serial,path=/var/tmp/socket-serial,logfile=/var/tmp/file-serial.log,mux=on,server=on,wait=off \
     -serial chardev:socket-serial \
     -chardev file,path=/var/tmp/file-bios.log,id=file-bios \
     -device isa-debugcon,chardev=file-bios,iobase=0x402 \

Hi, this was incorrectly marked as fixed in NetworkManager-1.40.2-1.el8, but is actually fixed in 1.40.4-1.el8.

Sorry for the inconvenience; can you please test the new version?

(In reply to Beniamino Galvani from comment #21)
> Hi, this was incorrectly marked as fixed in NetworkManager-1.40.2-1.el8, but
> is actually fixed in 1.40.4-1.el8.
> 
> Sorry for the inconvenience; can you please test the new version?

Boot VM 10 times it does not make host IP change.

root@dell-per440-11 /home/vbugs/bug/2141964 $ rpm -qa|grep -i networkm
NetworkManager-wifi-1.40.4-1.el8.x86_64
NetworkManager-bluetooth-1.40.4-1.el8.x86_64
NetworkManager-adsl-1.40.4-1.el8.x86_64
NetworkManager-ovs-1.40.4-1.el8.x86_64
NetworkManager-config-server-1.40.2-1.el8.noarch
NetworkManager-wwan-1.40.4-1.el8.x86_64
NetworkManager-tui-1.40.4-1.el8.x86_64
NetworkManager-1.40.4-1.el8.x86_64
NetworkManager-team-1.40.4-1.el8.x86_64
NetworkManager-ppp-1.40.4-1.el8.x86_64
NetworkManager-libnm-devel-1.40.4-1.el8.x86_64
NetworkManager-cloud-setup-1.40.4-1.el8.x86_64
NetworkManager-libnm-1.40.4-1.el8.x86_64

1.40.4-1.el8: IPv4 and IPv6 addresses stay the same even after DHCP and SLAAC would force their change after a port interface with lowest possible MAC address had been added to the bridge.

As per this and results by Quing in comment 23, I'm marking the bug as VERIFIED.

Tested by NM CI scenarios:
bridge_new_lower_mac_port_unchanged_ip_addresses_v4
bridge_new_lower_mac_port_unchanged_ip_addresses_v6

(In reply to David Jaša from comment #24)
> 1.40.4-1.el8: IPv4 and IPv6 addresses stay the same even after DHCP and
> SLAAC would force their change after a port interface with lowest possible
> MAC address had been added to the bridge.
> 
> As per this and results by Quing in comment 23, I'm marking the bug as
> VERIFIED.
> 
> Tested by NM CI scenarios:
> bridge_new_lower_mac_port_unchanged_ip_addresses_v4
> bridge_new_lower_mac_port_unchanged_ip_addresses_v6

Actually flipping the bug.

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 (NetworkManager bug fix and enhancement update), 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-2023:2968