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 \
MyFirstInstance
Login to instance
# ip netns
# ip netns exec NETNS_NAME ssh USER@SERVER
# ip netns exec qdhcp-6021a3b4-8587-4f9c-8064-0103885dfba2 \
ssh cirros@10.0.0.2
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
Pause
$ nova pause NAME
$ nova pause volumeTwoImage
Unpause
$ nova unpause NAME
Suspend
$ nova suspend NAME
Unsuspend
$ nova resume NAME
Stop
$ nova stop NAME
Start
$ nova start NAME
Rescue
$ nova rescue NAME
$ nova rescue NAME --rescue_image_ref RESCUE_IMAGE
Resize
$ nova resize NAME FLAVOR
$ nova resize my-pem-server m1.small
$ nova resize-confirm my-pem-server1
Rebuild
$ nova rebuild NAME IMAGE
$ nova rebuild newtinny cirros-qcow2
Reboot
$ 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@10.0.0.4
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 10.0.0.0/29
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
Note
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:
/var/log/$service/$service_component
.
For example, logs from the glance-api service are found in:
/var/log/glance/api.log
Logs from the nova-api service are found in:
/var/log/nova/nova-api.log
If you don't see a log for the service you're trying to troubleshoot, look in:
/var/log/upstart
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:
- Edit the service's configuration file.
- In the file, set the verbose or debug boolean to True.
- Save the file.
- 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:
- Edit data/hiera_data/common.yaml
- In the file, set the verbose or debug flag to true: debug: true and verbose: true
- Save the file.
- Do a Puppet catalog run or restart Puppet.
