On-Prem Manual Process

This page covers only the on-prem-specific portion of the operator workflow. Once the host is prepared, guest storage exists, and bastion staging is done, return to the stock AWS MANUAL PROCESS.

Table Of Contents

• 1. Prepare The Operator Workstation
• 2. Verify The On-Prem virt-01 Host Contract
• 3. Prepare The Guest Storage Volume Group
• 4. Configure The On-Prem Inventory And Group Vars
• 5. Bootstrap The Host And Provision Guest LVs
• 6. Build The Bastion And Stage The Project
• 7. Hand Back To The Stock Runbook

1. Prepare The Operator Workstation

The on-prem path uses the same controller-side secret and content inputs as the AWS path, except there is no public-cloud CLI or stack deployment step.

Required local inputs:

• repo checkout
• SSH keypair
• pull secret
• RHSM credentials
• optional local lab credentials

Keep these stock pages nearby:

• AWS PREREQUISITES: RED HAT INPUTS
• SECRETS

Install the collection dependencies and syntax-check the on-prem entrypoints:

cd <project-root>/aws-metal-openshift-demo
ansible-galaxy collection install -r requirements.yml

cd <project-root>/on-prem-openshift-demo
ansible-playbook --syntax-check playbooks/site-bootstrap.yml
ansible-playbook --syntax-check playbooks/site-lab.yml

2. Verify The On-Prem virt-01 Host Contract

The on-prem target starts after the host already exists. Before bootstrap, confirm that host can stand in for virt-01:

• SSH reachable from the operator workstation
• RHEL installed and updated to the desired baseline
• nested KVM available
• an uplink interface is present for OVS integration
• local storage is visible and the guest VG exists or can be created
• you know what bastion-side host and user you want to publish through:
  • on_prem_bastion_hypervisor_host
  • on_prem_bastion_hypervisor_user

Minimal verification:

ssh <hypervisor-admin-user>@<hypervisor-management-ip> <<'EOF'
hostnamectl --static
sudo virt-host-validate
sudo lsblk
sudo vgs
EOF

If CPU, RAM, or NUMA shape differs from the validated m5.metal baseline, read the host-sizing guidance before bootstrap:

• HOST SIZING

3. Prepare The Guest Storage Volume Group

On-prem guest disks are created as logical volumes inside an operator-provided volume group.

The current lab footprint expects roughly:

• 5950 GiB of guest LV capacity for the full current design

That is only the raw guest-disk sum. Leave additional headroom for:

• host root growth
• image cache
• mirror-content staging
• rebuild hygiene

Example check:

ssh <hypervisor-admin-user>@<hypervisor-management-ip> <<'EOF'
sudo vgs
sudo lvs
EOF

If the volume group does not exist yet, create it before bootstrap using your site-local storage procedure. This repo does not own PV creation.

What the repo does own:

• validating the volume group exists
• validating free space before provisioning
• creating the missing guest LVs
• publishing the /dev/ebs/* compatibility symlinks the stock guest roles use

4. Configure The On-Prem Inventory And Group Vars

The current on-prem target keeps the stock aws_metal inventory-group name on purpose so the existing support/day-2 playbooks do not need to fork.

Edit these files before the first run:

• inventory/hosts.yml
• inventory/group_vars/all.yml

What must be correct:

• ansible_host
• ansible_user
• ansible_ssh_private_key_file
• on_prem_lvm_volume_group
• on_prem_bastion_hypervisor_host
• on_prem_bastion_hypervisor_user
• any optional on_prem_lvm_lv_name_prefix
• any project-local credential overrides

At this stage, the on-prem subtree reuses the stock guest and day-2 vars and playbooks from aws-metal-openshift-demo through local wrappers. It does not modify the AWS-target codepath.

5. Bootstrap The Host And Provision Guest LVs

This is the main on-prem divergence from the AWS path.

Run:

cd <project-root>/on-prem-openshift-demo

ansible-playbook playbooks/bootstrap/site.yml

This is the on-prem equivalent of the early AWS host steps:

• host base configuration
• host CPU and memory policy
• OVS / libvirt host setup
• guest base-image staging
• LVM guest LV validation and creation
• /dev/ebs/* compatibility symlink publication

When it succeeds, the host should satisfy the same effective guest-disk contract the stock guest roles already expect.

Useful verification:

ssh <hypervisor-admin-user>@<hypervisor-management-ip> <<'EOF'
sudo lvs
sudo ls -l /dev/ebs
EOF

6. Build The Bastion And Stage The Project

The current on-prem site-bootstrap.yml:

• runs the on-prem bootstrap host prep
• reuses the stock bastion build
• stages both the on-prem subtree and the stock AWS-target subtree onto bastion through the local on-prem bastion-stage wrapper
• rewrites the bastion-side runtime inventory so the bastion can SSH back to the hypervisor without requiring ec2-user

Run:

cd <project-root>/on-prem-openshift-demo

ansible-playbook playbooks/site-bootstrap.yml

After this, the bastion should exist and the project should be staged.

7. Hand Back To The Stock Runbook

At this point, the on-prem-specific portion is over.

Choose the next stock runbook entry based on what you already completed:

• if you want the manual bastion-forward process:
  • Resume at AWS manual step 13A
• if you are still walking the support-services flow by hand from the bastion build:
  • Resume at AWS manual step 12

For automation rather than the hand-run sequence, use:

cd <project-root>/on-prem-openshift-demo
ansible-playbook playbooks/site-lab.yml