How can I prepare my instances for this migration?

• Shutdown your instance, and start it up again prior to the migration to see if the instance starts up gracefully without interruption or error messages (a reboot won’t be sufficient).
• Make sure that cloud(base)-init is disabled before you start the migration.
• Perform a file-system check of all file-systems prior to migration.
• Please make sure your system has no pending updates, so that there won’t be any interruption of installing patches during the migration (as this might be prematurely interrupted).

TL;DR, can you give me a short summary?

• Your instance will be migrated to a boot-from-volume instance.
• If you have a floating IP we will migrate it.
• We have created a new project for you on the new platform.
• If you use custom images or a snapshot to boot your instance from, we will migrate those glance images as well.
• If you have connected your instance to an internal network, we will extend that network into the new region.
• If you have a router for internet access on your network the public IP will change.
• If you have volumes attached to your instance, we will copy them to the new platform.
• If you have any snapshots on those volumes, those will be lost.
• If you do not disable cloud-init your SSH host key will change when migrating towards the new region.
• On Windows guests the admin password will be changed if cloudbase-init was not disabled.
• Windows instances might require reactivation of the license as the hardware of the VM is replaced
• We will use ICMP ping to determine if your instance is up and running, please prepare your instance accordingly.
• We will check commonly used ports (like port 22, 80, 443, etc).
• If you have a HA setup, there are some caveats
• Load balancers will be migrated once all instances have been migrated and will have some minutes of downtime.

Not all my instances have the migration metadata, what’s the reason?

We’re finalizing the last steps to enable the migration of all instances to the new region

• HA / vrrp setups will be migrated at a later stage.
• internal networks with custom routers will be migrated at a later stage.

Will our SSH keys be migrated?

Yes they will, your SSH keys will be copied to the new region but only for the instance (it will not be migrated to your user).

My instance is not running as expected after migration, can I perform a roll-back?

Yes, once the migration has been successfully completed, you can perform a rollback by setting the metadata key rollback-now on your instance within the legacy Horizon dashboard.

If you do perform a rollback, please let us know the reason. We’re keen to understand what went wrong so we can improve the process and avoid similar situations in the future.

Note: Any changes made on the new instance will not be carried back and should be considered lost. A rollback is only available within the first 5 days after the migration.

If I already have instances named equally in the new region, will they be overwritten?

No, we will not overwrite anything in the new region.

What will be the expected downtime during the migration?

• We’ve seen instances with downtime of less than a minute, but for safety reasons you should consider up to 15 minutes (The migration depends on the amount of time to boot up the instance and start all services)
• Our tests indicate that downtime could be as little as 40 seconds during minimal load on your instance. A graceful shutdown will be initiated using the OpenStack APIs. A new instance is then spawned and created in the new region, with a copy of the disk. The process will monitor the startup time and if it exceeds 10 minutes, we will automatically initiate a rollback.
• If the instance is attached to an internal network its connection will be lost for up to 10 minutes. This connection is needed to synchronize the internal network between the legacy region and the new region.
• When the migration is finished and your instance is booted up successfully within the new region please include an additional 10 minutes for the internal network to become ready.
• If the internal network doesn’t respond within 20 minutes after the migration has been finished please contact support and initiate a rollback of your instance.
• Load balancers will have up to 5 minutes of downtime, as the load balancer needs to be recreated in the new region.

Will migration of an instance affect my other operational instances?

Unless you have created a dependency on that instance, your other instances will not be affected.

What will happen with Load Balancers during migration?

All load balancers will be migrated once all instances have been migrated. During the migration of the load balancer there will be some minutes of downtime, as the load balancer needs to be recreated in the new region. The migration of the load balancer will start automatically once all instances have been migrated and will be on the same day as the last instance migration of your project. Load balancers will be converted to Octava load balancers during migration and will have the flavor ‘Small’ assigned. We expect the performance to be similar to or better than the current load balancer performance.

How can I initiate the migration myself?

When your instance is flagged for migration, additional metadata is added to your instance named o2o-scheduled-YYYY-MM-DDTHH:MM:SS. You can schedule the migration by changing the date / time (times are in the europe/amsterdam timezone!) to your preference. A date / time in the past will start a migration as soon as a migration slot is available (normally within a minute). Alternatively you can set metadata o2o-migrate-now on the metadata key migrate_flag.

To set or change the metadata of your instance, go to the Horizon interface Project > Compute > Instances. Click the more options triangle next to the instance and choose Update Metadata.

Open Provider platform options > Migration and Click + on Scheduling options. Update the date/timestamp to your liking and click Save

What will happen when I don’t start or schedule the migration myself?

Your instance will be migrated during office hours (9:00-17:00 Europe/Amsterdam timezone) on the date we communicated by e-mail, and set in the metadata.

Can I migrate outside office hours?

Yes, by scheduling the migration using the provided metadata (see How can I initiate the migration myself)

What will happen if the migration fails?

If the migration fails, your instance will be started again on the current OpenStack platform. We will investigate the cause of the failure and inform you about a new migration date.

How can I see if the migration was successful?

If the migration was successful, the instance will reach a ‘SHUTOFF’ state. This can be verified via either the OpenStack Legacy API or in the Horizon dashboard. The instance will be locked. The progress of the migration can be monitored through metadata key _export_progress

Where can I manage my migrated instance?

Your migrated instance can be managed through the new Horizon dashboard, accessible through the Control Panel.

My instance is connected through an internal network to my other instances, does this still work after migration?

Yes, your internal network will be expanded into the new region.

I don’t have any projects in new region, do I have to create a new one?

No, if you don’t have any projects created in our new region, we have already created a project for your convenience.

I have multiple projects in the new region, can you migrate my current resources to my existing project?

Yes, please contact support with the project mapping(s) you’d want us to use, so that we can configure it accordingly.

What happens with snapshots attached to my volumes?

Those will be lost, as we are unable to duplicate snapshots from the legacy to the new platform. When you want to save a snapshot of your volume, create a new volume with the snapshot as source. This can be done in Horizon: Volumes > New Volume > Clone an existing volume, here you select the volume where you want to clone the snapshot from and you can select the snapshot itself.

Are glance images (snapshots/custom images) also imported into the new region?

Yes, but only if the image is still available (not deleted).

Do I keep my current IP addresses?

