Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1321703 - failure to resolve domains on first boot
Summary: failure to resolve domains on first boot
Keywords:
Status: CLOSED DUPLICATE of bug 1146232
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-29 01:09 UTC by Chris Murphy
Modified: 2016-05-04 19:56 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-08 22:07:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
journal, first boot, domains do not resolve (229.00 KB, text/x-vhdl)
2016-03-29 01:09 UTC, Chris Murphy
no flags Details
journal, subseqeunt boot, resolution works OK (211.98 KB, text/x-vhdl)
2016-03-29 01:10 UTC, Chris Murphy
no flags Details
fpaste sysinfo (11.06 KB, text/plain)
2016-03-29 02:34 UTC, Chris Murphy
no flags Details
verify libvirtd is running (29.50 KB, image/png)
2016-05-04 19:56 UTC, Chris Murphy
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.