Red Hat Bugzilla – Bug 1038963
[RFE] qemu can't listen on both IPv6 and IPv4 localhost for VNC
Last modified: 2017-08-01 23:22:27 EDT
+++ This bug was initially created as a clone of Bug #1014422 +++ Description of problem: qemu doesn't listen on IPv6 socket for IPv4 and IPv6 VNC connections. Version-Release number of selected component (if applicable): qemu-1.4.2-10.fc19.x86_64 How reproducible: always Steps to Reproduce: 1. Use virt-manager to create and start a guest with VNC display 2. Check the listening VNC socket: sudo netstat -nlp | grep :59 Actual results: >sudo netstat -nlp | grep :59 tcp 0 0 127.0.0.1:5900 0.0.0.0:* LISTEN 3233/qemu-system-x8 Expected results: qemu should listen on an IPv6 socket configured to accept both IPv4 and IPv6 connections. >sudo netstat -nlp | grep :59 tcp6 0 0 ::1:5900 :::* LISTEN 3233/qemu-system-x8 Additional info: --- Additional comment from Cole Robinson on 2013-10-31 22:06:30 CET --- Dan, thoughts on if this is intentional or a defect, and if so is it qemu or libvirt? --- Additional comment from Daniel Berrange on 2013-11-01 09:56:23 CET --- It is a bug - we should listen on ::1 by default, with v6-only=0 so that it also covers 127.0.0.1. At minimum it is a libvirt bug. --- Additional comment from Jan Tomko on 2013-11-01 17:21:42 CET --- ::1 with IPV6_V6ONLY=0 does not cover 127.0.0.1, that only works for :: Since QEMU only supports one listen address, we can't tell it to listen on both. Even if we specify a hostname ('localhost') QEMU will only listen on the first address that works (usually ::1 on dual-stack systems) instead of listening on all of them.
Not going to happen for 7.0. As correctly stated above IPV6_V6ONLY=0 can only be used with the wildcard address. So fixing this implies going from a single listening socket to multiple listening sockets, one for 127.0.0.1:$port and one for [::1]:$port. Which is a non-trivial change inside qemu and it also has implications for the external interfaces. 'info vnc' monitor command will have to report multiple listening addresses then for example.
Daniel? I remember we discussed that, but I think iochannels don't support listening on two file handles (one v4, one v6), correct?
Yeah, that's correct - I had a plan to introduce a separate generic abstraction for representing a network service with multiple independent socket listeners & multiple clients which we could reuse in all areas of qemu with this need.
Fix depends on getting these two series into qemu 2.9: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00574.html https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00582.html The first series is pretty much ready. The second series needs a bit more work It is doable for 2.9 as long as no unexpected hurdles appear.
> https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00574.html > https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00582.html Patches are in, yay! upstream commit 396f935a9aff3cefd288bdb2b20024fb9dcfa062 & parents
Test against qemu-kvm-rhev-2.8.0-6.el7.x86_64, start qemu and check port qemu-kvm listened: # /usr/libexec/qemu-kvm -monitor stdio QEMU 2.8.0 monitor - type 'help' for more information (qemu) info vnc Server: address: ::1:5900 auth: none Client: none # netstat -tnap | grep qemu tcp6 0 0 ::1:5900 :::* LISTEN 2433/qemu-kvm Follow same steps against qemu-kvm-rhev-2.9.0-1.el7.x86_64 # /usr/libexec/qemu-kvm -monitor stdio QEMU 2.9.0 monitor - type 'help' for more information (qemu) VNC server running on ::1:5900 (qemu) info vnc Server: address: ::1:5900 auth: none Client: none # netstat -tnap | grep qemu tcp 0 0 127.0.0.1:5900 0.0.0.0:* LISTEN 2076/qemu-kvm tcp6 0 0 ::1:5900 :::* LISTEN 2076/qemu-kvm
Hi Gerd, Can you comment whether this bug is verified per comment 19? Many thanks! BR/ Guo, Zhiyi
> Can you comment whether this bug is verified per comment 19? Many thanks! Looks good.
Verified per comment 19 & 21
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392