Yes, all of your public (floating) and internal IP addresses will be migrated.

I would like to migrate all my resources ASAP, is that possible?

We are continuously working on resolving impediments that might block some migrations. You can contact support to validate if your instances can already be migrated.

Will I still be billed for my migrated resources in the old platform?

When the first migration is started we will bill your current resources until we migrated all of your project’s resources. When all resources in your project are migrated, we will start billing your resources from ams2 and stop billing from the legacy platform.

What will happen with my Windows license?

When your virtual machine is migrated, a new virtual machine is created on our destination platform. Windows will detect this new hardware automatically and configure the operating system appropriately. After the migration, it is possible your virtual machine needs to re-activate its license. To verify if your license is properly activated, please go to Windows System settings -> Activation -> Troubleshoot or Activate to verify activation or re-activate your license.

Will my SSH host key change if cloud-init is enabled?

Yes, the migration from the legacy platform to the new region will result in a new UUID and name for your instance. Due to the way cloud-init works by default, this will result in cloud-init to re-initialise your system as if it was newly spawned. This will also cause your SSH host key to be renewed. If you don’t want this, please disable cloud-init before the migration to the new region starts.

What flavor will my new instance get?

We have carefully selected destination flavors that match the specifications and price of your OpenStack Legacy flavor as closely as possible. See the following table how flavors are matched. If the flavor is not sufficient, you can resize your instance after migration to another flavor.

Requirements

Before adding Let’s Encrypt certificates to your load balancer, we first need to create a load balancer with HTTPS_OFFLOADING, like described in Create a ssl loadbalancer

We need a linux machine with the OpenStack command line tools Using the OpenStack CLI article.

For this guide we assume you have already created a DNS Zone, if you haven’t done this yet please read the following article: Create a DNS Zone

We will be storing the Let’s Encrypt SSL certificates in OpenStack. We are using Keymanager to do so. To read more about Keymanaer, refer to the article Introduction to Keymanager.

Preparing the linux server

For the script to work, we need a couple applications and scripts.

Step 1
Install tools with your prefered linux package manager.

# For Debian-based systems
sudo apt install python3 python3-pip certbot

# For Redhat-based systems
sudo yum install python3 python3-pip certbot

Step 2
Install the python packages with pip.

sudo pip install openstacksdk cryptography certbot git+https://opendev.org/x/certbot-dns-openstack.git

Step 3
Download the script from cloudtutorials. We recommend you reading the script before executing, this is always good practice.

sudo wget -O /root/renew_certificates.py https://raw.githubusercontent.com/CloudTutorials/OpenStack-Docs/refs/heads/main/assets/scripts/2025-01-30-create-certbot-ssl-loadbalancer/renew_certificates.py

Step 4 Gather the loadbalancer listener id(s) from the OpenStack project to verify which listeners you want to add the certificates to.

openstack --os-cloud ams2 loadbalancer listener list

Running the script and schedule it

Step 1 Run the script once to evaluate check if everything works

sudo python3 /root/renew_certificates.py --os-cloud <cloud> --domain *.test.example.com --renew \
 --create-barbican-secret --octavia-listener <UUID>

We expect the script to request a certificate through certbot. Certbot on its turn will use a plugin to create a DNS record in OpenStack Designate to validate the domain. The option –create-barbican-secret will gather the certificates from certbot’s live directories and upload the certificate to OpenStack Barbican. The option –octavia-listener will configure all listeners supplied with the uploaded certificate.

Step 2 When the script is running succesfully, we can create a cron to schedule the creation.

sudo cat > /etc/cron.d/renew_certs << EOF
# /etc/cron.d/renew_certs: crontab entries for the automated OpenStack
# Certificate renewal
#
# Upstream certbot recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(43200))' && python3 /root/renew_certificates.py --os-cloud <cloud> --domain *.test.example.com --renew  --create-barbican-secret --octavia-listener <UUID> >> /var/log/renew_cert.log 2>&1

EOF

Note: This script enables you to create backups to your ObjectStore project using the Restic backup tool instead of Duplicity. Please be aware that the CloudVPS-Boss script is not officially supported.

Notice

In this tutorial, we will install CloudVPS-Boss version 3.0.0, a newer version of the script that is compatible with the latest OpenStack Keystone V3.

Important!

When you upgrade to the new V3 implementation using the Restic-backup method, your backups will restart. This means:

• Your old backups will still exist but cannot be restored using Restic.
• We recommend creating a new backup immediately after installing the new version to ensure you have a backup that can be restored with Restic.
• Old backups created with a previous version of CloudVPS-Boss cannot be restored and will not be removed automatically. To avoid paying for stale backups, manually remove them after 1–2 weeks.

Installing CloudVPS-Boss v3.0.0

Follow these steps to install CloudVPS-Boss:

1. Clone the repository and run the installer:

    git clone https://github.com/CloudVPS/CloudVPS-Boss.git --branch support-v3-and-use-restic
    cd CloudVPS-Boss
    bash install.sh
   

2. Source the credentials:
   These credentials are required to create the Restic repository in your ObjectStore project.
   (You will not receive any feedback from the CLI client; this is expected):

   source /etc/cloudvps-boss-v3/v3-auth.conf
   

3. Create a Restic repository:
   Use the following command to initialize the repository. Choose a secure password and store it safely.
   (You will need this password to restore backups or in the next step):

   restic init -r swift:cloudvps-boss-v3:/
   

4. Store the restic password:
   Save the password used for the Restic repository in the configuration file:

   nano /etc/cloudvps-boss-v3/restic-password.conf
   

   Save the file by pressing CTRL + X and then Y.

5. Start the backup:
   Once configured, you can start the backup process. By default, backups run daily. For more configuration options, refer to the optional steps:

   cloudvps-boss
   

Credits

Special thanks to Cream Commerce B.V. for implementing Restic backup in their own fork, we have used this implementation in the v3.0.0 version of the CloudVPS-Boss script.
You can find their CloudVPS-Boss fork here.

SSL certificate

Before creating the load balancer, we need to store our SSL certificaten in OpenStack. We are using Keymanager to do so. To read more about Keymanaer, refer to the article Introduction to Keymanager. Currently it is not possible to upload the certificate through Horizon so we will be using the CLI. There are multiple options to upload the certificate to barbican. Our advise would be to use the container approach (Uploading the SSL certificate to keymanager in a container) . The easier option is the combined, although slightly less secure, approach which has the benefit of being selectable in horizon after storing (Uploading the SSL certificate to keymanager as single file) .

