Skip to main content

Configure SSH Between Compute Nodes in OpenStack:

To perform operations like live migration or resizing an instance between compute nodes in OpenStack, SSH key-based authentication must be configured between all the nodes. This ensures smooth communication for moving instance disks without encountering errors like "Permission denied."

Follow these steps to configure SSH between compute nodes: 

Step 1: Obtain or Generate SSH Key Pair:
On the first compute node, either use the existing SSH key pair located in /root/.ssh/id_rsa (private key) and /root/.ssh/id_rsa.pub (public key), or generate a new key pair if none exists:
# ssh-keygen -t rsa -b 2048
This will create a private key (id_rsa) and a public key (id_rsa.pub) in the .ssh directory. 

Step 2: Disable SELinux (Optional):
If you are using SELinux, switch to permissive mode temporarily to avoid permission issues:
# setenforce 0

Step 3: Enable Login for the nova User:
Ensure that the nova user has shell access:
# usermod -s /bin/bash nova
Switch to the nova user:
#su nova

Step 4: Set Up SSH for the nova User:
As root, create the necessary .ssh directory for the nova user and copy the private key generated in Step 1 into it:
# mkdir -p /var/lib/nova/.ssh # cp <private-key-path> /var/lib/nova/.ssh/id_rsa
Then configure SSH to skip host key checking to streamline logins:
# echo 'StrictHostKeyChecking no' >> /var/lib/nova/.ssh/config
Ensure correct permissions are set on the key and configuration files:
# chmod 600 /var/lib/nova/.ssh/id_rsa /var/lib/nova/.ssh/authorized_keys

Step 5: Repeat SSH Configuration on Other Nodes:
Repeat Steps 2 through 4 on every compute node. Important: Do not generate a new SSH key pair for each node. All nodes should use the same key pair to communicate.

Step 6: Copy the Public Key to Other Nodes:
From the first node, where the key pair was created, use ssh-copy-id to copy the public key (id_rsa.pub) to the nova user on each destination compute node:
# ssh-copy-id -i /var/lib/nova/.ssh/id_rsa.pub nova@<remote-compute-node>
This command installs the public key on the destination node's ~/.ssh/authorized_keys file, enabling passwordless access. 

Step 7: Verify SSH Access:
As the nova user, check if passwordless SSH login works between nodes:
# su nova # ssh <compute-node-address> # exit
You should be able to log in without entering a password. 

Step 8: Restart Services:
Once SSH configuration is complete on all nodes, restart the libvirt and nova-compute services to ensure proper functioning of live migration and other operations:
# systemctl restart libvirtd.service # systemctl restart openstack-nova-compute.service

Summary:
Configuring SSH between compute nodes in OpenStack is crucial for enabling live migration, resizing, and other operations that require seamless inter-node communication. By sharing the same key pair across all compute nodes and ensuring that the nova user has proper access, you can prevent issues during instance migration. 

By following these steps, you can ensure that your OpenStack environment is properly configured for efficient and secure node-to-node communication.

Comments

Popular posts from this blog

temp-1

  🔧 vast_id Configuration Key: vast_id Description This section defines the VAST ID , a unique numeric identifier used by internal systems for asset tracking, automation, or integration with enterprise management platforms. It helps associate the server with inventory records, monitoring tools, or deployment workflows. ✅ Used during provisioning to register the system in centralized databases or orchestration systems. JSON Format json 1 "vast_id" : 12194 ✅ Can also be provided as a string: json 1 "vast_id" : "12194" Field Reference vast_id String or Integer Unique identifier for the system in VAST (Verizon Asset Systems Tracker) 12194 ✅ Must be non-empty and numeric — leading zeros may be stripped depending on system. Validations Enforced vast_id  is required and must be a non-empty string or integer Ensures the field is present and contains usable data If  vast_id  is a string, it must not be blank or whitespace-only Prevents " " , "...

testing

09052025 T-1 { "volume_groups" : { "vgroot" : { "vgsize" : "304G" , "fs_type" : "xfs" } } , "logical_volumes" : { "root" : { "lvroot" : { "vgname" : "vgroot" , "lvname" : "lvroot" , "lvsize" : "12G" , "mountpoint" : "/" , "purpose" : "root filesystem" , "disk" : 1 , "partition" : 2 } } , "swap" : { "lvswap" : { "vgname" : "vgroot" , "lvname" : "lvswap" , "lvsize" : "4G" , "mountpoint" : "NA" , "purpose" : "swap" , "disk" : 1 , "partit...

temp

 {   "_id": {     "$oid": "6841e4b0fd270b2ab92d7eaa"   },   // 📌 [Auto-generated]   // Description: Unique system identifier for internal use (MongoDB ObjectId).   // Type: ObjectId (string)   // Required: No (automatically handled)   "vast_id": "21452",   // 📌 [Required]   // Description: Your unique request ID or reference number.   // Type: string   // Format: Numeric string (e.g., "21452")   // Example: "21452"   "env": "dev",   // 📌 [Required]   // Description: The environment where the VM will be deployed.   // Type: string   // Allowed values: "dev", "qa", "uat", "prod"   // Example: "dev" for development, "prod" for production   "ver": "0.2",   // 📌 [Do Not Modify]   // Description: Template version. Used by automation to ensure compatibility.   // Type: string   // Format: Semantic versioning (e.g., "...