Bug 1261007 - Display network is ignored > vdsm listens to all networks - listen="0" instead of listening to the display network
Display network is ignored > vdsm listens to all networks - listen="0" instea...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.6.0
x86_64 Linux
high Severity high
: ovirt-3.6.0-rc
: 3.6.0
Assigned To: Martin Polednik
Michael Burman
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-08 08:10 EDT by Michael Burman
Modified: 2016-03-09 14:45 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, when using a separate display network, the VDSM service ignored the specific listening IP address and listened to all connections via the management network. With this update, the VDSM service uses the display network settings as expected.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-09 14:45:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
vdsm log (1.65 MB, text/plain)
2015-09-08 08:10 EDT, Michael Burman
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 46224 master NEW graphics: use global displayNetwork if no local specified Never
oVirt gerrit 46356 ovirt-3.6 MERGED graphics: use global displayNetwork if no local specified Never

  None (edit)
Description Michael Burman 2015-09-08 08:10:45 EDT
Created attachment 1071327 [details]
vdsm log

Description of problem:
Display network is ignored > vdsm listens to all networks  listen="0" instead of listening to the display network.

If the display network has no connectivity to the IP, in my case (1.1.1.1) it will use the management network for the display role, because vdsm listens to all networks and he shouldn't. 

vdsm log -->
<graphics autoport="yes" listen="0" passwd="*****" passwdValidTo="1970-01-01T00:00:01" port="-1" tlsPort="-1" type="spice"/>

[root@silver-vdsa ~]# netstat -nlpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:16514           0.0.0.0:*               LISTEN      9792/libvirtd       
tcp        0      0 0.0.0.0:5666            0.0.0.0:*               LISTEN      851/nrpe            
tcp        0      0 0.0.0.0:56452           0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:34599           0.0.0.0:*               LISTEN      10816/rpc.statd     
tcp        0      0 0.0.0.0:8139            0.0.0.0:*               LISTEN      4358/ruby           
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      20591/qemu-kvm      
tcp        0      0 0.0.0.0:5901            0.0.0.0:*               LISTEN      20591/qemu-kvm    

Listen to all networks ^^

Console using -->
[root@silver-vdsa ~]# netstat -nt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 10.35.128.7:5901        10.35.3.84:39993        ESTABLISHED

My management network ^^ and not the display network. 

Version-Release number of selected component (if applicable):
3.6.0-0.13.master.el6

How reproducible:
100

Steps to Reproduce:
1. Working setup DC/Cluster/Host/VM
2. Create new network net-1 and assign it to cluster as a display network
3. Via Setup Networks attach network to host and configure static IP(not routed one) for this network
4. Run VM and connect to spice console

Actual results:
Connection to console succeeded.
vdsm listening to all networks and using the management network(10.35.128.7) as the display network.

<graphics autoport="yes" listen="0"

root@silver-vdsa ~]# netstat -nlt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State 
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:5901            0.0.0.0:*               LISTEN  

root@silver-vdsa ~]# netstat -nt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 10.35.128.7:5901        10.35.3.84:39993        ESTABLISHED


Expected results:
Connection to console should fail with error:
"Unable to connect to the graphic server /home/mburman/Downloads/console.vv
Could not connect to 1.1.1.1: Socket I/O timed out"

[root@orchid-vds2 ~]# netstat -nlpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 1.1.1.1:5900            0.0.0.0:*               LISTEN      27048/qemu-kvm      
tcp        0      0 1.1.1.1:5901            0.0.0.0:*               LISTEN      27048/qemu-kvm   


Additional info:
Danken, so it's not a fallback, it's because vdsm listening to all networks and he manage to establish connection via the management network, on 3.5.z we had 
listen network="vdsm-display-network" on 3.6 it's listen="0".

On 3.5.z if the display network had no routable IP(1.1.1.1) it failed to connect to console, because vdsm was listening only to the display network and not all networks.
"Unable to connect to the graphic server /home/mburman/Downloads/console.vv
Could not connect to 1.1.1.1: Socket I/O timed out"

on 3.5.z 
[root@orchid-vds2 ~]# netstat -nlpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:8139            0.0.0.0:*               LISTEN      1313/ruby           
tcp        0      0 1.1.1.1:5900            0.0.0.0:*               LISTEN      27048/qemu-kvm      
tcp        0      0 1.1.1.1:5901            0.0.0.0:*               LISTEN      27048/qemu-kvm  

vdsm listening only to the display network (in my case 1.1.1.1)
Comment 1 Michal Skrivanek 2015-09-15 10:17:59 EDT
this is hardly urgent as the only "drawback" is that another route is opened for console connection (which may affect e.g. management network when you overload it, fine, but it won't connect if client and/or firewall on the way is configured correctly)
Comment 2 Martin Polednik 2015-09-15 11:10:44 EDT
Can you also add vdsm.log from your 3.5.z run? It seems that displayNetwork is now sent in VM dict while graphics device expects it in it's own specParams.
Comment 3 Michal Skrivanek 2015-09-16 02:52:00 EDT
(In reply to Martin Polednik from comment #2)
> Can you also add vdsm.log from your 3.5.z run? It seems that displayNetwork
> is now sent in VM dict while graphics device expects it in it's own
> specParams.

it's not supposed to expect it...actually, I don't see anyone putting it into specParams on the engine side even in master.
Comment 5 Michal Skrivanek 2015-09-18 05:46:51 EDT
I'd like to see (separately) a patch on engine side to actually send parameters this new non-legacy way;-)
Comment 6 Michael Burman 2015-10-07 01:26:02 EDT
Verified on - 3.6.0-0.18.el6 with vdsm-4.17.8-1.el7ev.noarch
Comment 9 errata-xmlrpc 2016-03-09 14:45:08 EST
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://rhn.redhat.com/errata/RHBA-2016-0362.html

Note You need to log in before you can comment on or make changes to this bug.