Uploading the SSL certificate to keymanager in a container

The prefered way of storing a certificate in barbican for Octavia is to use seperate secrets to store the server certificate, private key, intermediate certificates and the passhprase. After storing the secrets, we can combine them using a certificate container. The downside of this approach however is secret containers are not yet supported in Horizon to use for Octavia.

Prerequisites

• All certificates files are stored on the OpenStack CLI server. We need the following files:
  • certificate.pem (the certificate file for the load balancer)
  • private.key (the private key for the load balancer, password protected)
  • intermediate.pem (intermediate certificates in proper order of your SSL supplier)
• Passphrase to decrypt the private key
• openssl tooling installed on the OpenStack CLI server

Step 1
First make sure you have setup the OpenStack CLI and that you are able to execute commands using the openstack command. For more information please refer to the Using the OpenStack CLI article.

Step 2
Store the certificate in barbican

# Store variables
certificate=certificate.pem
domain="$(openssl x509 -noout -subject -in "$certificate"|cut -d= -f 3| tr -d ' ')"
name="${domain}_certificate"

# Store the secret in keymanager
openstack secret store --name="${name}" -t 'application/octet-stream' -e 'base64' \
--payload="$(base64 < "$certificate")" --expiration $(date --date="$(openssl x509 -enddate -noout \
-in "$certificate"|cut -d= -f 2)" --iso-8601)

Make sure to save the returned secret_href as variable, we need that later

certificate_url="https://keymanager.domain.tld:/v1/secrets/uuid"

Step 3
Store the passhprase for the private key in barbican.

# Store variables
name="${domain}_passphrase"

# Store the secret in keymanager
openstack secret store --secret-type passphrase --name ${name} \
--payload $(read -sp "Password: ";echo ${REPLY})

Answer the password question and press enter

Make sure to save the returned secret_href as variable, we need that later

passphrase_url="https://keymanager.domain.tld:/v1/secrets/uuid"

Step 4
Store the private key in barbican

# Store variables
name="${domain}_private_key"
certificate=private.key

# Store the secret in keymanager
openstack secret store --name="${name}" -t 'application/octet-stream' -e 'base64' \
--payload="$(base64 < "$certificate")"

Make sure to save the returned secret_href as variable, we need that later

private_key_url="https://keymanager.domain.tld:/v1/secrets/uuid"

Step 5
Store all intermediate certificates in barbican

# Store variables
certificate=intermediate.pem
name="${domain}_intermediates"

# Store the secret in keymanager
openstack secret store --name="${name}" -t 'application/octet-stream' -e 'base64' \
--payload="$(base64 < "$certificate")" --expiration $(date --date="$(openssl x509 -enddate -noout \
-in "$certificate"|cut -d= -f 2)" --iso-8601)

Make sure to save the returned secret_href as variable, we need that later

intermediates_url="https://keymanager.domain.tld:/v1/secrets/uuid"

Step 6
Create a certificate container containing the certificate, all intermediates the passphrase and the private key.

# Store variables
name="${domain}_container"

# Store the secret in keymanager
openstack secret container create --name "${name}" --type certificate \
-s "certificate=${certificate_url}" -s "intermediates=${intermediates_url}" \
-s "private_key=${private_key_url}" -s "private_key_passphrase=${passphrase_url}"

Make sure to save the returned secret_href as variable, we need that later

octavia_certificate_url="https://keymanager.domain.tld:/v1/containers/uuid"

Uploading the SSL certificate to keymanager as single file

The alternative way to store a certificate to use with an Octavia loadbalancer is to create a single pkcs12 file with all certificates without password protection. The downside of this approach is we need to temporarily store the unencrypted private key for the load balancer on the OpenStack CLI server. The benefit is we can select the certificate in Horizon.

Prerequisites

• The server certificate, intermediate certificates and private key are stored in the proper order in a single file on the OpenStack CLI server named ‘certificate.pem’
• OpenSSL tooling installed on the OpenStack CLI server

Step 1
First make sure you have setup the OpenStack CLI and that you are able to execute commands using the openstack command. For more information please refer to the Using the OpenStack CLI article.

Step 2
Convert the certificates to a pkcs12 certificate (skip this if you already have a pkcs12 encoded file with all required certificates):

openssl pkcs12 -export -inkey private.key -in certificate.pem -certfile intermediate.pem \
-passout pass: -out complete.p12

Step 3
Store the certificate in barbican

certificate=complete.p12
domain="$(openssl pkcs12 -in "$certificate" -nokeys -passin pass: | openssl x509 -noout \
-subject | cut -d= -f 3| tr -d ' ')"
name="${domain}_complete_certificate"
expiration_date="$(date --date="$(openssl pkcs12 -in "$certificate" -nokeys -passin pass: | \
openssl x509 -enddate -noout | cut -d= -f 2)" --iso-8601)"
openstack secret store --name="${name}" -t 'application/octet-stream' -e 'base64' \
--payload="$(base64 < "$certificate")" --expiration "${expiration_date}"

Make sure to save the returned secret_href as variable, we need that later

octavia_certificate_url="https://keymanager.domain.tld:/v1/secrets/uuid"

Creating the loadbalancer

Creating the loadbalancer using the OpenStack Dashboard

Note: When you decided to store your certificate through a container, it is not easy to create the load balancer through the OpenStack Dashboard. Follow the step (Creating the loadbalancer using the OpenStack CLI)

Now we can create the loadbalancer. We will create a loadbalancer with a listener, a pool and a healthmonitor.

Step 1
Navigate to the Network tab and select Load Balancers.
Step 2
Initiate the process by clicking on the Create Load Balancer button.
Step 3
Enter details in the following fields:

• Name: webserver-loadbalancer
• IP Address: Leave empty for now
• Description: Loadbalancer for our webservers
• Availability Zone: Leave empty or choose an availability zone to your liking.
• Flavor: Choose a flavor to your liking for this tutorial we use the Medium flavor.
• Subnet: webserver-subnet

Step 4
Proceed to the Listener Details tab by clicking on Next.
Step 5
Complete the following fields:

