OpenStack Interview Questions and Answers for 2026

If we want to use the snapshots for migrating an instance from the OpenStack projects to the cloud, below are the steps. 

• Create a snapshot for the instance that needs to be migrated. 
• Download that snapshot. 
• Import the snapshot to the new environment. 
• Boot the new instance from the snapshot.

Below are the commands for each step.

Step 1: Create a snapshot for the instance that needs to be migrated. 

Shut down the source VM before taking the snapshot so the data will be flushed to the disk. To check the instance name, run the list command. 

$ nova list  

Shut down the instance. 

$ nova stop myInstance 

Now take a snapshot. 

$ nova image-create --poll myInstance myInstanceSnapshot  

Check the status of the image. 

$ nova image-list 

Step 2: Download that snapshot. 

Get the image ID. 

$ nova image-list 

Download the image using the image ID. 

$ glance image-download --file snapshot.raw f30b204e-1ce6-40e7-b8d9-b353d4d84e7d 

Step 3: Import the snapshot to the new environment. 

Go to the new environment, and import the snapshot. 

$ glance --os-image-api-version 1 image-create \ 
  --container-format bare --disk-format qcow2 --copy-from IMAGE_URL 

Step 4: Boot the new instance from the snapshot. 

Now use the snapshot to create the new instance. 

$ nova boot --flavor m1.tiny --image myInstanceSnapshot myNewInstance

To check the client’s version number, run the following command. 

$ PROJECT --version 

For checking the version number for the OpenStack client, run the following command. 

$ openstack --version

Like other OpenStack services, the telemetry service also has a logging option. We can change the target of logging, the format of the log entries, and the log levels, and other details via ceilometer.conf file. We get a list of configuration options.

We can use the stderr as the standard output for log messages that we can change to logfile or sysfile.

OpenStack provides a filter scheduler that allows us to filter and weigh to make an informed decision regarding where to create a new instance. This scheduler only works with compute nodes.

The filter scheduler goes through all the compute nodes and evaluates them against some set of filers applied. The resulting hosts will be ordered by weight. Then, the scheduler will select a host for the requested number of instances that choose the most weighted hosts. If a scheduler cannot find a host for the next instance, it means there is no perfect match to schedule the instance. If the existing filtering algorithm does not work as expected to provide us with the right result, then we can implement our algorithm

A common and most important OpenStack question for interview, don't miss this one.

Each instance has fixed, private, public, or floating IP addresses. Private IPs are for internal communication among instances; public IPs are for communication within the network but outside the cloud. Whenever we launch an instance, an IP address will be assigned automatically, which will remain the same till its termination, even after reboot.  

The cloud administrator configures a pool of IP addresses available in OpenStack compute. The number of floating IP addresses we can assign to a project depends on the limit set in the quota.  

For managing the floating IP address, we use the OpenStack command. 

Command to list details of the floating IP address. 

$ openstack floating ip pool list 

Command to allocate a floating IP address to a project. 

$ openstack floating ip create public 

Command to associate an IP address with an instance. 

$ openstack server add floating ip INSTANCE_NAME_OR_ID FLOATING_IP_ADDRESS 

Command to disassociate a floating IP address from an instance. 

$ openstack server remove floating ip INSTANCE_NAME_OR_ID FLOATING_IP_ADDRESS 

Removing floating IP address from a project. 

$ openstack floating ip delete FLOATING_IP_ADDRESS 

One of the most frequently posed OpenStack scenario based interview questions, be ready for this conceptual question.

To manage projects, users, and roles, we must be administrators. They can assign users to specific projects, and a user can be a member of several projects. Roles define what a user can do, and they can assign roles to user-project pairs.

For defining the actions for OpenStack service roles, the admin needs to make changes in the  /etc/PROJECT/policy.json files. While setting up the cloud, the operator defines at least one project, role, and user. While the admin can add, update, and delete projects and users, assign users to one or more projects, and change or remove the assignment. To delete a user account, remove it from its primary project.

A project in OpenStack is referred to as the group of zero or more users. In compute, each project has a VM. while in containers, each project owns a container. We can associate users to more than one projects. Each project-user pair has a specific role associated to it. 

To work around  projects, we can use openstack commands. 

Command to list projects to get their details. 

$ openstack project list 

Command to create a new project. 

$ openstack project create --description 'my new project' new-project \ 
  --domain default 

Command to disable a project temporarily. 

$ openstack project set PROJECT_ID --disable 

Command to enable a disabled project. 

$ openstack project set PROJECT_ID --enable 

Command to update the name of the project. 

$ openstack project set PROJECT_ID --name project-new 

Command to delete a project. 

$ openstack project delete PROJECT_ID 

