Sorry, expected results should look like this:

# netstat -putna | grep 3000
tcp      0 0 :::3000      :::* LISTEN 31750/qemu-kvm
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 31750/qemu-kvm

Closed, please submit the RFE according to teh RedHat process:

https://home.corp.redhat.com/wiki/engineering-tech-talk-meetings

Feb 08 - Requesting enhancements in RHEL: The RFE process.

Reopening. I see this as a bug and the person who sees this as a RFE should reassing it accordingly.

Today, spice-server listens on a single address.
You want it to listen on multiple addresses.
So you would like to add functionality that does not currently exists.
That's a RFE.

(In reply to comment #8)
> Today, spice-server listens on a single address.
> You want it to listen on multiple addresses.
> So you would like to add functionality that does not currently exists.
> That's a RFE.

RHEL has been claiming to support IPv6 for years. I don't think fixing
application to do what we already claim to support is a good candidate
for going through RFE process.

Adding to a tracker bug for broken dualstack networking.

I've written down some basic documentation, or you could say guidelines for dualstack server applications:

https://fedoraproject.org/wiki/Networking/NameResolution#Binding_to_addresses_using_getaddrinfo.28.29

So far I have the following solutions with the current linux TCP/IP stack:

1) Only support listening on all addresses. Always bind() to the IPv6 address in dualstack mode.

sock1 = socket(AF_INET6, SOCK_STREAM, SOL_TCP)
bind(sock1, in6addr_any, sizeof (in6addr_any))

2) Use only numeric addresses and NULL setting. Special case NULL setting and solve them separately with #1. Only then, if you use AI_NUMERICHOST and properly specify the socktype and/or protocol fields, you can assume that getaddrinfo() only returns one result.

If result order is fixed in glibc, you wouldn't actually have to special case the NULL host. But it's more of a hack.

3) Support full name name resolution. Always create one socket per resulting address. Set IPV6_V6ONLY on IPv6 sockets to suppres the transparent dualstack. This works for all cases.