• Name: webserver-listener-https
• Description: HTTPS Listener for our webservers
• Protocol: TERMINATED HTTPS
• Protocol Port: 443
• Admin State Up: Yes Leave all others options as they are for now.

Step 6
Proceed to the Pool Details tab by clicking on Next.
Step 7
Enter information in the following fields:

• Create Pool: Yes
• Name: webserver-pool-http
• Description: HTTP Pool for our webservers
• Algorithm: Least connections
• Session Persistence: Leave None
• TLS Enabled No
• Admin State Up: Yes

  Note: Find out more about the Algorithm and Session Persistence fields in the article Introduction into loadbalancer

Step 8
Proceed to the Pool Members tab by clicking on Next.
Step 9
Identify the instances you wish to include and click on Add for each.
Step 10
Enter the designated port for the host (80) and set the weight (1). Repeat this step for all webserver hosts you’re adding.

Note: In this tutorial, the connection from the load balancer to the webservers is not encrypted. The SSL encryption is hereby offloaded to the load balancer. If it is required to have an encrypted connection to the webservers, the webservers itself need an ssl certificate as well. This is outside of the scope for this tutorial.

Step 11
Navigate to the Health Monitor tab by clicking on Next.
Step 12
Complete the following fields:

• Name: webserver-healthmonitor-http
• Type: HTTP
• Max Retries Down: 3
• Delay: 5
• Max Retries: 3
• Timeout: 5
• HTTP Method: GET
• Excepted Codes: 200
• URL Path: /
• Admin State Up: Yes

Step 13
Proceed to the SSL Certificates tab by clicking on Next.
Step 14
Add the appropriate certificate from the available certificates. It will be named DomainName_complete_certificate

Note: It is possible to add multiple certificates. The load balancer will use SNI to select the appropriate certificate

Step 15
Initiate the creation of your load balancer by clicking on Create Load Balancer.
Step 16
Locate the load balancer you’ve just set up and click the small arrow beside it. From the dropdown menu, select Associate Floating IP.
Step 17
Select an available floating IP or choose the net-float pool, then confirm your choice by clicking on Associate.

Step 18
Finalize the deployment and start testing (Testing the loadbalancer)

Creating the loadbalancer using the OpenStack CLI

Now we can create the loadbalancer. We will create a loadbalancer with a listener, a pool and a healthmonitor. It is only possible to create the loadbalancer through

Prerequisites
We should already have a bash variable set with the certificate location

octavia_certificate_url="https://keymanager.domain.tld:/v1/containers/uuid"

Step 1
Gather the subnet uuid for the internal network:

openstack subnet list
vip_subnet_uuid=uuid

Step 2
Create the loadbalancer

openstack loadbalancer create --name "webserver-loadbalancer" \
--description "Loadbalancer for our webservers" --flavor Medium --vip-subnet-id "${vip_subnet_uuid}"

Make sure to save the returned id as variable, we need that later

lb_uuid=uuid

Step 3
Create the listener

openstack loadbalancer listener create "${lb_uuid}" --name "webserver-listener-https" \
--description "HTTPS Listener for our webservers" --protocol TERMINATED_HTTPS --protocol-port 443 \
--default-tls-container-ref "${octavia_certificate_url}" 

Make sure to save the returned id as variable, we need that later

listener_uuid=uuid

Step 4
Create the pool

openstack loadbalancer pool create --name "webserver-pool-http" \
--description "HTTP Pool for our webservers" --protocol HTTP --lb-algorithm LEAST_CONNECTIONS \
--listener "${listener_uuid}"

Make sure to save the returned id as variable, we need that later

pool_uuid=uuid

Step 5
Create the health monitor

openstack loadbalancer healthmonitor create "${pool_uuid}" --name "webserver-healthmonitor-http" \
--type HTTP --delay 5 --timeout 5 --max-retries 3

Step 6
Create the members

repeat the following command for all webservers you want to add to the pool

openstack loadbalancer member create "${pool_uuid}" --protocol-port 80 --name "<server_name>" \
--address "<server_address>"

Step 7
Finalize the deployment and start testing (Testing the loadbalancer)

Testing the loadbalancer.

Now that the load balancer is created, we can test it

Step 1
Create an A record in DNS for the domain to point to the floating IP address managing DNS records

Step 2
Await the update of the load balancer’s Operating Status to ONLINE and the DNS to propagate. Once this status is achieved, navigate to https://DomainName in your web browser to witness your load balancer functioning.

Step 3
Verify the SSL of the load balancer to have your URL checked with the
SSL Labs SSL Server Test

If you want to customize your Loadbalancer even further we highly recommend you to read the OpenStack Octavia Loadbalancer documentation

Introduction

To protect your data in a public cloud encryption becomes more important every day. One could think of encrypting traffic between clients and servers with https, encrypting volumes or just encrypting valuable key/value pairs. OpenStack Barbican provides a REST API designed for the secure storage, provisioning and management of secrets such as passwords, encryption keys and X.509 Certificates.

Use cases

Although the OpenStack key manager can be used to store secrets and raw binary data, it is most used to store Symmetric Keys, Asymmetric Keys and Certificates for other OpenStack services to use.

HTTPS Load balancer

With OpenStack Octavia, it is possible to create a high available load balancer. To allow the load balancer to encrypt http traffic with certificates, both private keys, intermediate and server certificates can be stored in barbican to be accessed by Octavia. On the creation, restart or update of an Octavia load balancer with terminated https, Octavia will request the certificates from Barbican.

Encrypted volumes

We can use Barbican to manage Block storage (cinder) encryption keys. LUKS is used to encrypt the data on the disks attached to your instances. The keys for the disk encryption are automatically generated by cinder and securely stored in barbican. When attaching an encrypted volume to an instance, nova retrieves the key from barbican and provides it to the compute proces on the compute node. Create a volume

Inner workings

Just like most OpenStack projects, barbican can be used with an API. The barbican API can be used to store and retreive secrets. When providing barbican with a secret for example a private key, barbican will encrypt the keys before storing them in a database. The encryption for the secrets is configurable through plugins and most cloud providers use Hardware Security Modules (or HSMs) to securely protects your cryptographic keys, but at the same time makes them easily accessible. When retrieved, barbican will decrypt the secrets and provide them to you or the service requesting the secrets. Barbican makes use of OpenStack Keystone to validate if a user is allowed to store and retrieve secrets.

