Welcome to the Cloud : Openstack Common troubleshooting commands

Today I am going to talk about the Openstack common issues and the troubleshoot commands used and these are very important commands to help for the experts to troubleshoot.

The question is now what is openstack ? why and where we are using the openstack services ?
Talking about the OpenStack, It is a set of software tools for building and managing cloud computing platforms for public and private clouds. Openstack is funded and supported by some of the biggest companies in software development and hosting, as well as thousands of individual community members, many think that OpenStack is the future of cloud computing. 

OpenStack is managed by the openstack foundation a non-profit that oversees both development and community-building around the project.

Below is the basic architecture diagram of OpenStack just to understand the complete life cycle.

Fig 1.1- OpenStack Architecture

Now the question is what is the purpose of the Openstack, OpenStack lets users deploy Virtual Machines (VM) and other instances that handle different tasks for managing a cloud environment on the fly. It makes horizontal scaling easy, which means that tasks that benefit from running concurrently can easily serve more or fewer users on the fly by just spinning up more instances. 

For example, a mobile application that needs to communicate with a remote server might be able to divide the work of communicating with each user across many different instances, all communicating with one another but scaling quickly and easily as the application gains more users.

Troubleshooting Commands

Identity (keystone)
List all users
$ openstack user list
List Identity service catalog
$ openstack catalog list

Images (glance)
List images you can access
$ glance image-list
Delete specified image
$ glance image-delete IMAGE
Describe a specific image
$ glance image-show IMAGE
Update image
$ glance image-update IMAGE
Upload kernel image
$ glance image-create --name "cirros-threepart-kernel" \
  --disk-format aki --container-format aki --is-public False \
  --file ~/images/cirros-0.3.1~pre4-x86_64-vmlinuz

Upload RAM image
$ glance image-create --name "cirros-threepart-ramdisk" \
  --disk-format ari --container-format ari --is-public False \
  --file ~/images/cirros-0.3.1~pre4-x86_64-initrd
Upload three-part image
$ glance image-create --name "cirros-threepart" --disk-format ami \
  --container-format ami --is-public False \
  --property kernel_id=$KID-property ramdisk_id=$RID \
  --file ~/images/cirros-0.3.1~pre4-x86_64-blank.img
Register raw image
$ glance image-create --name "cirros-raw" --disk-format raw \
  --container-format bare --is-public False \
  --file ~/images/cirros-0.3.1~pre4-x86_64-disk.img

Compute (nova)
List instances, check status of instance
$ nova list
List images
$ nova image-list
List flavors
$ nova flavor-list
Boot an instance using flavor and image names (if names are unique)
$ nova boot --image IMAGE --flavor FLAVOR INSTANCE_NAME
$ nova boot --image cirros-0.3.1-x86_64-uec --flavor m1.tiny \
Login to instance
# ip netns
# ip netns exec NETNS_NAME ssh USER@SERVER
# ip netns exec qdhcp-6021a3b4-8587-4f9c-8064-0103885dfba2 \
  ssh cirros@

Show details of instance
$ nova show NAME
$ nova show MyFirstInstance
View console log of instance
$ nova console-log MyFirstInstance
Set metadata on an instance
$ nova meta volumeTwoImage set newmeta='my meta data'
Create an instance snapshot
$ nova image-create volumeTwoImage snapshotOfVolumeImage
$ nova image-show snapshotOfVolumeImage

Pause, suspend, stop, rescue, resize, rebuild, reboot an instance
$ nova pause NAME
$ nova pause volumeTwoImage
$ nova unpause NAME
$ nova suspend NAME
$ nova resume NAME
$ nova stop NAME
$ nova start NAME
$ nova rescue NAME
$ nova rescue NAME --rescue_image_ref RESCUE_IMAGE
$ nova resize NAME FLAVOR
$ nova resize my-pem-server m1.small
$ nova resize-confirm my-pem-server1
$ nova rebuild NAME IMAGE
$ nova rebuild newtinny cirros-qcow2
$ nova reboot NAME
$ nova reboot newtinny
Inject user data and files into an instance
$ nova boot --user-data FILE INSTANCE
$ nova boot --user-data userdata.txt --image cirros-qcow2 \
  --flavor m1.tiny MyUserdataInstance2
