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)
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)
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.
(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.
I'd like to see (separately) a patch on engine side to actually send parameters this new non-legacy way;-)
Verified on - 3.6.0-0.18.el6 with vdsm-4.17.8-1.el7ev.noarch
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