Conclusion

A keymanager can be an essential part to protect your cloud infrastructure. The OpenStack barbican keymanager service provides secure storage, provisioning and management of secrets, such as passwords, encryption keys, etc.

The OpenStack Command Line Interface (CLI) is a powerful tool for managing OpenStack resources. This guide will show you how to install the OpenStack CLI, log in to the OpenStack CLI, and use the OpenStack CLI to manage OpenStack resources.

This guide makes use of the clouds.yaml file to store OpenStack credentials. You can also use environment variables to store your credentials using the openrc file. The clouds.yaml file is the recommended way to store your OpenStack credentials, as it is easier to manage and add multiple clouds (projects, regions etc.).

Install the OpenStack CLI

The installation of the OpenStack CLI is different for each Operating System and distrubution. Below you will find the installation instructions for the most common Linux distributions.

For Windows installations please see Using the OpenStack CLI (Windows).

Instruction for Debian
Instruction for Ubuntu
Instruction for CentOS Stream

Debian (10, 11, 12)

To install the OpenStack CLI, run the following commands:

Step 1
Update your package list to make sure we install the latest version of the OpenStack CLI.

sudo apt update

Step 2
We will now install the OpenStack CLI

Note: Installing the OpenStack CLI using the package manager will install the OpenStack CLI and all the required dependencies. The downside of this method is that you might not have the latest version of the OpenStack CLI. If you want to install the latest version of the OpenStack CLI, you can use pip3 to install the OpenStack CLI, more information can be found on the python-openstackclient PyPi page.

sudo apt install python3-openstackclient

After the installation has finished proceed to Preparing your OpenStack Credentials.

Ubuntu (20.04 | 22.04)

To install the OpenStack CLI, run the following commands:

Step 1
Update your package list to make sure we install the latest version of the OpenStack CLI.

sudo apt update

Step 2
Install python3 and pip3 which are required to install the OpenStack CLI

sudo apt install python3 python3-pip

Step 3
We will now update pip3 to make sure we use the latest version of pip3

sudo pip3 install --upgrade pip

Step 4
Now we can install the OpenStack CLI

sudo pip3 install python-openstackclient

After the installation has finished proceed to Preparing your OpenStack Credentials.

CentOS Stream (8, 9) | RHEL (8, 9) | Rocky Linux (8, 9) | AlmaLinux (8, 9)

To install the OpenStack CLI, run the following commands:

Step 1
Install python3 and pip3

sudo dnf install python3 python3-pip

Step 2
We will now update pip3 to make sure we use the latest version of pip3

sudo pip3 install --upgrade pip

Step 3
Now we can install the OpenStack CLI

sudo pip3 install python-openstackclient

After the installation has finished proceed to Preparing your OpenStack Credentials.

Preparing Your OpenStack Credentials

After installing the OpenStack CLI, we need to prepare our credentials to make sure we are able to login using the OpenStack CLI.

Step 1
First we will create a file to store our OpenStack credentials. In this tutorial we will use the clouds.yaml file to store our credentials. You can also use environment variables to store your credentials using the openrc file.

Create the directory in which the clouds.yaml file will be stored.

mkdir -p ~/.config/openstack

Step 2
We will now create the clouds.yaml file, the next step will describe how to populate the file with the necessary information.

nano ~/.config/openstack/clouds.yaml

Step 3
In the clouds.yaml file add the following content to it. Replace: region, <cloud_name>, <auth_url>, <username>, <password>, <project_name>, <project_id>, <user_domain_name>, and <project_domain_name> with your OpenStack credentials.

clouds:
  <cloud_name>:
    auth:
      auth_url: <auth_url>
      username: "<username>"
      project_id: <project_id>
      project_name: "<project_name>"
      user_domain_name: "<user_domain_name>"
      password: "<password>"
    region_name: "<region>"
    interface: "public"
    identity_api_version: 3

Note: The cloud_name can be any name you want to give to your cloud. We recommend using the region name as the cloud name.

Note: If you do not know all information, you can download the clouds.yaml file from the OpenStack dashboard. Go to the OpenStack dashboard, click on Project and then API Access. Click on DOWNLOAD OPENSTACK RC FILE and click on OPENSTACK CLOUDS.YAML FILE. This will download the clouds.yaml file with all the necessary information.

Note: For security reasons you may want to remove the password line from the clouds.yaml file, when you enter a command in the OpenStack CLI your password will be asked for.

Step 4
Now save the file and exit the text editor. by pressing CTRL + X and then Y and Enter.

After you have configured your credentials you can procceed to Using the OpenStack CLI to test if the OpenStack CLI works.

Using the OpenStack CLI

Now that we have installed the OpenStack CLI, we can use the OpenStack CLI to manage our OpenStack resources.

First we we need to specify the cloud (project/region) we want to use. make sure to replace <cloud_name> with the name you used in the clouds.yaml file.

export OS_CLOUD=<cloud_name>

Now we can use the OpenStack CLI to manage our OpenStack resources. For example, to list all the available images, run the following command:

openstack image list

To list all openstack instances (servers), run the following command:

openstack flavor list

Your are now ready to use the OpenStack CLI to manage your OpenStack resources. The OpenStack CLI has many more commands and options, so be sure to check the OpenStack CLI documentation

Note: Instead of setting the OS_CLOUD environment variable you can also specify the cloud using the --os-cloud option in the OpenStack CLI commands.

The OpenStack Command Line Interface (CLI) is a powerful tool for managing OpenStack resources. This guide will show you how to install the OpenStack CLI, log in to the OpenStack CLI, and use the OpenStack CLI to manage OpenStack resources.

This guide makes use of the clouds.yaml file to store OpenStack credentials. You can also use environment variables to store your credentials using the openrc file. The clouds.yaml file is the recommended way to store your OpenStack credentials, as it is easier to manage and add multiple clouds (projects, regions etc.).

Installation of the OpenStack CLI

The installation of the OpenStack CLI is different for each Operating System and distrubution. Below you will find the installation instructions for Windows.

For Linux installations please see Using the OpenStack CLI (Linux)

Installing Microsoft Visual C++

