External/Floating outgoing/incoming network
I have used following steps to test this.
- Create tenant network, tenant subnet
- Create shared router
- For external network, I have created external network ext-net outside of script because we have to do some manual stuff here. For external networking make sure physical Ethernet port is added into external bridge br-ex and network configuration file ifcfg-br-ex and ifcfg-ethX is created with relevant info.
- Add tenant network interface to router and set gateway of router to external network.
- Create VM instance into tenant network.
- Create and assign floating IP to VM
- Add security rule for PING and SSH testing.
- For external/outgoing access ping to 184.108.40.206 (google DNS) from VM and for floating incoming access ssh to VM using floating IP from outside.
Continue reading “Neutron Validation Testing Part 3” →
Tenant to tenant networking with different subnet
For tenant to tenant networking I used following steps.
- Create first tenant, tenant network, tenant subnet
- Create second tenant, tenant network, tenant subnet
- Create router in admin tenant and add both tenant interface to it.
- Create 2 VMs instance into two different tenant network.
- Add security rule for PING and SSH testing.
- Ping to each other using network namespace.
Continue reading “Neutron Validation Testing Part 2” →
All test are performed from standalone VM outside of the OpenStack cloud. First, establish passwordless SSH authentication between Standalone VM and OpenStack controller. Use following method to invoke the script from standalone VM which will run o on controller VM and get the details.
ssh –T <controller hostname/ip> < script.sh
Here –T Disable pseudo-tty allocation from VM
External and Internal API networking.
I was busy studying OpenStack Foundation’s COA exam so couldn’t publish blog post for a while.
Luckily I have passed the COA exam and hard work pays off. As I have passed this so thought of sharing my experience with the exam.
This post is basically contains some tips/info about OpenStack Foundation (COA) Certified OpenStack Administrator exam.
Certified OpenStack Administrator (COA) is the first professional certification offered by the OpenStack Foundation. It’s designed to help companies identify top talent in the industry, and help job seekers demonstrate their skills.
The Certified OpenStack Administrator is a professional typically with at least six months of OpenStack experience, and has the skills required to provide day-to-day operation and management of an OpenStack cloud.
The current exam is based on the OpenStack Liberty version and covers the core compute, storage and networking services. To learn more about the knowledge requirements and domains covered in the exam, go to www.openstack.org/coa/requirements.
Continue reading “Tips to pass OpenStack Foundation (COA) Certified OpenStack Administrator exam.” →
We can install Openstack using many tool Devstack and Packstack are two of them. In my last post I have shared Openstack Installation using Packstack on CentOS 7. In this post I am going through step by step Openstack installation using Devstack on Ubuntu 16.04.ive
I am using VirtualBox VM with following configuration.
OS – Ubuntu 16.04
RAM – 7168MB
Disk – 40GB
vCPU – 2
Network – One bridged ethernet adapter with static IP.
1. Install Ubuntu minimal server on VM and perform apt-get update and upgrade and reboot the machine.
2. Configure Bridged ethernet adapter with static IP and give relevant hostname to machine.
stack@Mitakastack:~/devstack$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
iface lo inet loopback
# The primary network interface
iface enp0s3 inet static
stack@Mitakastack:~/devstack$ cat /etc/hostname
Continue reading “Openstack Mitaka Installation using Devstack on Ubuntu 16.04” →
Mitaka is 13th release of Openstack. Following are some of the notable features in Mitaka.
- Real-time Kernel-based Virtual Machine (KVM) compute nodes and custom CPU thread policies
- Live migration improvements
- Rolling upgrades in Cinder
- Disaster recovery share-replication application programming interface (API) support
- Tenant resources cleanup
- Improved security groups performance
I have configured allinone Openstack Mitaka setup on one Virtual VM using VirtaulBox.
My Virtual VM configuration are as follows.
OS – CentOS 7.2
RAM – 7168MB
Storage – 40GB
Network – One bridged adpater with static IP
vCPU – 2
Install CentOS 7.2 on VM and update to latest level and reboot the system.
Continue reading “Openstack Mitaka Installation using packstack on CentOS 7” →
I came across some good info about the difference between two major Iaas provider Openstack and VMware. So thought of sharing with this blog. Couple of differences are as follows.
Continue reading “Compare Openstack Vs VMware” →
We saw volume creation with related issues and probable solutions.
Now we will see volume attach to VM. Create partition on it. Remove it and detach volume from VM.
Attach created volume to testvm. Following is command-line requirement for cinder volume-attach.
Volume ID will get it from cinder-list use auto to autoassign the new device.
You can check volume status is changed to in-use now and also changed attached with VM ID.
Continue reading “Basic Cinder (volume) service functionality in Openstack – Part2” →
In this post I am going to show you basic functionality of openstack cinder (volume) service functionality by creating volume on internal storage. Attaching that volume to VM. Create partition on that volume in client machine and test partition remove and detaching volume from VM.
Lets take one running state vm for cinder testing as we can do this operation on the fly. I have one VM name testvm.
Check the disk and partitions on the VM. I can access the testvm using private IP and public IP. Lets access it using private IP using unique network namespace.
First check private-net network ID and test the ping to private IP of VM using network namespace. For more details about basic networking in openstack check my last blog posts.
Continue reading “Basic Cinder (volume) service functionality in Openstack – Part1” →
When you installed Openstack using packstack you might have faced openstack-keystone service issue. When try it to restart it fails with code-name keystone error.
I have done some research on it and found the solution.
The issue is with Openstack Keystone Service which we have configured using httpd deamon in answers.cfg file ( configuration file used to install Openstack using packstack)
Now openstack-keystone service will not start as http service is already in started mode and we haven’t created any relation between openstack-keystone and http service.
So to start openstack-keystone service we have to create symbolic link and point openstack-keystone service to http service.
Continue reading “Failed to start OpenStack Identity Service (code-named Keystone).” →