Unable to access a VM console from remote machine

asked 2014-04-20 11:58:33 -0600

Laurie gravatar image

Hello all,

New to openstack I've set myself a goal of getting

a) An all-in-one installation up and running on my desktop and .. b) VM console access to the all-in-one system from a remote machine.

Step a) completed and all running as expected. However, step b) only partly successful. I can login remotely over the net to my all-in-one machine and access all fuctionality barr the VM console. I noticed my first mistake as the browser of the remote machine said it was unable to connect to Fare enough, not a valid IP, so I set myself up a domain name and edited /etc/nova/nova.conf and changed novncproxy_base_url from .. to http://cloudy.mymachine.org:6080/vnc_auto.html (http://cloudy.mymachine.org:6080/vnc_...) . This time the remote PC browser attempted to connect to the correct machine but fellover with "Unable to connect" (all port forwarding checked and working OK).

Mealwhile back on the desktop all-in-one installation I tried to view a VM console, but here too I am now getting "Unable to connect". After trial and error it seems that if nova.conf has the IP rather than a FQDN all works OK (but I need a FQDN for the remote system to use).

I'd appreciate any pointers to what it is I'm doing wrong / not understanding. Below is a line from the horizon.log which shows reference to even after removing reference to IP's. Do I need to hand edit something in the Db?

2014-04-20 15:55:48,729 2147 DEBUG openstack_dashboard.api.nova novaclient connection created using token "0011c673902b9ce2979f438ac75afb73" and url ""

O/S Centos 6.5 Havana 7 (Installed 3 days ago)

Thanks for your time.

edit retag flag offensive close merge delete


Try to run on remote host (with replaced by your IP of AIO Havana instance) :-

    ssh -L 5900: -N -f -l root
    ssh -L 5901: -N -f -l root
    ssh -L 5902: -N -f -l root
    ssh -L 5903: -N -f -l root
    ssh -L 5904: -N -f -l root

Just issue on remote host 
$ vncviewer localhost:590(X)
0 for first instance started
1 for second and etc.
See what happens ?
dbaxps gravatar imagedbaxps ( 2014-04-20 13:59:21 -0600 )edit

3 answers

Sort by ยป oldest newest most voted

answered 2014-04-20 14:22:21 -0600

dbaxps gravatar image

updated 2014-04-22 12:48:02 -0600

Keep AIO install as it is. No changes.
Run on remote host :-

# ssh -L 5900: -N -f -l root
# ssh -L 5901: -N -f -l root
# ssh -L 5902: -N -f -l root
# ssh -L 5903: -N -f -l root
# ssh -L 5904: -N -f -l root

Just issue on remote host

    $ vncviewer localhost:590(X)
    0 for first instance started
    1 for second and etc.
    See what happens ?

You should be able to launch browser to without port mapping.
 I would expect you to be prompted for login ,  without port mapping.
 Just use ipv4 iptables firewall with port 6080 open, e.g. /etc/sysconfig/iptables should have entry
 -A INPUT -p tcp -m multiport --dports 6080 -m comment --comment "001 novncproxy incoming" -j ACCEPT 
# service iptables restart (after adding this raw)
In case of failure - just one mapping
# ssh -L 6080: -N -f -l root

Also set ALLOWED_HOSTS = ['*'] in /etc/openstack-dashboard/local_settings and restart httpd

edit flag offensive delete link more


Not to confirm every time root password you may run on AIO Server

# ssh-keygen (Hit Enter to accept all of the defaults)
# ssh-copy-id -i ~/.ssh/id_rsa.pub root@IP_OF_REMOTE
dbaxps gravatar imagedbaxps ( 2014-04-20 14:32:14 -0600 )edit

answered 2014-04-22 09:09:17 -0600

Laurie gravatar image

Whoever said it would be easy? OK, I'll try and keep things as short & concise as possible. Thanks for the tips on the port forwarding. Port forwarding and firewalling is working as expected. I can ..

Remote Client Shell> vncviewer cloud.machine.org:0 (a vnc session comes up as expected).

If I go via horizon on the remote client all horizon functions work as expected, except the console option. It reports ...

"The connection to the server was reset while the page was loading."

Back on the server a tcpdump confirms that packets from the remote client did arrive and that a reset was sent back.

Note: The server never gets to send vnc data (port 5900) back to the remote client ....

Server Shell> tcpdump -i br-ex -n | grep 6080

23:59:28.662756 IP 92.238.xxx.xx.39577 > Flags [S], seq 1681964537, win 14600, options [mss 1460,sackOK,TS val 144927761 ecr 0,nop,wscale 4], length 0

23:59:28.662804 IP > 92.238.xxx.xx.39577: Flags [S.], seq 1348706998, ack 1681964538, win 14480, options [mss 1460,sackOK,TS val 5479782 ecr 144927761,nop,wscale 7], length 0

23:59:28.708602 IP 92.238.xxx.xx.39577 > Flags [.], ack 1, win 913, options [nop,nop,TS val 144927773 ecr 5479782], length 0

23:59:28.826933 IP 92.238.xxx.xx.39577 > Flags [P.], seq 2897:3453, ack 1, win 913, options [nop,nop,TS val 144927800 ecr 5479782], length 556

23:59:28.826990 IP > 92.238.xxx.xx.39577: Flags [.], ack 1, win 114, options [nop,nop,TS val 5479946 ecr 144927773,nop,nop,sack 1 {2897:3453}], length 0

23:59:31.715257 IP > 92.238.xxx.xx.39577: Flags [F.], seq 1, ack 1, win 114, options [nop,nop,TS val 5482834 ecr 144927773,nop,nop,sack 1 {2897:3453}], length 0

23:59:31.760771 IP 92.238.xxx.xx.39577 > Flags [F.], seq 3453, ack 2, win 913, options [nop,nop,TS val 144928536 ecr 5482834], length 0

23:59:31.760835 IP > 92.238.xxx.xx.39577: Flags [R], seq 1348707000, win 0, length 0

If I run, "nova get-vnc-console instance-name novnc" on the server, it generates the url ...

http://cloud.machine.org:6080/vnc_auto.html?token=4460a346-1900-4e87-b35f-cd36d24d7854 (http://cloud.machine.org:6080/vnc_aut...)

When I cut and paste the url into the server or remote client browser all runs as expected. A vnc session in the browser!

Conclusion: It would seem to be an issue with novncproxy. I know it's receiving the traffic, I also know it's issuing a reset.

I don't seem to have a /var/log/noxvncproxy.log on the system (should I?), here's what I have in /var/log/nova ...

edit flag offensive delete link more

answered 2014-04-29 06:28:54 -0600

Laurie gravatar image

SOLVED. The problem was caused by a firewall rule at the client. I got someone else to try logging in remotely (horizon) and then access the console in the browser from another machine. It all worked.

Next task is to find out what was causing the problem on the remote although I suspect other snags (misunderstandings) will rear their head before I get chance. Thanks for all the suggestions.

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools


Asked: 2014-04-20 11:58:33 -0600

Seen: 2,445 times

Last updated: Apr 29 '14