Bug 1321703

Summary: failure to resolve domains on first boot
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: agedosier, berrange, bgalvani, bugzilla, clalancette, crobinso, dcbw, itamar, jforbes, laine, libvirt-maint, lkundrak, psimerda, veillard, virt-maint
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-04-08 22:07:50 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:
Attachments:
Description Flags
journal, first boot, domains do not resolve
none
journal, subseqeunt boot, resolution works OK
none
fpaste sysinfo
none
verify libvirtd is running none

Description Chris Murphy 2016-03-29 01:09:09 UTC 
Description of problem: URLs are not resolved on firstboot. Rebooting fixes the problem. Always reproduces in virt-manager and Gnome-Boxes. Uncertain whether it reproduces on baremetal.


Version-Release number of selected component (if applicable):
NetworkManager-1.2.0-0.6.beta2.fc24.x86_64


How reproducible:
100% on first boot following an installation.
0% on subsequent boots.


Steps to Reproduce:
1. Install Fedora-Workstation-Live-x86_64-24_Alpha-7.iso using defaults.
2. Reboot from installation.
3.

Actual results:

No DNS resolution happens. I can enter IPs into Firefox and those work, I can also ssh and scp to from the guest VM. Reboot, now domain resolution works and continues to work for successive reboots.


Expected results:

Domain resolution should work on first boot.

Additional info:
Comment 1 Chris Murphy 2016-03-29 01:09:58 UTC 
Created attachment 1141047 [details]
journal, first boot, domains do not resolve
Comment 2 Chris Murphy 2016-03-29 01:10:18 UTC 
Created attachment 1141048 [details]
journal, subseqeunt boot, resolution works OK
Comment 3 Chris Murphy 2016-03-29 02:34:37 UTC 
Created attachment 1141065 [details]
fpaste sysinfo
Comment 4 Chris Murphy 2016-03-29 04:25:18 UTC 
This could be a dup of bug 1093803. I can reproduce the same behavior with Fedora 23 final again in both virt-manager and Gnome Boxes, the first boot has no domain resolution and all others after that it works.
Comment 5 Beniamino Galvani 2016-03-29 09:52:25 UTC 
This line:

[    6.841321] dnsmasq[1449]: ignoring nameserver 192.168.124.1 - local interface

suggests that the IP of DNS server received through DHCP is also
assigned to a local interface (maybe created by libivirtd), can you
please check if this is the case? Can you also paste the output of 'ip a'
when DNS is not working?
Comment 6 Chris Murphy 2016-03-29 19:32:10 UTC 
192.168.124.1 exists no where else except this host and/or vm.

On host when virt-manager is not running:
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c8:2a:14:02:88:99 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.4/24 brd 10.0.0.255 scope global dynamic enp2s0f0
       valid_lft 594124sec preferred_lft 594124sec
    inet6 2601:282:702:b960:7d43:76b3:7ddc:14e7/64 scope global temporary dynamic 
       valid_lft 345589sec preferred_lft 75122sec
    inet6 2601:282:702:b960:ca2a:14ff:fe02:8899/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 345589sec preferred_lft 345589sec
    inet6 fe80::ca2a:14ff:fe02:8899/64 scope link 
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:83:90:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue master virbr0 state DOWN group default qlen 500
    link/ether 52:54:00:83:90:be brd ff:ff:ff:ff:ff:ff


On host with virt-manager running, guest OS is at GRUB menu:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c8:2a:14:02:88:99 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.4/24 brd 10.0.0.255 scope global dynamic enp2s0f0
       valid_lft 594058sec preferred_lft 594058sec
    inet6 2601:282:702:b960:7d43:76b3:7ddc:14e7/64 scope global temporary dynamic 
       valid_lft 345589sec preferred_lft 75056sec
    inet6 2601:282:702:b960:ca2a:14ff:fe02:8899/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 345589sec preferred_lft 345589sec
    inet6 fe80::ca2a:14ff:fe02:8899/64 scope link 
       valid_lft forever preferred_lft forever
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:83:90:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue master virbr0 state DOWN group default qlen 500
    link/ether 52:54:00:83:90:be brd ff:ff:ff:ff:ff:ff
15: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN group default qlen 500
    link/ether fe:54:00:3f:7e:76 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe3f:7e76/64 scope link 
       valid_lft forever preferred_lft forever


On host with guest OS running and no DNS:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c8:2a:14:02:88:99 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.4/24 brd 10.0.0.255 scope global dynamic enp2s0f0
       valid_lft 594013sec preferred_lft 594013sec
    inet6 2601:282:702:b960:7d43:76b3:7ddc:14e7/64 scope global temporary dynamic 
       valid_lft 345590sec preferred_lft 75011sec
    inet6 2601:282:702:b960:ca2a:14ff:fe02:8899/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 345590sec preferred_lft 345590sec
    inet6 fe80::ca2a:14ff:fe02:8899/64 scope link 
       valid_lft forever preferred_lft forever
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:83:90:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue master virbr0 state DOWN group default qlen 500
    link/ether 52:54:00:83:90:be brd ff:ff:ff:ff:ff:ff
15: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN group default qlen 500
    link/ether fe:54:00:3f:7e:76 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe3f:7e76/64 scope link 
       valid_lft forever preferred_lft forever

On guest OS (f24 alpha 7) first boot:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:3f:7e:76 brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.69/24 brd 192.168.124.255 scope global dynamic ens3
       valid_lft 3542sec preferred_lft 3542sec
    inet6 fe80::a230:663a:2979:dfff/64 scope link 
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 500
    link/ether 52:54:00:32:e9:1f brd ff:ff:ff:ff:ff:ff


And guest OS again, subsequent boot:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:3f:7e:76 brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.69/24 brd 192.168.124.255 scope global dynamic ens3
       valid_lft 3584sec preferred_lft 3584sec
    inet6 fe80::a230:663a:2979:dfff/64 scope link 
       valid_lft forever preferred_lft foreve


Looks to me like libvirt in the guest OS is creating virbr0* on firstboot, but not subsequent boots and that might be the source of the conflict for 192.168.124.1.
Comment 7 Beniamino Galvani 2016-03-30 09:44:24 UTC 
(In reply to Chris Murphy from comment #6)
 
> Looks to me like libvirt in the guest OS is creating virbr0* on firstboot,
> but not subsequent boots and that might be the source of the conflict for
> 192.168.124.1.

Probably you should disable the service on guests? Reassigning to libvirt so that they can say if this is expected or a bug.
Comment 8 Cole Robinson 2016-04-08 22:07:50 UTC 
Probably just a dup of 1146232

*** This bug has been marked as a duplicate of bug 1146232 ***
Comment 9 Chris Murphy 2016-05-04 19:56:29 UTC 
Created attachment 1154000 [details]
verify libvirtd is running

This is an icky bug. Why is libvirtd enabled by default? Boxes doesn't need it to be. Virt-manager doesn't really either because it puts up a very clear message what it expects on baremetal. Having it enabled by default only has a downside near as I can tell.