The OpenStack CLI is build with Python3 but it requires the Microsoft Visual C++ to be installed on your system. You can download the Microsoft Visual C++ using the Microsoft C++ Build Tools

Step 1
Navigate to the Microsoft C++ Build Tools page and download the Build Tools.

Step 2
Run the installer which will download and install the required components.

Step 3
Once the installation is complete, the Visual Studio Build Tools will automatically open. From this window select the Desktop development with C++. This will install the required components for the OpenStack CLI to work. Click the Install button to start the installation.

After the installation has finished proceed to Installing Python3.

Installing Python3

Since the OpenStack Client is build with Python3 we will have to install python3 on our system first.

Step 1
Navigate to the Python Downloads page and download the latest version of Python3. (Do not download the pre-release version)

Step 2
Run the installer and make sure to check the box that says Add Python 3.x to PATH and click Install Now.

After the installation has finished proceed to Installing the OpenStack CLI.

Installing the OpenStack CLI

Now that we have prepared the environment by installing the required components we can now install the OpenStack CLI.

Step 1
Open PowerShell you can do this by hitting WIN + R in the input box that appears you type PowerShell and hit Enter.

Step 2
Within the PowerShell window run the following command to make sure we have the latest version of pip installed.

python -m pip install --upgrade pip

Step 3
Now that we are sure that we have the latest version of pip we can install the OpenStack CLI.

pip install python-openstackclient

After the installation has finished proceed to Preparing your OpenStack Credentials.

Preparing Your OpenStack Credentials

After installing the OpenStack CLI, we need to prepare our credentials to make sure we are able to login using the OpenStack CLI.

Step 1
First we will create a file to store our OpenStack credentials. In this tutorial we will use the clouds.yaml file to store our credentials. You can also use environment variables to store your credentials using the openrc file altough the openrc file does not by default on Windows.

Since we already have our PowerShell open we proceed with creating the OpenStack configuration directory using PowerShell. You can also create the directory yourself if you prefer.

New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.config\openstack"

Note: If you want to create the directory by hand using windows explorer the directory structure should look like: C:\Users\<username>\.config\openstack

Step 2
We will now create the clouds.yaml file, the next step will describe how to populate the file with the necessary information.

New-Item -Path "$env:USERPROFILE\.config\openstack\clouds.yaml" -ItemType File

Note: When creating the clouds.yaml manually using for example Windows Explorer make sure you create a clouds.yaml file and not accidentaly create a clouds.yaml.txt file which is not recognized by the OpenStack CLI.

Step 3
Now that we have created the clouds.yaml file we will open the clouds.yaml file using notepad. The following command will start Notepad with the clouds.yaml you can also chose to open the file manually using Windows Explorer.

Start-Process notepad.exe -ArgumentList "$env:USERPROFILE\.config\openstack\clouds.yaml"

Note: If you want to open the clouds.yaml file manually using Windows Explorer you can find the clouds.yaml file in: C:\Users\<username>\.config\openstack

Step 4
In the clouds.yaml file add the following content to it. Replace: region, <cloud_name>, <auth_url>, <username>, <password>, <project_name>, <project_id>, <user_domain_name>, and <project_domain_name> with your OpenStack credentials.

clouds:
  <cloud_name>:
    auth:
      auth_url: <auth_url>
      username: "<username>"
      project_id: <project_id>
      project_name: "<project_name>"
      user_domain_name: "<user_domain_name>"
      password: "<password>"
    region_name: "<region>"
    interface: "public"
    identity_api_version: 3

Note: The cloud_name can be any name you want to give to your cloud. We recommend using the region name as the cloud name.

Note: If you do not know all information, you can download the clouds.yaml file from the OpenStack dashboard. Go to the OpenStack dashboard, click on Project and then API Access. Click on DOWNLOAD OPENSTACK RC FILE and click on OPENSTACK CLOUDS.YAML FILE. This will download the clouds.yaml file with all the necessary information.

Note: For security reasons you may want to remove the password line from the clouds.yaml file, when you enter a command in the OpenStack CLI your password will be asked for.

Step 5
After entering the correct information in the clouds.yaml file we can now save the clouds.yaml file by pressing CTRL + S and then close the file by clicking on the X in the top right corner of the Notepad window or pressing ALT + F4 in the notepad Window.

After you have configured your credentials you can procceed to Using the OpenStack CLI to test if the OpenStack CLI works.

Using the OpenStack CLI

Now that we have installed the OpenStack CLI, we can use the OpenStack CLI to manage our OpenStack resources.

First we we need to specify the cloud (project/region) we want to use. make sure to replace <cloud_name> with the name you used in the clouds.yaml file.

$env:OS_CLOUD=<cloud_name>

Now we can use the OpenStack CLI to manage our OpenStack resources. For example, to list all the available images, run the following command:

openstack image list

To list all openstack instances (servers), run the following command:

openstack flavor list

Your are now ready to use the OpenStack CLI to manage your OpenStack resources. The OpenStack CLI has many more commands and options, so be sure to check the OpenStack CLI documentation

Note: Instead of setting the OS_CLOUD environment variable you can also specify the cloud using the --os-cloud option in the OpenStack CLI commands.

This articles will guide you through the process of creating a volume.

Using the OpenStack Dashboard

Creating a volume through the OpenStack Dashboard is a simple process.

Step 1
Log in to the OpenStack Dashboard

Step 2
Navigate to the VOLUMES section and click on Volumes

Step 3
Click on Create Volume button right above the volume list.

Step 4
Fill in the details of the volume you want to create. You can specify the size of the volume, the availability zone, and the volume type. Please feel free to change any of the example settings to your needs.

• Volume Name: data-volume
• Description: This is a volume for storing data
• Volume Source: NO SOURCE, EMPTY VOLUME (please see the note below)
• Type: SSD (please see the note below)
• Size (GiB): 10
• Availability Zone: ANY AVAILABILITY ZONE (please see the note below)
• Group: NO GROUP (please see the note below)

Note: The Volume Source field is used to create a volume from an existing volume, snapshot, or image. If you want to create an empty volume, select NO SOURCE, EMPTY VOLUME.

Note: The Type field is often used to provide different specifications or storage tiers. Some volume types might support volume encryption as well. Most OpenStack providers provide distinct naming for encrypted volume types.

