Description of problem: Often after booting my Fedora Workstation 21 Alpha TC5 guest, dns lookup is not working. This happened to me several times today, though I think it might have been working right after installation and today after I rebooted my host laptop, dns was working again, but another reboot and it stopped working again. I tried turning off firewalld and selinux permissive but that made no difference, and same with restarting NetworkManager. The gnome NetworkManager icon shows a question mark. The network is working with dhcp, and an ip address allocated but dns lookups are failing. How reproducible: often Steps to Reproduce: $ host redhat.com Actual results: Host redhat.com not found: 5(REFUSED) Expected results: lookup to work all the time as normal I tried adding a different nameserver to /etc/resolve.conf but this didn't help either. DNS is working normally from all other vm guests but not this one.
Jens, can you collect some details when things are broken? * cat /etc/resolv.conf * dig redhat.com * ip addr * ip route * nmcli dev * NM logs (journalctl -u NetworkManager or /var/log/messages) Are you able to ping outside? $ ping 8.8.8.8
Actually it seems to be a routing problem AFAICS now. Earlier I was confused by ping 192.168.122.1 "working" but it is actually only coming from the guest itself!! No I can't ping 8.8.8.8, nor can I ping the guest from the host. - resolv.conf is completely default. - dig fails in the same way as host mentioned originally. I think this might be related to virt net on the guest. Why we continue to install virt on desktop guests is beyond me... I see virtbr0 on guest with ip 192.168.122.1 which I think may be eating all outbound traffic.
[localhost ~]$ cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.122.1 [localhost ~]$ dig redhat.com ; <<>> DiG 9.9.5-P1-RedHat-9.9.5-9.P1.fc21 <<>> redhat.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 5483 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;redhat.com. IN A ;; Query time: 7 msec ;; SERVER: 192.168.122.1#53(192.168.122.1) ;; WHEN: Mon Sep 08 19:13:15 JST 2014 ;; MSG SIZE rcvd: 28 [localhost ~]$ ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.122.70 netmask 255.255.255.0 broadcast 192.168.122.255 inet6 fe80::5054:ff:fe51:2dd prefixlen 64 scopeid 0x20<link> ether 52:54:00:51:02:dd txqueuelen 1000 (Ethernet) RX packets 506 bytes 31320 (30.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 44 bytes 4741 (4.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 0 (Local Loopback) RX packets 974 bytes 105331 (102.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 974 bytes 105331 (102.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether c6:4f:02:6d:4d:5f txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [localhost ~]$ ip route default via 192.168.122.1 dev eth0 proto static metric 1024 192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.70 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 [localhost ~]$ nmcli dev DEVICE TYPE STATE CONNECTION virbr0 bridge connected virbr0 eth0 ethernet connected eth0 lo loopback unmanaged -- [localhost ~]$ It is hard for me to pull down the logs without working network. But let me know if there is anything specific I should look for. Otherwise I can download it next time net works again.
Anyway I suspect this is the fault of the virt net config, but what package owns that? This was not happening in F20 anyway.
Moving to libvirt then.
If you see host network devices in the guest, then there's something wrong with the network virtualization.
The problem is that you've installed libvirt into a guest that runs in the default libvirt network. The default network assigns addresses from the 192.168.122.0/24 network to the guests via DHCP. If you install libvirt in the guest and enable the same libvirt network you get exactly the same network connected to the virbr0 bridge and thus run into routing problems. You either have to disable the default network in the guest, or use "virsh net-edit default" in either the guest or host to change the network subnet to something different and then restart the network (net-destroy, net-start). If you plan on using multiple guests, I'd suggest you change the default network in the host.
Well the point is this doesn't happen for F20 AFAIK. :) So something must have changed... Note that Workstation installs virt (gnome-boxes) by default! as Fedora Desktop has done for some releases too I think.
FWIW there's a bug tracking this, we want to find a workaround for f21 since this is hitting more often *** This bug has been marked as a duplicate of bug 811967 ***
Thanks Cole, I didn't realise it was a longer standing issue. :-| I surprised I haven't hit it before, but it is highly reproducible for me with F21 Alpha TCs.