Users are the members that we can associate with one or more projects. Below are the commands. 

Command to list the users. 

$ openstack user list 

Command to create new user. We need to specify the username, password, and email address as without it the user cannot log into the dashboard. 

$ openstack user create --project new-project --password PASSWORD new-user 

To disable the user’s account temporarily. 

$ openstack user set USER_NAME --disable 

Command to enable the disabled account. 

$ openstack user set USER_NAME --enable 

Command to change the name and description of the user. 

$ openstack user set USER_NAME --name user-new --email [email protected] 

User has been updated. 

Command to delete the user. 

$ openstack user delete USER_NAME 

Roles are assigned to a project-user pair. Roles define the actions that can be performed by the user for that specific project. 

Below are the commands. 

Command to list all the available roles. 

$ openstack role list 

Command to create a new role. 

$ openstack role create new-role 

Command to list users and user ID to assign the role. 

$ openstack user list 

List all the roles to check the role ID to assign. 

$ openstack role list 

List all the projects and check project ID to assign to the role. 

$ openstack project list 

Assigning a role to project-user pair. 

$ openstack role add --user USER_NAME --project TENANT_ID ROLE_NAME 

Command to verify the assignment of role. 

$ openstack role assignment list --user USER_NAME \ 
  --project PROJECT_ID --names 

Command to check the role details. 

$ openstack role show ROLE_NAME 

Command to remove the role. 

$ openstack role remove --user USER_NAME --project TENANT_ID ROLE_NAME

A staple in OpenStack interview questions for experienced, be prepared to answer this one using your hands-on experience.

A RabbitMQ broker is the logical grouping of many nodes where each node run the RabbitMQ application and share users, virtual hosts, queues, exchanges, bindings, and runtime parameters. A group of nodes is referred to as cluster. For seamless operation of RabbitMQ, all the data is replicated across all nodes within the OpenStack ansible for improved and high availability. The nodes interact with each other using domain names.  

For creating a RabbitMQ cluster, there are two ways. 

• Manually using rabbitmqctl. 
• Specifying cluster nodes in a config, with rabbitmq-autocluster, or rabbitmq-clusterer plugins. 

In every IT or other companies, they backup their data for disaster recovery purposes. If we have deployed the OpenStack cloud using the OpenStack Ansible then we can take backup of the /etc/openstack_deploy/ directory that stores the ive inventory, host structure, network information, passwords, and options that are applied to the configuration files for each service. Create backup at the remote location.

To troubleshoot the issue, we can perform the following checks. 

• Check the physical connectivity of the hosts to the network. 
• Check the available interface bonding. 
• Check for various configurations, such as VLAN configs and trunking to edge and uplink ports on physical switches. 
• Check that the hosts will be under the same IP subnet and having proper routing. 
• Ensure that there is no iptables applied to the hosts that can deny the traffic.

To check the status of every services in OpenStack, we need to access every controller node and run the service <service_name> status command.

All the database operation are handled by the glance-registry that will manage the storage of the image index and properties. The glance-api is responsible for handling the API interactions and the image store.

If we face any issue regarding the image service then we must go through the /var/log/glance-api.log and /var/log/glance-registry.log under the glance api controller.

For better troubleshooting, perform the following actions.

• Download the image to check if it is readable front he store.
• Upload the image to check if the image is registering and writing properly to the image store.
• Run the openstack image list to check if the API and registry is working fine.

SQL database is commonly used by the OpenStack services for storing the information. But other databases are also supported by OpenStack, such as PostgreSQL. The database runs on the controller node. 

Below are commandsf or installing and configuring and installing components for database. 

a. Install the packages. 

# yum install mariadb mariadb-server python2-PyMySQL  

b. Create and edit the file /etc/my.cnf.d/openstack.cnf file, and add the following [mysql] section. 

[mysqld] 
bind-address = 10.0.0.11
default-storage-engine = innodb 
innodb_file_per_table 
max_connections = 4096 
collation-server = utf8_general_ci 
character-set-server = utf8 

c. Start the database service and make sure that the database will also start when the system boots. Below is the command. 

# systemctl enable mariadb.service 
# systemctl start mariadb.service 

d. Run the mysql_secure_installation script for securing the database service.  

# mysql_secure_installation 

Some major OpenStack concerns are- 

• Data residency- it is the concern regarding who owns the cloud data and if we can trust the cloud operator with our data. 
• Data disposal- it concerns if the operator sanitizes the cloud system media before disposing and releasing for reuse. 
• Data not removed securely- we can eliminate this challenge by configuring system settings for auto vacuuming the unwanted data to free space.

