Can we send requests directly on a bare metal machine in OpenStack? - networking

Do I need Controllers and Neutron nodes to send requests on a bare metal machine in OpenStack? Can we send requests directly on a bare metal machine without passing them through controller/neutron nodes?

Provider networking allows you to attach Nova instances directly to existing layer 2 networks so that they do not need to transit the Neutron controller for either local or external network access. You can mix-and-match provider networks with normal OpenStack virtual networks depending on your needs and available network resources.
This same solution would allow baremetal machines to communicate without involving the Neutron host.

Related

Use more than one physical interface on devstack ocata

I have a barebones PC with 6 physical interfaces to 'play' around with devstack. I'd like to deploy VMs on it and connect them to different Ethernet interfaces. Currently, I'm only able to use the interface associated to the br-ex bridge. I've tried to define several OVS bridges and assign the physical interfaces to different bridges. I try to define a mapping with more than one bridge, but that doesn't seem to work.
Has anyone had any success on this.
Thanks, /PA
You will need to create "provider networks", which allow you to associate neutron networks with specific physical interfaces. You can find documentation on creating provider networks in the install guide.
Once everything is configured correctly, you can attach new Nova servers to your provider networks by passing the appropriate --network argument when you boot a new server.

Openstack allow api access from vm

We are currently using Openstack newtown. We can access the API using client on public endpoint from any computer, but the vm don't have access to it, they can ping the IP and dns name but can't curl or access using openstack-client. How can we allow connection from VM to API ?
Assuming your public API endpoint is externally accessible, the network on which your virtual machine resides will need external access. This can be achieved in a few different ways, depending on your current configuration. You can create a Neutron provider network/subnet which will provide access to a physical network and gateway to the outside world. You can then boot your instance directly on the provider network. More information on Neutron provider networks can be found at docs.openstack.org.
The problem is that floating IP don't give the route of my external network.
I add route using neutron and now all is working perfectly. for info the command is:
neutron router-update demo-routeur --routes type=dict list=true destination=192.168.0.27/27,nexthop=10.0.0.1

OpenStack Compute-node communicate/ping vms run on it

In Ceilometer, when pollsters collect meter from VMs, it used hypervisor on compute-node. Now, I want to write new plugin for ceilometer and not use hypervisor to collect meter, I want to collect meter by a service that is installed on VMs (mean ceilometer get data from service), so I need compute-node must communicate with VMs by IP (private IP). Is there any solution to do this?
Thanks all.
In general the internal network used by your Nova instances is kept intentionally separate from the compute hosts themselves as a security precaution (to ensure that someone logged into a Nova server isn't able to compromise your host).
For what you are proposing, it would be better to adopt a push model rather than a pull model: have a service running inside your instances that would publish data to some service accessible at a routeable ip address.

Communication between tenant network and existing network in openstack

I am trying to make the tenant network communicate with an existing network which did not build in OpenStack. we all know we can allocate a floating IP to VM with external network, but now we have no need access Internet, so we would not allocate IP to VM, just want to make tenant VM can communicate with another network, how do I map the existing network to OpenStack and create router between them?
Any help would be appreciated.Thanks!
There are certain steps to do this.
You need to add a routing entry for the tenant network in compute nodes.
You need to use Masquerading on compute node.
I think with this configuration you will be able to establish communication between tenant network and existing physical network.

Openstack with neutron on two physical nodes

We have two physical system(ubuntu14.04.2) having 2 physical NIC each.
Is it possible to install openstack(juno) with neutron on same ?
Official documentation says that we need 3 nodes with network node having 3 NICs
Any help would be greatly appreciated.
Thanks,
Deepak
You can install all of OpenStack on a single system for development and testing purposes. Given that a single node installation is possible, it should follow that a two-node installation is also possible (and it is).
The documentation recommends three NICs because this leads to the simplest configuration. However, you can run a network host with two NICs. There are several different traffic types you'll be dealing with:
Public web (Horizon) traffic
Public API traffic (if you expose the APIs)
Internal API traffic
Tenant internal network traffic (traffic between Nova instances and the compute host)
Tenant external network traffic (traffic between Nova instances and "the rest of the world")
Storage (transferring Glance images, iSCSI for Cinder volumes, etc)
Being able to segment these in a meaningful fashion can lead to a more manageable and more performant environment. With only two NICs, you are probably looking at one for "internal traffic" (interal api, storage, tenant internal networking, etc) and one for "external traffic" (dashboard, public apis, tenant external traffic). This is certainly possible, but it means, for example, that excessive traffic from your tenants can impact access to the dashboard, and that a high volume of storage traffic can impact access to Nova instances.
If/when your environment grows beyond two nodes, you may want to investigate adding additional NICs to your configuration.

Resources