(In reply to comment #0)
> 1st: when administrator wants qemu/spice-server to listen on both ipv6 and
> ipv4, she can not run qemu with -spice
> addr=<ipv4_address>,addr=<ipv6_address>

For the IPv6 dual-stack you do not need to listen on multiple sockets.
It is enough to listen on IPv6 in6addr_any socket as IPV6_V6ONLY is zero by default.  Such socket will accept also IPv4 connections on the same port.


> 2nd: when administrator wants qemu/spice-server to listen on some addresses
> only with localhost e.g. -spice addr=127.0.0.1,addr=<eth2_address>

This is true although iptables/ip6tables can serve the same purpose well.

(In reply to comment #12)
> It is enough to listen on IPv6 in6addr_any socket as IPV6_V6ONLY is zero by
> default.

If you want to get this right, you'd either have to handle dual-stack settings in the app or you can use naïve approach of trying to bind to all addresses returned by getaddrinfo(NULL) -- but then you'll run to bug 880698.

(In reply to comment #12)
> (In reply to comment #0)
> > 1st: when administrator wants qemu/spice-server to listen on both ipv6 and
> > ipv4, she can not run qemu with -spice
> > addr=<ipv4_address>,addr=<ipv6_address>
> 
> For the IPv6 dual-stack you do not need to listen on multiple sockets.
> It is enough to listen on IPv6 in6addr_any socket as IPV6_V6ONLY is zero by
> default.  Such socket will accept also IPv4 connections on the same port.

Does that mean you acutally prefer solution #1 (or solution #2) from comment 11?

> > 2nd: when administrator wants qemu/spice-server to listen on some addresses
> > only with localhost e.g. -spice addr=127.0.0.1,addr=<eth2_address>
> 
> This is true although iptables/ip6tables can serve the same purpose well.

I don't think the spice developers will share this opinion. You are right that the firewall can be used as a barrier from external hosts. But question is whether
you can (and want to) get rid of the current practice of binding to localhost.

(In reply to comment #14)
> Does that mean you acutally prefer solution #1 (or solution #2) from comment
> 11?

Yes.  (But I am no networking authority.)

(In reply to comment #15)
> (In reply to comment #14)
> > Does that mean you acutally prefer solution #1 (or solution #2) from comment
> > 11?
> 
> Yes.  (But I am no networking authority.)

I sort of agree that simple servers should just use #1 and leave the security
part to other layers that are better suited for that. That means any service
that doesn't support address binding or name binding or special cased localhost-only, should refuse such a setting.

(In reply to comment #13)
> If you want to get this right, you'd either have to handle dual-stack
> settings in the app or you can use naïve approach of trying to bind to all
> addresses returned by getaddrinfo(NULL) -- but then you'll run to bug 880698.

Yes, if you tolerate the subsequent failed 0.0.0.0 binding. Otherwise, you would
need IPV6_V6ONLY. But that would work even without the glibc ordering fix. Either way, if you support binding to all returned addresses, you need to support multiple sockets, too.

(In reply to comment #12) 
> > 2nd: when administrator wants qemu/spice-server to listen on some addresses
> > only with localhost e.g. -spice addr=127.0.0.1,addr=<eth2_address>
> 
> This is true although iptables/ip6tables can serve the same purpose well.

Not really, one of very common use cases to bind to specific address is to limit the interface where spice-server can use - and you can not use neither iptables for it (outgoing packets could be routed via wrong devices) nor SO_BINDTODEVICE (because spice-server is part of qemu process that runs under "qemu" user) nor external stuff like selinux (because qemu needs to use different interfaces for different purposes). See this email for some more info:
https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-November/001672.html

This is not just about security, but for practical reasons, too.

(In reply to comment #16)
...
> (In reply to comment #13)
> > If you want to get this right, you'd either have to handle dual-stack
> > settings in the app or you can use naïve approach of trying to bind to all
> > addresses returned by getaddrinfo(NULL) -- but then you'll run to bug 880698.
> 
> Yes, if you tolerate the subsequent failed 0.0.0.0 binding. Otherwise, you would
> need IPV6_V6ONLY. But that would work even without the glibc ordering fix.
> Either way, if you support binding to all returned addresses, you need to
> support multiple sockets, too.

IMHO this is the way to go because:
1) it will work for apps that can only listen on single address ($SUBJ of this bug) and need to listen just on wildcard address
2) it is more consistent with client behaviour where program should continue to next address if connect() fails (but unlike it, server should bind() to all returned addresses)

FWIW, the example in gettaddrinfo(3) is quite wrong in this respect if I read the code correctly - it exhibits the same bug as this BZ (break out of the loop on success in the example):
          /* getaddrinfo() returns a list of address structures.
              Try each address until we successfully bind(2).
              If socket(2) (or bind(2)) fails, we (close the socket
              and) try the next address. */

           for (rp = result; rp != NULL; rp = rp->ai_next) {
               sfd = socket(rp->ai_family, rp->ai_socktype,
                       rp->ai_protocol);
               if (sfd == -1)
                   continue;

               if (bind(sfd, rp->ai_addr, rp->ai_addrlen) == 0)
                   break;                  /* Success */

               close(sfd);
           }

spice-server has something similar with goto out of the cycle trying to bind gai results (but fixing just that doesn't suffice, reds_init_socket() must return multiple results, reds_init_net() must accept them and loop through them, and RedsState structure must be able to store them - if I read and understand the code correctly).

(In reply to comment #17)
> Not really, one of very common use cases to bind to specific address is to
> limit the interface where spice-server can use - and you can not use neither
> iptables for it (outgoing packets could be routed via wrong devices)

man iptables:
[!] -o, --out-interface name
Name of an interface via which a packet is going to be sent (for packets entering the FORWARD, OUTPUT and POSTROUTING chains).

(In reply to comment #18)
> man iptables:
> [!] -o, --out-interface name
> Name of an interface via which a packet is going to be sent (for packets
> entering the FORWARD, OUTPUT and POSTROUTING chains).

Not really usable in dynamic environments (such as virtualization host with ephemeral VMs which happens to be the case of vdsm) till some other interface to netfilter (such as firewalld) is available and integrated by upper layers. In other words: a very long time to go.

I had very dynamic product tracking each hotel guest/MAC by time limited tickets via iptables, it is easy to handle as there is even Perl interface to iptables.
(not an advertisement as it is commercially dead anyway)
http://jankratochvil.net/product/hotelgate

(In reply to comment #20)
> I had very dynamic product tracking each hotel guest/MAC by time limited
> tickets via iptables, it is easy to handle as there is even Perl interface
> to iptables.
> (not an advertisement as it is commercially dead anyway)
> http://jankratochvil.net/product/hotelgate

Yes. I also made such a product a long time ago. It is easy to maintain on the deployment level. But is unreliable on the upstream level.

David is unfortunately right here. Unless you have a requirement-based firewall configuration system, this is not the way to go.

Moving back to RHEL 7, this isn't a large feature, rather an improvement.

Not implemented upstream yet, moving to 7.4

Probably qemu_opt_foreach can be used to handle options keeping the order. Not clear how to specify multiple addresses types.

So looking at the possible usecases we are targeting:

1. local workstation usecase - Does only need to connect from localhost
2. RHV - Does not support this
3. OSP - Does not support SPICE

Also libvirt would need to get this extension (so we would have SPICE/qemu, libvirt and then RHV to implement this).
This is not going to happen anytime soon. As such closing this RFE.