To validate that the file was injected, use ssh to connect to the instance, and look in /var/lib/cloud for the file.
Inject a keypair into an instance and access the instance with that keypair
Create keypair
$ nova keypair-add test > test.pem
$ chmod 600 test.pem
Start an instance (boot)
$ nova boot --image cirros-0.3.0-x86_64 --flavor m1.small \
  --key_name test MyFirstServer
Use ssh to connect to the instance
# ip netns exec qdhcp-98f09f1e-64c4-4301-a897-5067ee6d544f \
  ssh -i test.pem cirros@
Manage security groups
Add rules to default security group allowing ping and SSH between instances in the default security group
$ nova secgroup-add-group-rule default default icmp -1 -1
$ nova secgroup-add-group-rule default default tcp 22 22

Networking (neutron)
Create network
$ neutron net-create NAME
Create a subnet
$ neutron subnet-create NETWORK_NAME CIDR
$ neutron subnet-create my-network

Block Storage (cinder)
Used to manage volumes and volume snapshots that attach to instances.
Create a new volume
$ cinder create SIZE_IN_GB --display-name NAME
$ cinder create 1 --display-name MyFirstVolume
Boot an instance and attach to volume
$ nova boot --image cirros-qcow2 --flavor m1.tiny MyVolumeInstance
List volumes, notice status of volume
$ cinder list
Attach volume to instance after instance is active, and volume is available
$ nova volume-attach INSTANCE_ID VOLUME_ID auto
$ nova volume-attach MyVolumeInstance 573e024d-5235-49ce-8332-be1576d323f8 auto


On the Xen Hypervisor it is possible to provide a specific device name instead of automatic allocation. For example:
$ nova volume-attach MyVolumeInstance 573e024d-5235-49ce-8332-be1576d323f8 /dev/vdb
This is not currently possible when using non-Xen hypervisors with OpenStack.
Manage volumes after login into the instance

List storage devices
# fdisk -l
Make filesystem on volume
# mkfs.ext3 /dev/vdb
Create a mountpoint
# mkdir /myspace
Mount the volume at the mountpoint
# mount /dev/vdb /myspace
Create a file on the volume
# touch /myspace/helloworld.txt
# ls /myspace
Unmount the volume
# umount /myspace

Object Storage (swift)
Display information for the account, container, or object
$ swift stat
$ swift stat ACCOUNT
$ swift stat CONTAINER
$ swift stat OBJECT
List containers
$ swift list

Required troubleshooting data collection 
The logfiles for OpenStack services are one of the primary tools for troubleshooting problems with OpenStack.
Most OpenStack logfiles are named following this convention:
For example, logs from the glance-api service are found in:
Logs from the nova-api service are found in:
If you don't see a log for the service you're trying to troubleshoot, look in:
A log file is sometimes created there instead.
It may help in troubleshooting to enable verbose (more detailed diagnostic messages) logging or debug (lower level traces) logging for an OpenStack service or for all OpenStack services.
To enable verbose or debug logging for an OpenStack service:
  1. Edit the service's configuration file.
  2. In the file, set the verbose or debug boolean to True.
  3. Save the file.
  4. Restart the service.
Note: Some OpenStack services might not have verbose or debug flags. Instead, you can try enabling verbose or debug logging for all OpenStack services, below.
To enable verbose or debug logging for all OpenStack services:
  1. Edit data/hiera_data/common.yaml
  2. In the file, set the verbose or debug flag to true: debug: true and verbose: true
  3. Save the file.
  4. Do a Puppet catalog run or restart Puppet.