Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Operators

can connect to VM locally, but not from outside

 

 

OpenStack operators RSS feed   Index | Next | Previous | View Threaded


trapni at gmail

Apr 12, 2012, 11:37 AM

Post #1 of 4 (178 views)
Permalink
can connect to VM locally, but not from outside

Hi,

I can connect to my newly created VM from within its compute node,
but not from any other host, and this is, I guess, due to some networking
configuration/design mess.

The goal is, to have one big 10.10.0.0/16 network in our data center,

10.10.1x.yy -> IPMI
10.10.2x.yy -> switches, PDUs, ...
10.10.3x.yy -> physical nodes
*10.10.4x.yy -> VMs
*
so basically, I have assigned all physical nodes an IP like br0:
10.10.30.190/16, with eth0 already joined to br0, and everything works fine
:)

Now, comes the nova mess :(....

# cat /etc/nova/nova.conf
--use_console_monitor=True

--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/usr/bin/nova-dhcpbridge
--logdir=/var/log/nova
--state_path=/var/lib/nova
--lock_path=/var/lock/nova

--allow_admin_api=true
--use_deprecated_auth=false
--auth_strategy=keystone

--scheduler_driver=nova.scheduler.simple.SimpleScheduler

--s3_host=10.10.30.190
--ec2_host=10.10.30.190
--rabbit_host=10.10.30.190
--cc_host=10.10.30.190
--nova_url=http://10.10.30.190:8774/v1.1/
--glance_api_servers=10.10.30.190:9292
--image_service=nova.image.glance.GlanceImageService
--glance_host=10.10.30.190
--sql_connection=mysql://novadbadmin:********@10.10.30.190/nova

--ec2_url=http://10.10.30.190:8773/services/Cloud
--keystone_ec2_url=http://10.10.30.190:5000/v2.0/ec2tokens

--api_paste_config=/etc/nova/api-paste.ini

--libvirt_type=kvm
--libvirt_use_virtio_for_bridges=true

--start_guests_on_host_boot=true
--resume_guests_state_on_host_boot=true

# ----- VNC
--vnc_enabled=true
--vncproxy_url=http://10.10.30.190:6080
--vnc_console_proxy_url=http://10.10.30.190:6080

# ----- network specific settings
--network_manager=nova.network.manager.FlatDHCPManager
--public_interface=eth0

--flat_interface=eth0
--flat_network_bridge=br0

# ----- public network
#--floating_range=$public_net/28

# ----- private network
*--routing_source_ip=10.10.30.190
--fixed_range=10.10.0.0/24
--flat_network_dhcp_start=10.10.41.10
--network_size=512
*--force_dhcp_release
--flat_injected=False

--iscsi_helper=tgtadm
--iscsi_ip_prefix=10.10.52 # ?

--connection_type=libvirt
--root_helper=sudo nova-rootwrap
--verbose
# eof

I tried different approaches in getting this run, and I remember the last
time I tried to set nova up, it worked (somehow? I did something handy to
the routing table? can't remember, unfortunately)...

I use a big 10.10/16 network so that we don't bloat the VPN client scripts
with additional routes everyone (who should know) must know about, and for
(I hoped) ease of simplicity.

I chose not to use VLAN because even tough our switches are VLAN capable
I'd like to avoid the extra overhead for now, because I'd like to get it
basically up'n'running and not delay my first experience yet another week
:-)

Has anyone an idea on how I could achieve getting every IP to where it
belongs to?

Many thanks in advance,
Christian.


ogelbukh at mirantis

Apr 13, 2012, 4:57 AM

Post #2 of 4 (174 views)
Permalink
Re: can connect to VM locally, but not from outside [In reply to]

Hello,

Did you check ip_forward setting on your nova-network node? This is turned
on by libvirt on compute nodes, but not by nova-network on gateway machine.
And it is turned off by default in most Linux distros.

Command to check:
# sysctl -a | grep net.ipv4.ip_forward
net.ipv4.ip_forward = 1

If value is 0, you need to set it to 1 with sysctl -w:
# sysctl -w net.ipv4.ip_forward=1

--
Best regards,
Oleg

On Thu, Apr 12, 2012 at 10:37 PM, Christian Parpart <trapni [at] gmail>wrote:

> Hi,
>
> I can connect to my newly created VM from within its compute node,
> but not from any other host, and this is, I guess, due to some networking
> configuration/design mess.
>
> The goal is, to have one big 10.10.0.0/16 network in our data center,
>
> 10.10.1x.yy -> IPMI
> 10.10.2x.yy -> switches, PDUs, ...
> 10.10.3x.yy -> physical nodes
> *10.10.4x.yy -> VMs
> *
> so basically, I have assigned all physical nodes an IP like br0:
> 10.10.30.190/16, with eth0 already joined to br0, and everything works
> fine :)
>
> Now, comes the nova mess :(....
>
> # cat /etc/nova/nova.conf
> --use_console_monitor=True
>
> --dhcpbridge_flagfile=/etc/nova/nova.conf
> --dhcpbridge=/usr/bin/nova-dhcpbridge
> --logdir=/var/log/nova
> --state_path=/var/lib/nova
> --lock_path=/var/lock/nova
>
> --allow_admin_api=true
> --use_deprecated_auth=false
> --auth_strategy=keystone
>
> --scheduler_driver=nova.scheduler.simple.SimpleScheduler
>
> --s3_host=10.10.30.190
> --ec2_host=10.10.30.190
> --rabbit_host=10.10.30.190
> --cc_host=10.10.30.190
> --nova_url=http://10.10.30.190:8774/v1.1/
> --glance_api_servers=10.10.30.190:9292
> --image_service=nova.image.glance.GlanceImageService
> --glance_host=10.10.30.190
> --sql_connection=mysql://novadbadmin:********@10.10.30.190/nova
>
> --ec2_url=http://10.10.30.190:8773/services/Cloud
> --keystone_ec2_url=http://10.10.30.190:5000/v2.0/ec2tokens
>
> --api_paste_config=/etc/nova/api-paste.ini
>
> --libvirt_type=kvm
> --libvirt_use_virtio_for_bridges=true
>
> --start_guests_on_host_boot=true
> --resume_guests_state_on_host_boot=true
>
> # ----- VNC
> --vnc_enabled=true
> --vncproxy_url=http://10.10.30.190:6080
> --vnc_console_proxy_url=http://10.10.30.190:6080
>
> # ----- network specific settings
> --network_manager=nova.network.manager.FlatDHCPManager
> --public_interface=eth0
>
> --flat_interface=eth0
> --flat_network_bridge=br0
>
> # ----- public network
> #--floating_range=$public_net/28
>
> # ----- private network
> *--routing_source_ip=10.10.30.190
> --fixed_range=10.10.0.0/24
> --flat_network_dhcp_start=10.10.41.10
> --network_size=512
> *--force_dhcp_release
> --flat_injected=False
>
> --iscsi_helper=tgtadm
> --iscsi_ip_prefix=10.10.52 # ?
>
> --connection_type=libvirt
> --root_helper=sudo nova-rootwrap
> --verbose
> # eof
>
> I tried different approaches in getting this run, and I remember the last
> time I tried to set nova up, it worked (somehow? I did something handy to
> the routing table? can't remember, unfortunately)...
>
> I use a big 10.10/16 network so that we don't bloat the VPN client scripts
> with additional routes everyone (who should know) must know about, and for
> (I hoped) ease of simplicity.
>
> I chose not to use VLAN because even tough our switches are VLAN capable
> I'd like to avoid the extra overhead for now, because I'd like to get it
> basically up'n'running and not delay my first experience yet another week
> :-)
>
> Has anyone an idea on how I could achieve getting every IP to where it
> belongs to?
>
> Many thanks in advance,
> Christian.
> _______________________________________________
> Openstack-operators mailing list
> Openstack-operators [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


trapni at gmail

Apr 13, 2012, 7:42 AM

Post #3 of 4 (175 views)
Permalink
Re: can connect to VM locally, but not from outside [In reply to]

On Fri, Apr 13, 2012 at 1:57 PM, Oleg Gelbukh <ogelbukh [at] mirantis> wrote:

> Command to check:
> # sysctl -a | grep net.ipv4.ip_forward
> net.ipv4.ip_forward = 1
>

Hey,

yeah, it is set, and thus, unfortunately, wasn't the issue :(

Many thanks,
Christian.


mscherbakov at mirantis

Apr 16, 2012, 5:49 PM

Post #4 of 4 (175 views)
Permalink
Re: can connect to VM locally, but not from outside [In reply to]

Hi Christian,
consider to use VLAN.
Nova designed to have its own DHCP server (unless you use FlatManager),
so your VMs will do DHCP discovery in your L2 network. Which is currently
the same as your management net, where you probably already have dhcp
server.

Regards,

On Fri, Apr 13, 2012 at 7:42 AM, Christian Parpart <trapni [at] gmail> wrote:

>
> On Fri, Apr 13, 2012 at 1:57 PM, Oleg Gelbukh <ogelbukh [at] mirantis>wrote:
>
>> Command to check:
>> # sysctl -a | grep net.ipv4.ip_forward
>> net.ipv4.ip_forward = 1
>>
>
> Hey,
>
> yeah, it is set, and thus, unfortunately, wasn't the issue :(
>
> Many thanks,
> Christian.
>
> _______________________________________________
> Openstack-operators mailing list
> Openstack-operators [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


--
Mike Scherbakov

OpenStack operators RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.