Power Business Continuity and Automation

Power Business Continuity and Automation

Connect, learn, and share your experiences using the business continuity and automation technologies and practices designed to ensure uninterrupted operations and rapid recovery for workloads running on IBM Power systems. 


#Power
#TechXchangeConferenceLab

 View Only

Role-Based Red Hat Linux Installation on IBM PowerVM with Ansible

By Spoorthy S posted Tue October 14, 2025 02:34 AM

  

Role-Based Red Hat Linux Installation on IBM PowerVM with Ansible 

By: Spoorthy S 

Installing Red Hat Enterprise Linux (RHEL) manually on IBM PowerVM logical partitions (LPARs) can be time-consuming and prone to errors. An alternative is using a NIM server, which is based on AIX OS; however, it often requires manual intervention as well. Our solution addresses this challenge by offering a fully automated approach with zero manual input. The primary objective of this blog is to introduce this Ansible Role-based solution and provide a deep dive into how it works. The automation leverages network-based installation via PXE boot, orchestrated through a modular Ansible role named redhat_linux_install. 

This role encapsulates all necessary steps from provisioning the LPAR to validating the OS installation, making it ideal for teams aiming to streamline Linux deployments on IBM Power systems. 

Infrastructure Components 

  • Repository Server: Hosts RHEL distro files and kickstart configuration via HTTP 
  • PXE Server: Runs DHCP and TFTP services to support network boot. 
  • LPAR: Target logical partition for OS installation. 
  • HMC: Manages the LPAR and triggers the network boot. 

Installation flow: 

  • When an installation is triggered, a kickstart file is generated on the repository server which contains the configuration details of the required Linux OS installation. The repository server also contains the various builds available.  
  • The boot files of the required OS are then downloaded on the DHCP-TFTP serverA grub config file is also created on this server using the previously generated kickstart file. 
  • Next, the lpar_netboot command instructs the lpar to start network boot, by having the partition send out a bootp request to the DHCP-TFTP server to fetch the initial boot files. With this the required Linux OS is installed on the Lpar.  

Prerequisites 

  • Python 3.8 or later 
  • Ansible 2.12 or later 

Role Execution Flow 

The role redhat_linux_install encapsulates the following stages: 

1.  LPAR creation: 

  • Logic: Uses the `powervm_lpar_instance` module to create a new logical partition on the specified managed system, this task will run if the LPAR is not available in the managed system. 
  • Parameters: Includes LPAR name, profile, memory, processor settings, disk size and virtual NIC configuration. 
  • Outcome: A new LPAR is provisioned and ready for OS installation. 
  • The LPAR must be created with a virtual NIC attached to a valid network. If no network adapter is available or pingable, the playbook will fail gracefully with an appropriate error message. 

2MAC Address Retrieval 

  • Logic: Extracts the MAC address of the virtual NIC associated with the newly created LPAR. 
  • Command Used: lparnetboot command to retrieve the MAC address  
  • Purpose: Required for DHCP and PXE configuration to identify the LPAR during network boot. 
  • Condition Checked: The task verifies that at least one network adapter is marked as "successful" and pingable. If none are found, the installation halts with a descriptive failure message. 

3. Kickstart File Generation 

  • Logic: Create Kickstart file using the distro version and MAC address. Copy it to the repository server 
  • Template Used: `ks.j2` 
  • Destination: `/var/www/html/linux_ks/{{ ks_file }}` on the repository server. 
  • This file defines installation parameters such as: 
    - Language and keyboard layout 
    - Network configuration 
    - Partitioning and bootloader setup 
    - Package selection (`@core`, `kexec-tools`, etc.) 

4.  PXE Service Validation and Setup 

  • Logic: Checks if `dhcpd` and `tftp` services are running on PXE server. Installs and configures them if they are not present. 
  • Modules Used: `service_facts`, `dnf`, `systemd`, `firewalld` 
  • Services Checked: `dhcpd.service`, `tftp.service`, `xinetd.service` 
  • Firewall Ports Opened: UDP 67 (DHCP), UDP 69 (TFTP) 

