Re: [Qemu-devel] Patch to improve handling of server sockets

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, May 04, 2010 at 04:50:34PM -0500, Anthony Liguori wrote:
> On 05/04/2010 04:47 PM, Gerd Hoffmann wrote:
> >On 05/04/10 18:23, Anthony Liguori wrote:
> >>On 05/04/2010 08:49 AM, Reinhard Max wrote:
> >>>Hi,
> >>>
> >>>I am maintaining the tightvnc package for openSUSE and was recently
> >>>confronted with an alleged vnc problem with QWMU that turned out to be
> >>>a shortcoming in QEMU's code for handling TCP server sockets, which is
> >>>used by the vnc and char modules.
> >>>
> >>>The problem occurs when the address to listen on is given as a name
> >>>which resolves to multiple IP addresses the most prominent example
> >>>being "localhost" resolving to 127.0.0.1 and ::1 .
> >
> >My tigervnc (tightvnc successor) has IPv6 support and handles this 
> >just fine.  There is also the option to force qemu to listen on ipv4 
> >(or ipv6) only.
> >
> >>>The existing code stopped walking the list of addresses returned by
> >>>getaddrinfo() as soon as one socket was successfully opened and bound.
> >>>The result was that a qemu instance started with "-vnc localhost:42"
> >>>only listened on ::1, wasn't reachable through 127.0.0.1. The fact
> >>>that the code set the IPV6_V6ONLY socket option didn't help, because
> >>>that option only works when the socket gets bound to the IPv6 wildcard
> >>>address (::), but is useless for explicit address bindings.
> >
> >Indeed.
> >
> >>But that said, I'm not sure we're doing the wrong thing right now. Gerd,
> >>what do you think about this behavior?
> >
> >Reinhard is correct.  If a hostname resolves to multiple addresses 
> >like this ...
> >
> >   zweiblum kraxel ~# host zweiblum
> >   zweiblum.home.kraxel.org has address 192.168.2.101
> >   zweiblum.home.kraxel.org has IPv6 address 
> >2001:6f8:1cb3:2:216:41ff:fee1:3d40
> >
> >... qemu should listen on all addresses returned.  Which in turn 
> >requires multiple listening sockets.
> >
> >Changing this is a big deal though, thats why I've taken the somewhat 
> >unclean shortcut to listen on the first match only when implementing 
> >this.  Clients are supposed to try to connect to all addresses 
> >returned by the lookup (and they do if they got IPv6 support), thus 
> >this usually doesn't cause trouble in practice.
> >
> >When going for multiple listening sockets in qemu we have to figure 
> >how we'll handle this in a number of places as there is no single 
> >listening address any more.  Reporting the vnc server address in QMP 
> >is one.  I'm sure there are more.
> 
> Okay, that makes sense.  Personally, I'm inclined to agree that this is 
> a client problem.

It isn't a client problem if QEMU is not listening on all the required
addresses. In Gerd's case 

> >   zweiblum.home.kraxel.org has address 192.168.2.101
> >   zweiblum.home.kraxel.org has IPv6 address
> >2001:6f8:1cb3:2:216:41ff:fee1:3d40

If QEMU only listens on 2001:6f8:1cb3:2:216:41ff:fee1:3d40, and a VNC
client that only knows IPv4 tries to connect it will fail. There's nothing
the client can do to solve this. QEMU has to be listening on all addresses 
associated with a name for the dual-stack setup to provide correct fallback 
for clients.


Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|