Bug 1079164 - DNS does not appear to be working when using QEMU User Networking (SLIRP)
DNS does not appear to be working when using QEMU User Networking (SLIRP)
Status: RESOLVED INVALID
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Virtualization:Other
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Lin Ma
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-02-02 19:37 UTC by Tony Jones
Modified: 2018-04-19 15:33 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Jones 2018-02-02 19:37:32 UTC
I have several guest images.  None have functioning DNS anymore using qemu-2.11.0-3.1.x86_64 (I upgraded to latest tumbleweed version) and openSUSE-release-20171213-1.2.x86_64 (qemu in this version was similarly not working).

The SLIRP network forwarding through 10.0.2.2 is working,  obviously by IP address only.  It is the DNS forwarding that is not working.

In each host image,  /etc/nsswitch.conf is configured "hosts dns".  /etc/resolv.conf lists the dns server at 10.0.2.3.     10.0.2.3 responds to guest ICMP.

Directly running "nslookup" on the guest results in a timeout.

Running tcpdump on the host, filtering for DNS queries shows nothing being forwarded from the guest.

guest is being started as 'qemu-system-x86_64 --enable-kvm -m 4096 -smp cpus=2 <image>.qcow'.   This has always worked in the past.

I'm trying to compare SLE functionality to Fedora/Ubuntu for an existing bug.

I'll try and do additional debugging to see what is happening.
Comment 1 Tony Jones 2018-02-02 19:38:29 UTC
"In each host image,  /etc/nsswitch.conf" should read "in each guest image". Sorry.
Comment 2 Tony Jones 2018-02-03 02:53:40 UTC
I upgraded to: openSUSE-release-20180131-1.2.x86_64

Same qemu version (as I had previously manually upgraded it):  qemu-2.11.0-3.1.x86_64

problem unchanged.

I'm on vacation next week and didn't have time to do much more debugging of what is going on.  I need to add some code into the qemu dns forwarder I expect.  

Or maybe it's usererror, but I'm not seeing where.
Comment 3 Lin Ma 2018-03-06 06:12:50 UTC
I can't reproduce the issue on tumbleweed host + SLES15Beta7 guest with slirp network backend, nslookup in guest works as well, Could you please upgrade qemu related packages and try again, thanks.

Below is my test environment:

twhost:~ # rpm -qa | grep qemu
qemu-sgabios-8-1.1.noarch
qemu-2.11.1-1.1.x86_64
qemu-vgabios-1.11.0-1.1.noarch
qemu-block-rbd-2.11.1-1.1.x86_64
qemu-seabios-1.11.0-1.1.noarch
qemu-kvm-2.11.1-1.1.x86_64
qemu-block-iscsi-2.11.1-1.1.x86_64
qemu-ovmf-x86_64-2017+git1510945757.b2662641d5-2.1.noarch
qemu-tools-2.11.1-1.1.x86_64
qemu-block-curl-2.11.1-1.1.x86_64
qemu-ipxe-1.0.0-1.1.noarch
qemu-x86-2.11.1-1.1.x86_64


sle15guest:~ # nslookup www.google.com
Server:         10.0.2.3
Address:        10.0.2.3#53
                                                                                                                                                                               
Non-authoritative answer:                                                                                                                                                      
Name:   www.google.com                                                                                                                                                         
Address: 216.58.204.132                                                                                                                                                        
Name:   www.google.com                                                                                                                                                         
Address: 2a00:1450:4007:812::2004
Comment 4 Tony Jones 2018-04-19 15:33:01 UTC
config error on my system. it appears that the SLIRP dns forwarder only tries the first entry in resolv.conf,  which in my case was not correct.     libresolver tries them all in series.