5. DHCP Range Calculation 

  • Logic: Uses a Bash script to calculate usable IP range from the provided subnet. 
  • Script Behavior: Converts subnet IP and netmask to decimal, calculates start and end IPs. 
  • Facts Set: `dhcp_range_start`, `dhcp_range_end` 
  • Template Used: `dhcp_server_conf.j2` 
  • Destination: `/etc/dhcp/dhcpd.conf` on PXE server 

6. PXE Server Preparation 

  • Logic: Prepares PXE server by cleaning old directories and downloading boot files. 
  • Actions: Deletes old TFTP boot folder, calculates `cutdir`, downloads `/boot` and `/ppc` using `wget`. 
  • GRUB Setup: Uses `grub2-mknetdir`, generates `grub.cfg` from `grub_conf.j2`, copies to `powerpc-ieee1275`. 

7. DHCP Configuration for LPAR 

  • Logic: Adds static DHCP entry for LPAR. 
  • Template Used: `dhcpd_conf.j2` 
  • Destination: `/etc/dhcp/dhcpd.conf` 
  • Actions: Backs up current dhcp config, inserts block to dhcp config file with `blockinfile`, restarts `dhcpd` service. 

8. LPAR Netboot Trigger 

  • Logic: Triggers network boot on LPAR via HMC . 
  • Module Used: `powervm_lpar_instance` from power_hmc collection 
  • Action: trigger lpar_netboot command on HMC using LPAR parameters 
  • Parameters: `vm_ip`, `vm_mac`, `nim_ip`, `nim_gateway`, `nim_subnetmask` 

9. DHCP Cleanup 

  • Logic: Restore the DHCP config file to the original by removing the config related to LPAR. 
  • Actions: Backs up dhcp config file, removes LPAR related DHCP block in config file and restarts dhcpd service. 

10. Post-Installation Validation 

  • Logic: Verifies successful OS installation and accessibility on the VM. 
  • Steps: Waits for SSH service to be active, gathers facts and prints OS version 

Example Playbook: redhat_linux_install.yml

---
- name: Install Redhat Operating system on Linux system
hosts: vm
collections:
- ibm.power_hmc
gather_facts: false
roles:
- role: redhat_linux_install
vars:
distro: Rhel9.1le
repo_dir: /rc-2.0/
host_ip: 1.2.3.4
host_gw: 1.2.3.1
host_subnet: 1.2.3.0
host_netmask: 255.255.255.0
dns_ip: 1.0.0.1
hostname: abc.hmc.com
lpar_name: abc-02
managed_system: abc-24
network_name: test
mem: 6144
proc: 4
disk_size: 28590
host_password: "{{ hostvars[groups['vm'][0]].ansible_password }}"

Inventory file: servers.yml 

[repo] 

repo_server ansible_host=1.4.2.5 ansible_become_pass='abcd' ansible_user=hmc ansible_password=abcd 

[pxe] 

pxe_server ansible_host=1.4.2.9 ansible_become_pass='abcd' ansible_user=root ansible_password=abcd 

[hmcs] 

hmc_server ansible_host=1.4.2.2 ansible_become_pass='abcd' ansible_user=root ansible_password=abcd 

[vm] 

host_vm ansible_host=aaa.abc.com ansible_user=root ansible_password=abcd host_ip=9.9.9.9 

 

Ansible command to run the installation using playbook: 

ansible-playbook -vvvi servers.yml redhat_linux_install.yml 

 

Security Best Practices 

Store sensitive credentials (e.g., HMC auth) in Ansible Vaults. Use SSH key-based authentication for secure access to PXE and repository servers. 

References 

  • Linux Kernel GitHub: https://github.com/torvalds/linux 

1 comment
29 views

Permalink

Comments

Wed October 15, 2025 03:44 AM

It looks like indentation in the playbook was lost when pasting.