Note: The Availability Zone field is used to specify the availability zone where the volume will be created. This is important since volumes cannot be attached to instances in different availability zones.

Note: The Group field is used to specify the volume group where the volume will be created. This is can be a handy tool if you have multiple volume in your OpenStack environment and want to group them together.

Step 5
Click on the small arrow button behind the newly created volume to see actions menu and click on Manage Attachments

Step 6
Select the instance you want to attach the volume to and click on Attach Volume to attach the volume to the instance.

Using the OpenStack CLI

Creating a volume through the OpenStack CLI can be a bit more complicated than using the OpenStack Dashboard, but when you get the hang of it, it can be a powerful tool.

Step 1
First make sure you have setup the OpenStack CLI and that you are able to execute commands using the openstack command. For more information please refer to the Using the OpenStack CLI article.

Step 2
Run the following command to create a volume:

openstack volume create --size <volume_size --type <volume_type> --availability-zone <availability_zone> <volume_name>

Note: The volume_type is often used to provide different specifications or storage tiers. Some volume types might support volume encryption as well. Consult the documentation of your OpenStack providers to select the proper volume type.

Step 3
Check the status of the volume by running the following command:

openstack volume show <volume_name>

Step 4
Attach the volume to an instance by running the following command:

openstack server add volume <instance_name/instance_id> <volume_name/volume_id>

Mounting the volume within the instance

After you have created and attached the volume to an instance, you can mount the volume within the instance. The process of mounting a volume is different for each operating system.

Be default the volume is just empty diskspace which you can use as you like. The following steps will guide you through the process of mounting the volume an adding an filesystem to it so you can use it to store your data.

Instruction for Linux

Instruction for Windows

Linux

Step 1
You can identify the volume by its size and mountpoint. For example, if the volume is 10GB and has no mountpoint, it is likely the volume you just created. it will probably look simular to /dev/sdb but it may be different.

List the available disks on the instance by running the following command:

lsblk

Note: The mountpoint displayed in OpenStack might not be the same as the mountpoint in the instance.

Step 2
Create a new partition on the volume by running the following command:

sudo fdisk <volume>

Step 3
Format the partition by running the following command:

sudo mkfs.ext4 <volume>

Note: You can choose any filesystem to format the partition. In this example, we are using ext4.

Step 4
Create a new directory to mount the volume by running the following command:

sudo mkdir /mnt/data-volume

Note: You can choose any directory to mount the volume. In this example, we are using /mnt/data-volume.

Step 5
Mount the volume by running the following command:

sudo mount <volume> /mnt/data-volume

You can now use the volume to store your data.

Mounting the volume automatically

If you want to mount the volume automatically after a reboot, we need to add an entry to the /etc/fstab file.

When managing multiple volumes on a single instance, it might be more feasible to use the procedure on Identify cinder volumes from within the instance. Or use the steps below. Both procedures result in an automatically mounted volume

Step 1
First we need to identify the volume by its UUID. You can do this by running the following command:

You are looking for the UUID of the volume you just created. It will probably look something like 85ca773c-a78b-415e-b1cd-2c4f1a1d267f. Make sure you copy the UUID of the correct volume. it should be the same path as in the steps above (for example: /dev/sdb).

sudo blkid

Step 2
Now we need to add an entry to the /etc/fstab file. We will use the UUID we found in the previous step to identify the volume.

sudo nano /etc/fstab

Now add the following line to the bottom of the file:

UUID=<linux_volume_id> /mnt/data-volume ext4 defaults 0 0

To save the file press CTRL + X, then Y, and then ENTER.

Step 3
Test the /etc/fstab file by running the following command:

sudo mount -a

The volume should now be mounted automatically after a reboot. If you received an error, please check the /etc/fstab file for any errors.

Windows

Step 1
Right-click the windows logo in the left bottom corner and click on Disk Management.

Step 2
Right click on the Disk you want to prepare and online the disk to be able to use the disk.

Step 3
Right click on the Disk you want to prepare and click on Initialize Disk.

Step 4
In the Initialize Disk window, select the disk you want to initialize, select the GPT (GUID Partition Table) and click on OK.

Step 5
Right click on the unallocated space and click on New Simple Volume. You can just click on Next in the New Simple Volume Wizard to use the default settings. You can change the drive letter and the volume label if you want.

Your disk is now ready to use, you can access it through Window Explorer and use the disk to store you data.

Volumes are a great way to store data for your instances. However, sometimes you may need to resize a volume to add more space. This article will guide you through the process of resizing a volume within OpenStack and resizing the filesystem within the instance (server). For most OpenStack environments, a live extend is possible.

Using the OpenStack Dashboard

To resize a volume using the OpenStack Dashboard, please follow these steps:
Step 1
First log in to the OpenStack Dashboard

Step 2
Navigate to the Volumes section

Step 3
Click on the volume you want to resize

Step 4
Click on the Small Arrow button behind the volume and click Extend Volume

Step 5
Enter the new size of the volume and click Extend Volume

Your volume is now be resized within OpenStack. Please note that you may need to extend your filesystem within the instance (server) as well before you are able to use the new space. To do this please proceed to the section: Resize filesystem within the instance

Using the OpenStack CLI

To resize a volume using the OpenStack CLI, please follow these steps:

Step 1
First make sure you have setup the OpenStack CLI and that you are able to execute commands using the openstack command. For more information please refer to the Using the OpenStack CLI article.

Step 2
Identitfy the volume you want to resize we do this by listing the volumes

openstack volume list

Step 3
Run the following command to resize the volume

openstack --os-volume-api-version 3.42 volume set --size <new-size-in-gb> <volume-id-or-name>

Your volume is now be resized within OpenStack. Please note that you may need to extend your filesystem within the instance (server) as well before you are able to use the new space. To do this please proceed to the section: Resize filesystem within the instance

Resize filesystem within the instance

For both Linux and Windows, you will need to resize the filesystem within the instance (server) as well.

Instructions for Linux

Instructions for Windows

Linux

After resizing the volume within OpenStack, you will need to resize the filesystem within the instance (server) as well.

Step 1
First we need to identify the volume. This can be done using the lsblk command.

lsblk

Step 2
The folowing step is only required if you have partitions on the volume.
If you have partitions on the volume, you will need to resize the partition before resizing the filesystem. This can be done using the growpart command.

