Bug 1528971

Dan, there should be a table in postgresql with iptables ports to be opened.
Not sure about how the new firewalld ansible deployment stores the port to be opened but it will probably need a fix as well.

This bug is unrelated to firewall. (ovirt-imageio is responsible to deliver its own firewall service configuration, and there is no bug there).

The problem is that its default port, just like vdsm, is not valid for well-known service. It can be assigned by the kernel to any random process.

This may be avoided by setting a system-wide list of reserved ports, or by changing the port numbers. However neither is straightforward nor urgent for 4.2.1.

Doesn't this make sense to be done at rpm installation time? Before host-deploy? To add a file to /etc/sysctl.d/ with "net.ipv4.ip_local_reserved_ports=54322" and load it e.g. with 'sysctl -p' or something?

from us I think it's enough to see that after boot you have

$ sysctl net.ipv4.ip_local_reserved_ports
net.ipv4.ip_local_reserved_ports = 54321,54322

and no regression. Maybe derez would like a more functional verification.

(In reply to Dan Kenigsberg from comment #5)
> from us I think it's enough to see that after boot you have
> 
> $ sysctl net.ipv4.ip_local_reserved_ports
> net.ipv4.ip_local_reserved_ports = 54321,54322
> 
> and no regression. Maybe derez would like a more functional verification.

Maybe just ensure that the ports are indeed open (e.g. using lsof), so imageio-proxy/imageio-daemon could use them.

> Maybe just ensure that the ports are indeed open (e.g. using lsof), so imageio-proxy/imageio-daemon could use them.

please elaborate. Vdsm is expected to open and listen on 54321, but nothing is expected to occupy 54322.

(In reply to Dan Kenigsberg from comment #7)
> > Maybe just ensure that the ports are indeed open (e.g. using lsof), so imageio-proxy/imageio-daemon could use them.
> 
> please elaborate. Vdsm is expected to open and listen on 54321, but nothing
> is expected to occupy 54322.

The issue has been raised from an ost test that sporadically failed due to a conflict with port 54322.
If the fix ensures that 54322 remains unoccupied, then we should be good.

Tested using:
vdsm-4.30.6-1.el7ev.x86_64

I tried 2 approaches:

1. Using sysctl
# sysctl net.ipv4.ip_local_reserved_ports
net.ipv4.ip_local_reserved_ports = 54321-54322

2. Using lsof
# lsof -i :54322
COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
ovirt-ima 23748 vdsm    4u  IPv4 117401      0t0  TCP *:54322 (LISTEN)

# lsof -i :54321
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
vdsmd   4838 vdsm   21u  IPv6 635745      0t0  TCP storage-ge16-vdsm2.scl.lab.tlv.redhat.com:54321->storage-ge-16.scl.lab.tlv.redhat.com:37662 (ESTABLISHED)
vdsmd   4838 vdsm   24u  IPv6 636377      0t0  TCP localhost:54321->localhost:46754 (ESTABLISHED)
vdsmd   4838 vdsm   33u  IPv6 635488      0t0  TCP *:54321 (LISTEN)
python  4839 vdsm   20u  IPv6 636376      0t0  TCP localhost:46754->localhost:54321 (ESTABLISHED)

3. Using fuser
# fuser 54322/tcp
54322/tcp:           23748

# fuser 54321/tcp
54321/tcp:            4838


Moving to VERIFIED.

This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.0 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.