Bug 1126332 - Unable to connect to instances via VNC, because compute nodes are using the wrong network
Summary: Unable to connect to instances via VNC, because compute nodes are using the w...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rubygem-staypuft
Version: Foreman (RHEL 6)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: z1
: Installer
Assignee: Scott Seago
QA Contact: Ofer Blaut
URL:
Whiteboard:
: 1129970 (view as bug list)
Depends On:
Blocks: 1126583
TreeView+ depends on / blocked
 
Reported: 2014-08-04 08:17 UTC by Toni Freger
Modified: 2014-10-01 13:25 UTC (History)
12 users (show)

Fixed In Version: ruby193-rubygem-staypuft-0.3.4-2.el6ost
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1126583 (view as bug list)
Environment:
Last Closed: 2014-10-01 13:25:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1350 0 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Bug Fix Advisory 2014-10-01 17:22:34 UTC

Description Toni Freger 2014-08-04 08:17:45 UTC
Description of problem:
Unable to connect to instances via VNC, since compute nodes don't have external\public NIC.

Version-Release number of selected component (if applicable):
Icehouse on RHEL7
Neutron - VXLAN
Controller+ Networker+ 2Computes Node

openstack-nova-novncproxy-2014.1.1-4.el7ost.noarch
novnc-0.4-7.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 3 Toni Freger 2014-08-04 12:05:19 UTC
Yes, nova-novncproxy running on the controller.

Comment 4 Jaroslav Henner 2014-08-04 12:35:37 UTC
Staypuft is a misconfiguring the thing. In my opinion, the novnc and dashboard should listen on the public/external network while Staypuft/Foreman might only be listening on the management network (192.168.x.x). In order to do so, one has to specify

  ServerAlias 10.35.x.x

in the /etc/httpd/config.d/15-horizon_vhost.conf and

add the same address to ALLOWED_HOSTS to 
  /etc/openstack-dashboard/local_settings

and novncproxy_base_url in nova.conf on the computes should probably also contain 10.35.x.x.

the vncserver_listen si imho configured well -- 192.168.x.x

novnc is innocent here:
lsof -ni | grep novn 
nova-novn 14126       nova    3u  IPv4 160500      0t0  TCP *:6080 (LISTEN)

Comment 5 Lars Kellogg-Stedman 2014-08-04 16:57:55 UTC
Toni,

Can you add the output of "iptables -S" on your compute node to this report?  In at least one other instance of this problem it was actually a firewall issue rather than a nova configuration issue.

Also, please attach /etc/nova/nova.conf from your controller and /etc/nova/nova.conf from your compute node.

Thanks!

Comment 6 Lars Kellogg-Stedman 2014-08-04 17:34:26 UTC
ohochman gave me access to this environment.  There are two issues:

(a) The vnc configuration on the compute nodes has them listening on the "wrong" address. In the configuration file is:

  vncserver_listen=192.168.100.253
  vncserver_proxyclient_address=192.168.100.253

Where 192.168.100.0/24 is the address range for the tenant overlay network.  These should be listening on the management network, which on these systems is 192.168.0.0/24.

(b) The iptables configuration on the compute nodes does not permit VNC access.  VNC servers start at port 5900 and then go up, so you need to open ports 5900-(5900 + max number of instances you expect to be running on this server).  Or just "all traffic from the controller".

With both of these issues fixed, it is possible to connect to a VNC console through the gui.

Comment 8 Mike Burns 2014-08-04 20:26:41 UTC
my take on this is that we need to split into 2 bugs, 1 for (a) and 1 for (b) in comment 6.

I will clone and change components correctly.

Comment 9 Mike Burns 2014-08-04 20:30:07 UTC
This bug is for (a) in comment 6

Comment 10 Jason Guiditta 2014-08-11 21:37:10 UTC
Moving to staypuft to track addition of new params needed there

Comment 11 Scott Seago 2014-08-12 19:36:47 UTC
Staypuft fix is here: https://github.com/theforeman/staypuft/pull/265

Comment 13 Mike Burns 2014-08-14 12:04:05 UTC
*** Bug 1129970 has been marked as a duplicate of this bug. ***

Comment 15 Omri Hochman 2014-08-20 14:33:57 UTC
Currently the link that is being created by attempting to open VNC console is pointing to internal network IP like 192.168.0.6 , this should be replace by external network IP to be able to open the console. 

   
should be fixed for A1

Comment 18 Ofer Blaut 2014-09-23 04:40:38 UTC
verified - ruby193-rubygem-staypuft-0.3.5-1.el6ost.noarch

I have tested with NON HA setup and my publicAPI was on the same network as tenant network ( which is not not the PXE/Provision one)

I was able to access horizon and use VMs consoles ( which are on compute hosts)

Comment 22 errata-xmlrpc 2014-10-01 13:25:48 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.

http://rhn.redhat.com/errata/RHBA-2014-1350.html


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