Bug 1205081

Summary:	NetworkManager races with dnsmasq-dhcp on libvirt network
Product:	[Fedora] Fedora	Reporter:	Stef Walter <stefw>
Component:	NetworkManager	Assignee:	Lubomir Rintel <lkundrak>
Status:	CLOSED EOL	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	22	CC:	dcbw, psimerda
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-19 13:10:21 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:
Bug Depends On:
Bug Blocks:	1204627

Description Stef Walter 2015-03-24 08:30:06 UTC

Description of problem:

During addition of a device to a libvirt bridge, NetworkManager causes races and prevents dnsmasq-dhcp on the host from receiving network requests from VMs.

It's hard to know where to diagnose this exactly, but i can reproduce reliably here. It happens about 1 in 10 VM boots.

I had never seen this occur on Fedora 21.

Marking the bridge as unmanaged by NetworkManager causes the issue to go away.

Version-Release number of selected component (if applicable):

NetworkManager-1.0.0-8.fc22.x86_64
libvirt-daemon-1.2.13-2.fc22.x86_64
dnsmasq-2.72-3.fc22.x86_64

How reproducible:

Regularly on my machine when running the Cockpit CI test suite.

Steps to Reproduce:
1. Run the Cockpit CI test suite on my machine
2. Ask Stef to help you reproduce this or give more info

Actual results:

Can clearly see that DHCP requests don't make it to dnsmasq-dhcp

Expected results:

dnsmasq-dhcp gets and responds to DHCP requests.

Additional info:

This works around the issue:

$ cat /etc/sysconfig/network-scripts/ifcfg-cockpit0
DEVICE=cockpit0
NM_CONTROLLED=no

After disabling networkmanager for the cockpit0 interface:

$ nmcli dev status
DEVICE TYPE STATE CONNECTION
virbr0 bridge connected virbr0
enp3s0 ethernet connected enp3s0
cockpit0 bridge unmanaged --
cockpitx bridge unmanaged --
lo loopback unmanaged --
cockpit0-nic tap unmanaged --
cockpitx-nic tap unmanaged --
tap0 tap unmanaged --
tap1 tap unmanaged --
virbr0-nic tap unmanaged --

Comment 1 Stef Walter 2015-03-24 08:30:35 UTC

$ sudo virsh net-dumpxml cockpit
[sudo] password for stef: 
<network>
  <name>cockpit</name>
  <uuid>f3605fa4-0763-41ea-8143-49da3bf73262</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='cockpit0' stp='on' delay='0'/>
  <mac address='52:54:00:b8:d2:b5'/>
  <domain name='cockpit.lan'/>
  <ip address='10.111.111.200' netmask='255.255.255.0'>
    <dhcp>
      <host mac='52:54:00:9e:00:00' name='m10.cockpit.lan' ip='10.111.111.10'/>
      <host mac='52:54:00:9e:00:01' name='m11.cockpit.lan' ip='10.111.111.11'/>
      <host mac='52:54:00:9e:00:02' name='m12.cockpit.lan' ip='10.111.111.12'/>
      <host mac='52:54:00:9e:00:03' name='m13.cockpit.lan' ip='10.111.111.13'/>
      <host mac='52:54:00:9e:00:04' name='m14.cockpit.lan' ip='10.111.111.14'/>
      <host mac='52:54:00:9e:00:05' name='m15.cockpit.lan' ip='10.111.111.15'/>
      <host mac='52:54:00:9e:00:06' name='m16.cockpit.lan' ip='10.111.111.16'/>
      <host mac='52:54:00:9e:00:07' name='m17.cockpit.lan' ip='10.111.111.17'/>
      <host mac='52:54:00:9e:00:08' name='m18.cockpit.lan' ip='10.111.111.18'/>
      <host mac='52:54:00:9e:00:09' name='m19.cockpit.lan' ip='10.111.111.19'/>
      <host mac='52:54:00:9e:00:0a' name='m20.cockpit.lan' ip='10.111.111.20'/>
      <host mac='52:54:00:9e:00:0b' name='m21.cockpit.lan' ip='10.111.111.21'/>
      <host mac='52:54:00:9e:00:0c' name='m22.cockpit.lan' ip='10.111.111.22'/>
      <host mac='52:54:00:9e:00:0d' name='m23.cockpit.lan' ip='10.111.111.23'/>
      <host mac='52:54:00:9e:00:0e' name='m24.cockpit.lan' ip='10.111.111.24'/>
      <host mac='52:54:00:9e:00:0f' name='m25.cockpit.lan' ip='10.111.111.25'/>
      <host mac='52:54:00:9e:00:F0' name='f0.cockpit.lan' ip='10.111.111.100'/>
      <host mac='52:54:00:9e:00:F1' name='f1.cockpit.lan' ip='10.111.111.101'/>
      <host mac='52:54:00:9e:00:F2' name='f2.cockpit.lan' ip='10.111.111.102'/>
      <host mac='52:54:00:9e:00:F3' name='f3.cockpit.lan' ip='10.111.111.103'/>
      <host mac='52:54:00:9e:00:F4' name='f4.cockpit.lan' ip='10.111.111.104'/>
    </dhcp>
  </ip>
</network>

Comment 2 Stef Walter 2015-03-24 08:37:09 UTC

This breaks the Cockpit test suite. Workaround:

https://github.com/cockpit-project/cockpit/pull/1998

Comment 3 Fedora Admin XMLRPC Client 2015-08-18 15:00:02 UTC

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Fedora End Of Life 2016-07-19 13:10:21 UTC

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.