qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Patch to improve handling of server sockets
Date: Tue, 04 May 2010 16:50:34 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

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.

Regards,

Anthony Liguori

cheers,
  Gerd






reply via email to

[Prev in Thread] Current Thread [Next in Thread]