[rhos-list] Nova-network woes (Vnc issue now)

Kashif Mohammad k.mohammad1 at physics.ox.ac.uk
Fri Mar 22 10:19:59 UTC 2013


Hi

As I mentioned earlier that now everything is working except vnc access. I tried many options but nothing seems to be working. One suspicious thing is that nova-vncproxy is running without nova.conf file

nova      2170  0.0  0.1 236268 17148 ?        S    Mar21   0:01 python /usr/bin/nova-novncproxy --web /usr/share/novnc/ 

is that expected behaviour ? Looking at /etc/init.d/openstack-nova-novncproxy it seems to be expected behaviour

daemon --user nova --pidfile $pidfile "$exec --web /usr/share/novnc/ &>/dev/null & echo \$! > $pidfile"


Can any one confirm this please. I am using  openstack-nova-novncproxy-0.4-2.el6.noarch from folsom redhat repo. 

Cheers
Kashif


-----Original Message-----
From: rhos-list-bounces at redhat.com [mailto:rhos-list-bounces at redhat.com] On Behalf Of Kashif Mohammad
Sent: 21 March 2013 15:47
To: Brent Eagles
Cc: rhos-list at redhat.com
Subject: Re: [rhos-list] Nova-network woes

Hi Brent

Thanks for looking into it. Fixed one of the main issue so my vm can get access to internet. I have one public and one private ip on my compute node and have defined private ip as my_ip in nova.conf at compute node. Looking more deeply I found that routing_source_ip defaults to $my_ip.

Explicitly defined routing_source_ip to public ip address and it started working. Nova network is now creating correct iptables rule so vm can access internet. 

>> iptables -A POSTROUTING -t mangle -p udp --dport 68 -j CHECKSUM --checksum-fill

Found the solution here
https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/issues/14 


But  still my vnc not working. Running openstack-nova-consoleauth, openstack-nova-novncproxy openstack-nova-xvpvncproxy on controller node. I have this configuration in nova.conf at controller node
novnc_enabled = true
vnc_enabled = true
novncproxy_base_url = http://163.1.5.243:6080/vnc_auto.html
xvpvncproxy_base_url = http://163.1.5.243:6081/console
 


On Compute node 
vnc_enabled = true
novnc_enabled = true
novncproxy_base_url = http://163.1.5.243:6080/vnc_auto.html
xvpvncproxy_base_url = http://163.1.5.243:6081/console
vncserver_proxyclient_address = 192.168.9.3
vncserver_listen = 0.0.0.0


I can get vnc url using get-vnc-console so probably authentication bit is working but when I try to access vnc console through browser it just give this error
Failed to connect to server (code: 1006) 

Get same error if try to connect through horizon dashboard. I will very much appreciate your help. 

Cheers
Kashif


-----Original Message-----
From: Brent Eagles [mailto:beagles at redhat.com] 
Sent: 21 March 2013 15:20
To: Kashif Mohammad
Cc: rhos-list at redhat.com
Subject: Re: [rhos-list] Nova-network woes

Hi Kashif,

On Wed, Mar 20, 2013 at 05:23:16PM +0000, Kashif Mohammad wrote:
> 
> Hi Guys
> 
> I am using rhel6.4 and RedHat Openstack Folsom rpms. I have  one
> controller node which is running glance, cinder, scheduler, api
> server, consoleauth and other node is running compute, network and
> api. Both nodes have one public and one private IP and running in
> multi_host mode.
> 
> I am not running nova-network and nova-compute on controller node.
> Network bit is like this on compute node
> 
> public_interface = em1
> flat_interface = em2
> fixed_range = 10.0.1.0/24
> flat_network_dhcp_start = 10.0.1.5
> connection_type = libvirt
> flat_injected = False
> multi_host = True
> flat_network_bridge = br100
> 
> created network like this
> nova-manage network create private 10.0.1.0/24 1 256 --bridge=br100 --multi_host=True

I would try running nova-manage using the keyword=value approach instead
of relying on positional arguments (e.g.  --fixed_range_ipv4=10.0.1.0/24). 
It would avoid issues with getting the order wrong which can lead to
surprising results.

> I can create VM through dashboard and initially it couldn't get ip
> address from dhcp server running on compute node but after adding 
> 
> iptables -A POSTROUTING -t mangle -p udp --dport 68 -j CHECKSUM --checksum-fill

Mmmm.. if everything is configured properly, you shouldn't have to
modify the firewall rules for this to work. Was there something you came
across while debugging your setup that gave you the idea to add this?

> it is getting ip address and I can log in into vm from compute node.
> It can reach metadata server and grab public keys.  My problem is that
> VM's can not access outside word. I think that issue is in this line
> of iptable
> 
> 47  3247 nova-network-float-snat  all  --  any    any     anywhere             anywhere
>     2   168 SNAT       all  --  any    em1     10.0.1.0/24          anywhere            to:192.168.9.3
> 
> It is changing source IP address to local ip rather than external ip. If insert a rule
>
> iptables -t nat -I nova-network-snat 2 -o em1 -j SNAT --to-source 163.1.5.40 

That's weird. Can you describe how you configured and allocated the floating IPs? This
is another thing that generally just works.

> Then it vm can access interner but the moment I create a new VM this line disappear from iptable.
> 
> My n/w setting is like this
> 
> 2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
>     link/ether 00:22:19:6a:bc:09 brd ff:ff:ff:ff:ff:ff
>     inet 163.1.5.40/24 brd 163.1.5.255 scope global em1
>     inet6 fe80::222:19ff:fe6a:bc09/64 scope link
>        valid_lft forever preferred_lft forever
> 3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
>     link/ether 00:22:19:6a:bc:0b brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::222:19ff:fe6a:bc0b/64 scope link
>        valid_lft forever preferred_lft forever
> 5:  br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
>     link/ether 00:22:19:6a:bc:0b brd ff:ff:ff:ff:ff:ff
>     inet 10.0.1.1/24 brd 10.0.1.255 scope global br100
>     inet 192.168.9.3/24 brd 192.168.9.255 scope global br100
>     inet6 fe80::80cd:6fff:fef7:d955/64 scope link
>        valid_lft forever preferred_lft forever
> 
> I can not reach vnc as well but I first fix this n/w issue and then look into vnc.
> 
> Thanks
> Kashif 

Heh. No VNC? It is the one thing you should *not* live without! I would
say that something got crossed during configuration. You might want to
"back up" to the beginning and try each thing in turn. If the "cookbook"
type instructions didn't work as described, it might be best to figure
out why instead of tweaking until things just kind of work. As one bit
of configuration tends to depend on another, if the most fundamental
thing does not work properly (e.g.  allocating a private IP to a VM) it
is very possible that things are going to go awry with other
configuration items (e.g. allocating floating IPs). 

However, instead of just leaving with you a note to "try again", and it
is just a thought/guess, but if iptables is giving you grief and you
have a pre-existing firewall configuration, you might want to look for
rules that might interfere with what openstack is trying to do.  What I
have done in the past when trying a new configuration is take a snapshot
of the current configuration with iptables-save (e.g.  iptables-save >
iptables.before) and again when everything is "done" (iptables.after?)
and visually compare the two. It is useful pedagogically because I see
what Openstack is doing and it helps identify configuration (and
sometimes bugs!) before I go too far.

Cheers,

Brent

_______________________________________________
rhos-list mailing list
rhos-list at redhat.com
https://www.redhat.com/mailman/listinfo/rhos-list




More information about the rhos-list mailing list