Compliance may be required for various OpenStack activites, such as regulatory and legal requirements, customer need, privacy considerations, and security best practices. So, to adhere to regulation and standards, business and customer must have compliance function in place. It describes the status of the company regarding audits, assessments, and certifications that are necessary to strengthen the security of the company.

The shared file service in OpenStack, code named manila, offers services that allows us to manage the shared file system in a multi-tenant cloud. This service allows us to create a shared file system and manage its properties, such as visibility, accessibility and usage quotas. It allows us to work with various storage providers following shared file system protocols: NFS, CIFS, GlusterFS, and HDFS.

To ensure the smooth working of the OpenStack components, config files has necessary information. If an user without authorized access made any changes accidentally then it can impact the availability, resulting in denial of services to end users. So make sure that the user ownership of such critical configuration files must be set to root and group ownership must be set to manila. Not only this, the containing directory should have the same ownership.

To ensure the proper access, run the following command and check the config. 

$ stat -L -c "%U %G" /etc/manila/manila.conf | egrep "root manila" 
$ stat -L -c "%U %G" /etc/manila/api-paste.ini | egrep "root manila" 
$ stat -L -c "%U %G" /etc/manila/policy.json | egrep "root manila" 
$ stat -L -c "%U %G" /etc/manila/rootwrap.conf | egrep "root manila" 
$ stat -L -c "%U %G" /etc/manila | egrep "root manila" 

The data processing service of OpenStack, code named sahara, offers a platform that let us provision and manage the instance clusters using frameworks like Hadoop and Spark. A user can upload and execute the applications to access data from object storage or external providers using the dashboard or the REST API. the controller of data processing services use the orchestration service (heat) for creating instance clusters that can be scaled up and down as requested.

A staple in OpenStack interview questions for experienced, be prepared to answer this one using your hands-on experience.

Once you run instance in a virtualized environment, open new security controls that might be available while deploying onto bare metal. We can implement various technologies to the virtualization stack for improving the information assurance for cloud tenants. 

The OpenStack users with strong security requirements must deploy these technologies. It might be possible that all technologies are not available for every scenario. Some technologies inspect instance data like run state that are not required by the users of the system.

Different security services for instances are- 

• Entropy to instances. 
• Trusted images  
• Migration of instance 
• Update and patches 
• Monitoring, alerting, and reporting. 
• Firewalls and other security controls. 

We can use different methods to do that- 

• We can run the ping command to find where the issue is exactly within the network. In case of an instance, ping an external host, such as google.com. If it works, then there is no network issue. 
• If that does not work, ping the IP address of the compute node where the instance is hosted. If that works, then there the issues exists somewhere in between the compute node and compute node’s gateway. 
• If it does not work, then the issue lies between the instance and the compute node. Then we must check the bridge connecting the compute node’s main NIC with the vnet NIC of the instance. 
• If everything works fine, then launch another instance and see if both instance can ping each other. If they cannot, then check firewall settings.

We can spin a new VM using below command. 

# openstack server create –flavor {flavor-name} –image {Image-Name-Or-Image-ID}  –nic net-id={Network-ID} –security-group {Security_Group_ID} –key-name {Keypair-Name} <VM_Name> 

It uses the puppet as the config management tool that will allow us to automate the installation of OpenStack. In the background, puppet pushes the config to the nodes.

The sanitization process eliminates the information from the media that we cannot retrieve or reconstruct. Sanitization techniques include clearing, purging, cryptographic erase, and destruction for ensuring that information is not disclosed to unauthorized users when such media is reused or released for disposal.

The bare-metal driver for OpenStack Compute helps manage the provision of physical hardware using standard cloud APIs and orchestration tools. We can use it for single-project clouds, such as the self-deployment of OpenStack.

Using the bare-metal driver, we must create a network interface and add it to a bare-metal node for launching an instance from a bare-metal image. We can run commands to list and remove bare-metal nodes and network interfaces linked to those bare metals.

Commands to manage bare-metal nodes. 

Adding a network interface to a bare-metal node. 

Baremetal-interface-add 

Lists network interfaces linked to a bare-metal node. 

Baremetal-interface-list 

Remove a network interface. 

Baremetal-interface-remove 

Create a bare-metal node. 

Baremetal-node-create 

Remove a bare-metal node and any linked interfaces. 

Baremetal-node-delete 

Lists available bare-metal nodes. 

Baremetal-node-list 

Show information about bare-metal node 

Baremetal-node-show 

The volume is a block storage device we can detach, just like a USB. we can attach a volume to a single instance only. We can use the openstack client command for creating and managing volumes. 

Migrating a volume- 

