Bug 1261007 - Display network is ignored > vdsm listens to all networks - listen="0" instead of listening to the display network
Summary: Display network is ignored > vdsm listens to all networks - listen="0" instea...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.6.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Martin Polednik
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-08 12:10 UTC by Michael Burman
Modified: 2016-03-09 19:45 UTC (History)
14 users (show)

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.
Clone Of:
Environment:
Last Closed: 2016-03-09 19:45:08 UTC
oVirt Team: Virt
Target Upstream Version:


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


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0362 normal SHIPPED_LIVE vdsm 3.6.0 bug fix and enhancement update 2016-03-09 23:49:32 UTC
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

Description Michael Burman 2015-09-08 12:10:45 UTC
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 14:17:59 UTC
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 15:10:44 UTC
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 06:52:00 UTC
(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 09:46:51 UTC
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 05:26:02 UTC
Verified on - 3.6.0-0.18.el6 with vdsm-4.17.8-1.el7ev.noarch

Comment 9 errata-xmlrpc 2016-03-09 19:45:08 UTC
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.