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 1401165 - IPv6 DNS problems in qemu user networking
Summary: IPv6 DNS problems in qemu user networking
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-03 07:06 UTC by Jan ONDREJ
Modified: 2017-07-21 10:31 UTC (History)
11 users (show)

Fixed In Version: qemu-2.7.1-6.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-21 09:32:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jan ONDREJ 2016-12-03 07:06:50 UTC
Description of problem:
No DNS response using qemu in Fedora 25, when trying user networking (default).

Version-Release number of selected component (if applicable):
qemu-kvm-2.7.0-7.fc25.x86_64

How reproducible:
always

Steps to Reproduce:
1. run qemu-kvm
2. press Ctrl+B to run ipxe shell
3. try: chain http://www.fedoraproject.org/

Actual results:
Error 0x3e11623b (http://ipxe.org/3e11623b)
URL says: Error: No DNS servers available

Expected results:
Different error message.

Additional info:
Does not matter, which url do you use, just use something which needs DNS translation. You can try for example my http://boot.salstar.sk/, which should start my ipxe boot menu.

Comment 1 Richard W.M. Jones 2016-12-13 18:28:24 UTC
Does virt-rescue work for you?  It uses qemu user networking too,
and works fine for me.

$ LIBGUESTFS_BACKEND=direct virt-rescue --network --scratch
...
Welcome to virt-rescue, the libguestfs rescue shell.

Note: The contents of / are the rescue appliance.
You have to mount the guest's partitions under /sysroot
before you can examine them.

bash: cannot set terminal process group (1): Inappropriate ioctl for device
bash: no job control in this shell
><rescue> exec 3<>/dev/tcp/redhat.com/80
><rescue> echo "GET /" >&3
><rescue> cat <&3
HTTP/1.0 301 Moved Permanently
Location: http://www.redhat.com/
Server: BigIP
Connection: close
Content-Length: 0

><rescue> exit

Comment 2 Jan ONDREJ 2016-12-13 19:28:28 UTC
Yes, virt-rescue works well. Looks like my steps to reproduce have some bugs.

Try this (my boot menu, small file):

wget http://boot.salstar.sk/ipxe/ipxe.lkrn
qemu-kvm -kernel ipxe.lkrn

Fails with network unreachable error, but without DNS it can continue.

After downgrade to qemu from Fedora 24 works well again, so looks like there is no problem with my ipxe build, but with qemu.

Comment 3 Jan ONDREJ 2016-12-13 21:05:13 UTC
After some debugging with nixze on IRC #ipxe, looks like there are ipv6 problems with qemu. My boot script is running on ipv6 network and communicates with IPv6 DNS and web server, which don't work.

As last in network dump, there are DNS queries and reply, but no connection to web server.

Does this information helps?

Comment 4 Richard W.M. Jones 2016-12-13 23:02:18 UTC
Yes I don't think user networking (ie SLIRP) supports IPv6 at all,
and probably it never will.

Comment 5 Jan ONDREJ 2016-12-14 06:17:53 UTC
(In reply to Richard W.M. Jones from comment #4)
> Yes I don't think user networking (ie SLIRP) supports IPv6 at all,
> and probably it never will.

Then why it's working with qemu-2.6, but don't with 2.7?

May be it's partially supported? DNS requests respond with IPv6 addresses, which has not been done in 2.6?

Comment 6 Paolo Bonzini 2016-12-14 12:50:24 UTC
SLIRP supports IPv6, but there could be bugs.  Please report to qemu-devel.

Comment 7 Cole Robinson 2017-03-20 14:37:02 UTC
Using this reproducer:

(In reply to Jan ONDREJ from comment #2)
> 
> wget http://boot.salstar.sk/ipxe/ipxe.lkrn
> qemu-kvm -kernel ipxe.lkrn

I bisected to:

commit f7725df38750c1eaebc6665159bb58ec23864c92
Author: Samuel Thibault <samuel.thibault>
Date:   Sun Mar 20 16:02:52 2016 +0100

    slirp: Add RDNSS advertisement
    
    This adds the RDNSS option to IPv6 router advertisements, so that the guest
    can autoconfigure the DNS server address.
    
    Signed-off-by: Samuel Thibault <samuel.thibault>
    Reviewed-by: Thomas Huth <thuth>
    
    ---
    Changes since last submission:
    - Disable on windows, until we have support for it


And infact if you revert that commit on qemu master, things work again. So either that patch is buggy or maybe it exposes a config issue

thuth, since you reviewed that patch, and have had other slirp patches, any thoughts?

Comment 8 Thomas Huth 2017-03-20 15:45:29 UTC
No clue ... so I'd suggest that you try to discuss this issue on qemu-devel mailing list with Samuel in CC: ...

Anyway, it might also be interesting to get a dump of the network packages on both, the QEMU side and the host side. For the host side, you can use wireshark. For QEMU, please start it with the following parameter:

 -object filter-dump,id=fid1,netdev=<netdevid>,file=/path/to/dumpfile.dat

Comment 9 Cole Robinson 2017-03-20 21:44:46 UTC
Jan, probably better if you initiate the report, I don't know what your PXE config is and I don't have one locally to test with. Building/testing upstream qemu is:

sudo dnf builddep qemu
git clone git://git.qemu-project.org/qemu.git
cd qemu
./configure --target-list="x86_64-softmmu" --disable-werror
make
./x86_64-softmmu/qemu-system-x86_64 $options

Comment 10 Cole Robinson 2017-03-21 15:50:26 UTC
Or if someone can distill a reproducer that doesn't depend on custom ipxe config, maybe just a series of commands from the ipxe prompt, I can report it upstream

Comment 11 Jan ONDREJ 2017-03-22 07:29:56 UTC
My boot scripts are public. Can anybody try, if they fails for you too?

Just boot qemu into command line and then:

chain http://boot.salstar.sk/

Difference from qemu distribution ipxe is, that these supports IPv6.

For those, who wants my binaries to boot directly, here are:
  http://boot.salstar.sk/ipxe/

My binaries are build manually after each commit to upstream ipxe.git. If somebody interested in my ipxe configuration, it's on my page too.

Is this enough for reproduce?

Comment 12 Cole Robinson 2017-03-27 20:25:25 UTC
Patches were posted upstream, I'll pull them into Fedora once they land in qemu.git

http://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg05107.html

Comment 13 Fedora Update System 2017-04-15 18:23:41 UTC
qemu-2.7.1-6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-01925dba3c

Comment 14 Fedora Update System 2017-04-16 21:23:25 UTC
qemu-2.7.1-6.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-01925dba3c

Comment 15 Fedora Update System 2017-04-19 09:24:40 UTC
qemu-2.7.1-6.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 16 Jan ONDREJ 2017-07-21 08:58:24 UTC
Currently DNS is completely broken in qemu. Trying to boot Fedora 26 netboot image with:

qemu-kvm -m 2000 -cdrom Fedora-Server-netinst-x86_64-26-1.5.iso -net user -net nic

Boots well, I can access shell, but unable to access any hostname, for example:

curl -v http://www.redhat.com/
* Could not resolve host: www.redhat.com

My versions:
qemu-kvm-2.9.0-1.fc26.1.x86_64
dnsmasq-2.76-3.fc26.x86_64

I don't know, if this is a qemu or dnsmasq problem.

Using curl http://ip_address/ works.

Comment 17 Thomas Huth 2017-07-21 09:28:04 UTC
(In reply to Jan ONDREJ from comment #16)
> Currently DNS is completely broken in qemu.

Is this still related to IPv6? Or is this a new problem instead? In the latter case, I think it's cleaner if you open a new bug instead...

Comment 18 Jan ONDREJ 2017-07-21 09:32:29 UTC
I am not sure, but adding new bug:

https://bugzilla.redhat.com/show_bug.cgi?id=147360

Comment 19 Jan ONDREJ 2017-07-21 10:31:51 UTC
Sorry, wrong bug ID menitoned here:

https://bugzilla.redhat.com/show_bug.cgi?id=1473604

More curious, that bugzilla wrote: "Email sent to: None".
And really I get no email about my bug, but getting my own reports for all other bugs.


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