For migrating a volume with its data from one location to another, we must have admin rights. Volume migration can be done if they are detached with no snapshots. There are some scenarios when we want to migrate the volume, such as bringing down the physical storage device for maintenance without impacting the functioning, modifying the volume properties, and freeing up space in the back end. 

For migrating a volume, we can use the command- 

$ openstack volume migrate [-h] --host <host> [--force-host-copy] 
                                  [--lock-volume | --unlock-volume] 
                                  <volume> 

In the above example- 

1. force-host-copy forces the host-based migration mechanism and bypasses any driver optimizations. 
2. lock-volume | --unlock-volume applicable to the available volume for determining if other commands cause the termination of volume migration.  
3. lock-volume locks the volume state so the migration will not get aborted in between. 

Using the networking capability, we can easily create and manage the network objects, such as networks, subnets, ports, and others, that can be used by other OpenStack services. To accommodate different networking equipment and software, we can use plugins. This will improve the flexibility of OpenStack architecture and deployments.

The code-named neutron, a networking service, allows us to define and address network connectivity within the cloud. Operators can leverage different networking technologies to power their cloud networking using such services. It also offers an API that lets us to configure and manage different network services ranging from L3 forwarding and Network Address Translation (NAT) to load balancing, perimeter firewalls, and virtual private networks.

OpenStack networking has three components. 

• API Server- it offers support for Layer 2 networking and IP Address Management (IPAM), as well as an extension for a Layer 3 router construct that enables routing between Layer 2 networks and gateways to external networks. Its wide range of APIs enables interoperability with various commercial and open-source network technologies. 
• OpenStack Networking plug-ins and agents- it has various plugins and agents for Plugs and unplugs ports, creates networks or subnets, and provides IP addresses, and more. But make sure to use one plugin at a time. 
• Messaging queue accepts and routes RPC requests between agents to complete API operations. 

This, along with other interview questions on OpenStack, is a regular feature in OpenStack interviews, be ready to tackle it with an approach mentioned below.

In OpenStack, tokens are used for authenticating and authorizing the user’s interaction with OpenStack APIs. tokens are of different types specifying various levels and scopes of authorization. The general purpose of the token is to relay information about your role. A user can have multiple role assignments, projects, domains, and others, known as authorization scopes, where the token has a single scope of operation.  

Different scopes of tokens are- 

• Unscoped tokens- they do not have a service catalogue, roles, or authorization scope. They just prove the user’s identity to keystone. There is no need to specify an authorization scope in your authentication request. 
• Project-scoped tokens- such tokens authorize the user to operate in a specific cloud tenancy and are helpful for things like spinning up compute resources or carving off block storage. To consume resources in deployment, users must have role assignments on projects. 
• Domain-scoped tokens- such tokens authorize the user to operate on the contents of a domain or the domain itself. If the user has access to the domain, they can manage things within the domain, such as creating new users and projects. 
• System-scoped tokens- some APIs affect the entire deployment system, such as modifying endpoints and service management. Such tasks are reserved for operators and require system-scoped tokens, representing the role assignments a user has to operate on the deployment, such as system admins and cloud admins. 

Account reaper removes the data from the deleted accounts in the background. A reseller issue a delete request on the account’s storage URL that will mark the account for deletion. It will change the status column of the account_stat table in the account database to DELETED, specifying the account will have to be deleted later. There is no retention time and undelete option. The reseller will make those decisions if they want to delete the account. 

To protect the account from mistaken delete requests, we can set a delay_reaping value in the [account-reaper] section of the account-server.conf to delay the actual deletion of data. Well, there is no option of undelete currently. We have to update the account database replicas directly, setting the status column to an empty string and updating the put_timestamp to be greater than the delete_timestamp.

A must-know for anyone looking to prepare for OpenStack advanced interview questions, this is one of the frequent questions asked of content managers.

The image service of OpenStack is called Glance, which allows us to discover, register and retrieve virtual images. Using its REST API, we can query the VM image metadata to retrieve the actual image. We can store such virtual machine images in different locations, varying from simple file systems to object-storage systems like OpenStack Object Storage.

This service is central to Infrastructure-as-a-Service (IaaS), accepting API requests for disk or server images and metadata definitions from end users. Not only this, but we can also store the disk or server images on various repository types, including OpenStack Object Storage.

OpenStack image services have different components-

• glance-api- that will accept the API calls for discovering, retrieving, and storing the images.
• glance-registry will allow us to store, process, and retrieve the metadata about images.
• Database- stores the image metadata. We can use databases like- MySQL or SQLite.
• Storage repository for image files- it supports various storage repos, such as file systems, Object Storage, RADOS block devices, VMware datastore, and HTTP.
• Metadata definition service- includes common API for vendors, admins, services, and users to define their own custom metadata meaningfully.