sudo growpart <disk> <partion_number>

Step 3
After you will need to resize the filesystem. This can be done using the resize2fs command.

resize2fs <disk/partition>

Windows

After resizing the volume within OpenStack, you will need to resize the filesystem within the instance (server) as well. We recommend using the documentation provided by Microsoft to resize the filesystem.

Instruction for resizing using Disk Management

Instruction for resizing using PowerShell

Using Disk Management

Right-click the windows logo in the left bottom corner and click on Disk Management.

Right-click the volume you want to resize and click Extend Volume.

Follow the wizard to extend the volume and click Finish to complete the process.

If you want to use all of the available space, you can just click Next and then Finish in the wizard.

Using PowerShell

To resize the filesystem using PowerShell, you can use the Resize-Partition cmdlet. The Powershell script below will resize the partition to the maximum size. Replace <drive_letter> with the drive letter of the partition you want to resize.

# Set the drive/partition you want to resize
$TargetDrive = "<drive_letter>"

# Get the maximum size of the partition
$DriveSize = (Get-PartitionSupportedSize -DriveLetter $TargetDrive)

# Resize the partition
Resize-Partition -DriveLetter $TargetDrive -Size $DriveSize.SizeMax

Introduction

Loadbalancers can be an essential part of a cloud infrastructure. Loadbalancers can be used to distribute the incoming traffic to multiple servers. This can in turn increase the availability of the servers and the applications. OpenStack Octavia is a loadbalancer service that provides loadbalancing services to the OpenStack cloud. Octavia is a on-demand and reliable loadbalancer service. Octavia is a replacement for the older Neutron LBaaS service.

Types of loadbalancers

There are two types of Loadbalancers in OpenStack Octavia which can be used to create your Loadbalancer setup.

Single Loadbalancer

A single loadbalancer setup is a simple setup where a single loadbalancer is used to distribute the incoming traffic to the backend servers/applications. This setup is suitable for non-critical applications because if the loadbalancer fails, the whole setup will be down.

Active/Standby Loadbalancer (High Availability)

The Active/Standby Loadbalancer setup is a more reliable setup where the standy loadbalancer will take over the traffic if the active loadbalancer fails. This setup is highly recommended and essential for critical applications. This setup can be used to make sure the availability of the servers and applications can be assured.

Flavors

Loadbalancer flavors are used to chose between the Single and Active/Standby Loadbalancer setups. Most of the time, the Active/Standby Loadbalancer setup is used because of its reliability and availability. Loadbalancer flavors are also used to define the performance of the loadbalancer. The flavors can be used to define the performance of the loadbalancer like the number of connections, the number of requests, the bandwidth, vice versa. Based on your requirements, you can choose the flavor that suits your needs. Most providers indicate the performance of the loadbalancer in the flavor description.

Listeners

Listeners are used to define the incoming traffic to the loadbalancer. The listeners are used to define the protocol, port, and the pool to which the traffic should be forwarded.

Pools

A pool is a group of backend servers or applications to which the traffic should be forwarded. The pools are used to define the protocol, the algorithm, and the backend servers for the specific Listener.

Loadbalancer Algorithms

Pool algorithms are used to define the way the traffic should be distributed to the backend servers.

• Round Robin: is used to distribute the traffic to the backend servers in a circular order.
• Least Connections: is used to distribute the traffic to the backend servers based on the number of connections towards the backend servers.
• Source IP: is used to distribute the traffic to the backend servers based on the source IP of the incoming traffic.

Session Persistence

Session persistence is used to make sure that the traffic from the same client is always forwarded to the same backend server. This is used to make sure that the session data is always available on the same server. This is essential for applications that require session data to be available on the same server. OpenStack Octavia currently supports the following Session persistence methods:

• HTTP_COOKIE: is used to make sure that the traffic from the same client is always forwarded to the same backend server based on the HTTP cookie.
• APP_COOKIE: is used to make sure that the traffic from the same client is always forwarded to the same backend server, uses a hashmap in memory of the loadbalancer and are less reliable then HTTP cookies.
• SOURCE_IP: is used to make sure that the traffic from the same client is always forwarded to the same backend server based on the source IP of the incoming traffic.

Monitors

Monitors are used to define the health of the backend servers. The monitors are used to define the protocol, the interval, the timeout, the retries, and the status of the backend servers. Whenever a backend server or application is down, the monitor will mark the server as down and the traffic will not be forwarded to that server anymore. This way you can make sure that the traffic is only forwarded to the healthy servers to avoid downtime for the users.

SSL Termination (HTTPS)

SSL Termination is used to decrypt the incoming traffic and forward it to the backend servers. This is used to offload the SSL encryption from the backend servers. This way the backend servers can focus on the application and the loadbalancer can focus on the SSL encryption. The storage of the SSL certificates is be done with OpenStack Barbican (Secret Manager) and can be added to the loadbalancers on creation or at a later point. It is required to use the TERMINATED_HTTPS listener protocol to enable SSL Termination at the Loadbalancer.

Where to place your loadbalancer

Chosing the best location for you loadbalancer can be an essential part of the setup. We recommend checking the geographical location of the backend servers to make sure the loadbalancer is placed in the desired region/availability zone (AZ).

Loadbalancers can be used to forward external traffic to the backend servers but they may also be used to forward internal traffic within your private network. This is something to keep in mind when desiging your cloud infrastructure.

Recommendations

When creating a loadbalancer setup, it is recommended to use the Active/Standby Loadbalancer setup. This is because of the reliability and availability of the setup. The Active/Standby Loadbalancer are setup to make sure the availability of the servers and applications can be assured whenever one of the loadbalancers fails.

When you create a loadbalancer we recommend to use an Floating IP address for the loadbalancer. This way we can always swap the IP between loadbalancers in case you want to upgrade or replace the loadbalancer.

Conclusion

Loadbalancers can be an essential part of a cloud infrastructure. Loadbalancers can be used to distribute the incoming traffic to multiple servers. This can in turn increase the availability of the servers and the applications. OpenStack Octavia provides a on-demand and reliable loadbalancer service which is easy to use and manage for your cloud infrastructure.

Now that you know everything you need to know about loadbalancers, you can start creating your own loadbalancer setup. We highly recommend to read the article about creating a loadbalancer with webservers to get started with OpenStack Octavia.