Red Hat OpenShift is a unified platform to build, modernize, and deploy applications at scale. In a previous tutorial, you learned how to deploy the Red Hat OpenShift platform on IBM® Z and IBM z/VM. In this tutorial, learn how to deploy Red Hat OpenShift on IBM LinuxONE and the Kernel-based Virtual Machine (KVM) hypervisor that is provided by Red Hat Enterprise Linux.

Red Hat OpenShift overview

Red Hat OpenShift is a hybrid-cloud enterprise Kubernetes application platform. It provides a set of container-based open source tools that enable digital transformation, accelerating application development while maintaining optimal use of infrastructure.

Red Hat OpenShift is optimized to improve developer productivity and promote innovation. It includes an enterprise-grade Linux® operating system, container runtime, networking, monitoring, registry, authentication, and authorization solutions. Red Hat OpenShift also offers several add-ons, such as Service Mesh (based on Istio), Serverless (based on Knative), and Red Hat OpenShift Pipelines (based on Tekton) as well as support for a variety of persistent storage solutions such as Red Hat OpenShift Data Foundation bundled with Red Hat OpenShift Plus and IBM Fusion Data Foundation and Container Native Storage Access using IBM Spectrum Scale.

Technology stack

Technology stack

Prerequisites

In this tutorial, the minimum requirements are used to get the environment up and running. For production or performance testing, refer to the preferred configuration from the official Red Hat documentation.

The minimum machine requirements for a cluster with a user-provisioned infrastructure (UPI) are:

One temporary bootstrap node
Three control plane (or master) nodes
At least two compute plane (or worker) nodes
One Bastion (infrastructure) node (recommended)
A valid subscription of the Red Hat OpenShift cluster for IBM zSystems

Note: If you do not have a Red Hat OpenShift Container Platform subscription, you can request an evaluation subscription.

Minimum resource requirements

Fig 2

Install Red Hat OpenShift Container Platform using one of the following IBM Z/LinuxONE hardware options.

IBM z16 (all models), IBM z15 (all models), IBM z14 (all models)
IBM LinuxONE 4 (all models), IBM LinuxONE III (all models), IBM LinuxONE Emperor II, IBM LinuxONE Rockhopper II

Minimum hardware requirements

One logical partition (LPAR) with six IFLs (SMT2 enabled)
One OSA or RoCE network adapter

Operating system requirements

One Red Hat Enterprise Linux (RHEL) version 8.6+ system that is deployed natively on a logical partition (LPAR)

Note: This tutorial assumes that the RHEL KVM host system is already installed in a logical partition.

Estimated time

This tutorial should take approximately one hour to complete.

Fig 3

The bootstrap node, control plane nodes (or masters), and compute plane nodes (or workers) must use Red Hat Enterprise CoreOS (RHCOS) as the operating system. For the Bastion node, I recommend using Red Hat Enterprise Linux, which is provided with the subscription to Red Hat OpenShift Container Platform.

All nodes that form a Red Hat OpenShift cluster require network access to the HTTP server, which usually runs on the Bastion node. During the Red Hat OpenShift Container Platform installation process, nodes attempt to fetch the Ignition configuration files (master, worker, or bootstrap) as well as the RHCOS image (rootfs) from the HTTP server. The virtual machines under KVM are configured with static IP addresses. No DHCP server is required.

The following figure shows what this layout looks like. This tutorial provides all helper scripts to facilitate the learning process. All scripts are available from this GitHub repository.

Environment

Fig 4

In this tutorial, each KVM guest accesses a KVM network bridge set up as macvtap that enables all nodes of this Red Hat OpenShift cluster to be on the same network range as the KVM host server.

Note: In this network configuration, the KVM host does not have network access to any of the KVM guests. This is why it is important to access your KVM guests from your workstation, not the KVM host.

This way, if you need to set up multiple LPARs, it's easier to expand the reliability of the solution using multiple logical partitions on a single server or if you decide to extend your Red Hat OpenShift cluster to multiple physical servers. The KVM virtual switch uses a configuration called macvtap bridge to deliver this capability.

The following image shows a visual representation of how macvtap works.

Fig 5

Step 1. Set up the RHEL KVM host

Connect from your workstation (MacOS, Microsoft Windows, or any Linux Distro) to the RHEL KVM host.
```
Login: root
Password: <password>
```
Note: The options to connect to your KVM host are:
- Linux/MacOS: Use a terminal window.
  
  Example:
```
# ssh <user>@<you_KVM_host_IP_address>
```
- Windows: Use PuTTY to connect to the remote RHEL KVM host.
Enable non-root users to use virsh cli and manipulate system-wide KVM resources (such as VMs and networks).
Install the necessary packages to enable the system to be a KVM host.
```
# dnf install qemu-kvm libvirt virt-install virt-viewer
```
Edit the /etc/libvirt/libvirtd.conf file.
```
# vi /etc/libvirt/libvirtd.conf
```
Uncomment the following directions for /etc/libvirt/libvirtd.conf.
```
unix_sock_group = "libvirt"
unix_sock_rw_perms = "0770
```
Note: This step is not mandatory, but is recommended. Virtual machines run as a nonprivileged user.
Create a non-root user.
```
# useradd ocpuser
```
Set a password for the new user.
```
# passwd ocpuser
```

Add a non-root user to the kvm and libvirt groups.

# usermod -aG kvm ocpuser
# usermod -aG libvirt ocpuser

Edit the file /home/ocpuser/.bash_profile, and add the following line.
```
export LIBVIRT_DEFAULT_URI="qemu:///system"
```
Make sure that the file you edited in the previous step has the proper ownership and group (ocpuser:ocpuser).
Restart the service for the libvirtd daemon, then log out and log in again.
```
# systemctl restart libvirtd
```
Log out of the root user.

Now, complete the following steps.

Log on to your KVM host as the ocpuser user.
Create a cloud-init-demo directory.
Go to this GitHub repository, and copy the files from the cloud-init directory as well as the macvtap-net.xml file to the newly created cloud-init-demo directory in your RHEL KVM host system.

Note: You must have access to a Red Hat account with a Red Hat Enterprise Linux for IBM Z entitlement or subscription to continue the tutorial from this point. This access enables you to download the files from the Red Hat official repository. Go to redhat.com > customer portal > Downloads > Red Hat Enterprise Linux > Red Hat Enterprise Linux for IBM zSystems, and copy the files to the RHEL KVM host system.
On your RHEL KVM system, ensure that you are logged in as ocpuser, and create a directory called resources in your user home directory: /home/ocpuser/resources.
Download the rhel-8.6-s390x-kvm.qcow2 and rhel-8.6-s390x.iso required files, and copy them to the KVM host system in the /home/ocpuser/resources directory.
On the KVM host system, the cloud-init-demo directory should contain the following code.
```
$ ls cloud-init-demo
cloud_init.cfg  create-guest.sh  network_config_static.cfg
```

Check that the current virtual bridges defined in the RHEL KVM host.

$ virsh net-list
 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

Create the new bridge using the previously created macvtap-net.xml file.

$ virsh net-define macvtap-net.xml
Network macvtap-net defined from macvtap-net.xml

Activate the new bridge and set it to auto-start.

$ virsh net-autostart macvtap-net
Network macvtap-net marked as autostarted

$ virsh net-start  macvtap-net
Network macvtap-net started

Check whether the new bridge is created, active, and set to auto-start.

$ virsh net-list
 Name          State    Autostart   Persistent
------------------------------------------------
 default            active   yes         yes
 macvtap-net        active   yes         yes

Set the /var/lib/libvirt/images permissions.

$ sudo chown root:libvirt /var/lib/libvirt/images
$ sudo chmod 775 /var/lib/libvirt/images

Move the qcow2 file and ISO image from the cloud-init-demo directory to /var/lib/libvirt/images.

$ sudo mv /home/ocpuser/resources/rhel-8.6-s390x-kvm.qcow2 /home/ocpuser/resources/rhel-8.6-s390x.iso /var/lib/libvirt/images

Run the create-guest.sh script to create the VM with the RHEL OS for the Bastion server.

Note: Make the create-guest.sh executable by issuing the following command: $ chmod +x create-guest.sh.

$ ./create-guest.sh
Formatting '/var/lib/libvirt/images/<user1bastion>-snapshot-cloudimg.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=42949672960 backing_file=/var/lib/libvirt/rhel-8.6-s390x-kvm.qcow2 backing_fmt=qcow2 lazy_refcounts=off refcount_bits=16
image: /var/lib/libvirt/images/<kvmbastion>-snapshot-cloudimg.qcow2
file format: qcow2
….
Starting install..
…Domain creation completed.

Run the following command to start your new VM.
```
$ virsh  start user1bastion
```

Verify that the VM is running.

$ virsh list --all
 Id   Name         State
----------------------------
 2    user1bastion   running

Step 1.1. Configure core services for Red Hat OpenShift UPI deployment in your Bastion guest virtual machine

Connect to your new Bastion guest virtual machine from your local machine (that is, your laptop or workstation). Do not connect from the RHEL KVM host.

Note: It can take 2-5 minutes for the Bastion system to be ready.
```
$ ssh rhel@<your_IP-address-bastion>
```
Get root access by typing the following command.
```
$ sudo su –
```
Create an internal repository using the ISO DVD attached to the virtual machine.
```
# mkdir /media/ISO
```
Mount the device of the VM that has the ISO DVD image.
```
# mount /dev/sr1 /media/ISO
```
Copy the rheldvd.repo file from your user ID from the dedicated GitHub repository to the Bastion guest virtual machine that you created previously at /etc/yum.repos.d/rheldvd.repo.

Note: To copy files to your Bastion system, use the following instructions, if required.

Linux/MacOS: Copy the rheldvd.repo file to your workstation and then to your Bastion system as the rhel user.

Example: # scp rheldvd.repo rhel@<your_Bastion_IP_Address>:/home/rhel

Then, copy the file from /home/rhel/rheldvd.repo to the /etc/yum.repos.d as root: # sudo cp /home/rhel/rheldvd.repo /etc/yum.repos.d.

Windows OS Copy the rheldvd.repo file to your workstation and then to your Bastion system as the rhel user using the [WinSCP application. Next, copy the file from /home/rhel/rheldvd.repo to /etc/yum.repos.d as root: # sudo cp /home/rhel/rheldvd.repo /etc/yum.repos.d.

Step 1.2. Install and configure the DNS service

  # dnf install bind bind-utils

Create a backup of the named.conf file.
```
# cd /etc/
# cp named.conf named.bak
```
Copy the file named.conf from the GitHub repository to the Bastion guest virtual machine at /etc/named.conf.

Note: Make sure to set the proper owner and permissions for /etc/named.conf.
```
    # chown root:named /etc/named.conf
    # chmod 640 /etc/named.conf
    # chcon --reference=/etc/named.bak /etc/named.conf
```
Copy the user1.local.db and user1.local.rev files from the GitHub repository to the Bastion guest virtual machine at /var/named/user1.local.db and /var/named/user1.local.rev.
Make sure that the files have the correct ownership.

# chown named:named /var/named/user1.local.db

# chown named:named /var/named/user1.local.rev

Note: Set the correct owner and permissions for the following files.
```
   # chmod 660 /var/named/user1.local.db
   # chmod 660 /var/named/user1.local.rev
   # restorecon -r -v /var/named
```
Enable the named service, make it persistent across reboots, and test the configuration.

# systemctl --now enable named Created symlink /etc/systemd/system/multi-user.target.wants/named.service → /usr/lib/systemd/system/named.service.

Step 1.3. Install and configure HAProxy

 # dnf install haproxy

Back up the default configuration file.

# cd /etc/haproxy
# cp haproxy.cfg haproxy.bak

Copy the haproxy.cfg file from the GitHub repository to /etc/haproxy/haproxy.cfg in the Bastion guest virtual machine.

Note: Be sure to set the proper owner and permissions for /etc/haproxy/haproxy.cfg.
```
# chown root:root /etc/haproxy/haproxy.cfg

# chmod 644 /etc/haproxy/haproxy.cfg

# chcon --reference=/etc/haproxy/haproxy.bak /etc/haproxy/haproxy.cfg
```
Enable the SELinux Boolean.
```
# setsebool -P haproxy_connect_any 1
```
Start and enable the haproxy to be persistent across reboots.
```
# systemctl --now enable haproxy
```

Step 1.4. Install and configure HTTPd

# dnf install httpd

Create a backup of the configuration file.

# cd /etc/httpd/conf
# cp httpd.conf httpd.bak

Edit the httpd.conf file to modify Listen 80 to Listen 8088, and save the file.
Add the SELinux context to enable HTTPd to bind to that custom port configuration.
```
# semanage port -a -t http_port_t -p tcp 8088
```
Start and enable HTTPd to be persistent across reboots.
```
# systemctl --now enable httpd
```

Step 2. Create the Red Hat OpenShift cluster

Create the directories that will be used by the OpenShift Container Platform installation process.
```
# mkdir /var/www/html/ocp
# mkdir /var/www/html/ignitions
# mkdir /root/ocp-install
```

Download the required files.

# cd /root/ocp-install
# curl -o openshift-install.tar.gz 'https://mirror.openshift.com/pub/openshift-v4/s390x/clients/ocp/4.13.4/openshift-install-linux-4.13.4.tar.gz'

# curl -o openshift-client-linux.tar.gz 'https://mirror.openshift.com/pub/openshift-v4/s390x/clients/ocp/4.13.4/openshift-client-linux-4.13.4.tar.gz'

Download the rootfs file that is used for the creation of the Red Hat OpenShift cluster nodes.

# cd /var/www/html/ocp
# curl -o rhcos-installer-rootfs.s390x.img 'https://mirror.openshift.com/pub/openshift-v4/s390x/dependencies/rhcos/4.13/4.13.0/rhcos-installer-rootfs.s390x.img'

Create a symbolic link to the file.

# ln -s rhcos-installer-rootfs.s390x.img rootfs.img

Prepare the openshift-install binary for the next steps of the Red Hat OpenShift installation.

# cd /root/ocp-install
# tar zxvf openshift-install.tar.gz
README.md
openshift-install
# chmod +x openshift-install

Generate the SSH key that is used to access your nodes when Red Hat OpenShift is deployed.

Note: Do not enter a passphrase for the following step.

Example:

# ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:oGtK67DNVtkHeTwO5PeyatQSVKIKvgHnrDPa+16S4x0
The key's randomart image is:
+---[RSA 3072]----+
|      ...        |
|     .o.         |
|o . .+.o         |
|o= . .*.=        |
| o+ .o OSo       |
| .o oo+ = .      |
|=...*.Eo o       |
|.X.= =...        |
|ooO++.o.         |
+----[SHA256]-----+

Use the generated key to complete the ssh-public-key section of the install-config.yaml file.

# cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDGvqfrMYmyyZZECggNBwrI2P1eLhj63NbQ8yY/blvpW0g7y0cOyyGbP968fvtOrQwYGxxM3qAjuy7S1L0EhUIkNwWIJmKPok/XNEloLUz8cv+g5To/I6rxxP/N4DmAynCNJhHBuX6/fOI2lKWlkd47i/Cto46fA++YzHIc9PLMBfz1cgvsae5o6wftvZ9k9mtvohFP4TcUed8WTL9W51Mxkos8i9p2sHcFyW20/6P97pZTmaa4gVURH+C/ah+VwCljJwy9iDyubfqK91Sqm8MriPbWjcE1naaL9SgGQemVBB1Ceeolq9xdFoQt77Y3y+gZ/yHAEhQupb0FW4+gPLUgirs6WsinBsWPHID+E6nxnKz8OT5E36mZTC71erxvJTDm8YT1DUtnMOQ6q+...

Note 1: To access the pull secret, you must have a Red Hat account with a valid Red Hat OpenShift subscription.

Note 2: Before you proceed, ensure that in the install-config.yaml file, you have replaced the values of the <pull-secret> and the <ssh-public-key> variables with the correct values enclosed in single quotation marks.

After completing the previous steps, you should have the following result.

# ls /root/ocp-install/ocp-deploy
install-config.yaml

# ls /root/ocp-install
ocp-deploy openshift-install test_dns.sh create-ignitions-files.sh

Before you proceed with the installation process, you must verify the DNS service name resolution by running the test_dns.sh script. If the script completes with a "resolution successful" message, you can proceed to the next step. If not, verify your DNS configuration and try again.

You must create the ignition files and copy them to the correct directory so that they can be accessed during the installation of the Red Hat OpenShift nodes. You complete these tasks by running the create-ignition-files.sh script and verifying that the files have been created in the correct locations.

# cd /root/ocp-install
# ./create-ignition-files.sh

# ls /var/www/html/ignitions
bootstrap.ign master.ign worker.ign

Step 2.1. Create Red Hat OpenShift guest nodes on KVM

Log on to the KVM host as the ocpuser user.
Create the ocp_vms directory.
Copy all the files from the GitHub repository to the newly created ocp_vms directory in your host KVM system.

Download the following files.

$ cd /var/lib/libvirt/images

$ curl -o kernel 'https://mirror.openshift.com/pub/openshift-v4/s390x/dependencies/rhcos/4.13/4.13.0/rhcos-4.13.0-s390x-live-kernel-s390x'

$ curl -o initramfs 'https://mirror.openshift.com/pub/openshift-v4/s390x/dependencies/rhcos/4.13/4.13.0/rhcos-4.13.0-s390x-live-initramfs.s390x.img'

You should see the following information in your /home/ocpuser/ocp_vms directory.

$ cd /home/ocpuser/ocp_vms
$ chmod +x *sh
1-make-bootstrap-vm.sh  2-make-master-vms.sh  3-make-worker-vms.sh  env

Because all these files have been prestaged, it's a simple process to create the new guest VMs. We encourage you to look at each of these steps to see the correct commands to create the guest VMs.

Step 2.2. Create the bootstrap node

$ ./1-make-bootstrap-vm.sh

When this script runs, it creates the VM for the bootstrap node. The VM does start automatically. To start the VM so that the bootstrap can load its configuration and proceed, use the following command.
```
$ virsh start kvm1-bootstrap
```
To monitor the installation process for the bootstrap, log in from your workstation to Bastion as the rhel user and become the root user to issue the following command.

Example:
```
$ sudo su -
# ssh core@bootstrap.kvm1.user1.local
```
To access the bootstrap log file, run the following command.
```
$ journalctl -b -f -u bootkube.service
```
Note: This step normally takes 5-15 minutes.
The bootstrap program should be ready for the next stage of the installation process when the following message displays in bootstrap’s logs.
```
Created "99_openshift-cluster-api_master-user-data-secret.yaml" secrets.v1./master-user-data -n openshift-machine-api
```
When you see this message, go back to your KVM host system and run the next script to install the control nodes (formerly known as master nodes).

Step 2.3. Create the control plane nodes

$ cd /home/ocpuser/ocp_vms
$ ./2-make-master-vms.sh

When this script runs, it creates the VMs for the control nodes. The VMs do start automatically. To start the VMs, use the following command.
```
$ virsh start kvm1-master1
$ virsh start kvm1-master2
$ virsh start kvm1-master3
```
To monitor the installation process for the bootstrap, log in from your workstation to Bastion as the rhel user and become the root user to run the following command.

Example:
```
$ sudo su -
# ssh core@bootstrap.kvm1.user1.local
```
To access the bootstrap log file, run the following command.
```
$ journalctl -b -f -u bootkube.service
```
Note: It can take a few minutes for updates to show in this log file.
The control nodes are ready for the next stage of the installation process when the following message displays in the bootstrap’s logs.
```
bootkube.service complete
bootkube.service: Succeeded
```
Note: It can take 5-25 minutes to complete this step.
From this point forward, you can shut down the bootstrap guest VM. Run the following command from your KVM host system.
```
$ virsh destroy kvm1-bootstrap
```
Note: The virsh destroy command only shuts down the VM. If you need to erase the VM definition, run the # virsh undefine bootstrap command and erase the qcow file for the bootstrap at the /var/lib/libvirt/images directory.

To verify that the Red Hat OpenShift cluster has been formed, log on to your respective Bastion guest VM, and export the following shell variable.

# export KUBECONFIG=/root/ocp-install/ocp-deploy/auth/kubeconfig

# cd /root/ocp-install
# oc get nodes

Example:

# oc get nodes

NAME                       STATUS   ROLES    AGE   VERSION
master1.kvm1.user1.local   Ready    master   30mins   v1.23.5+012e945
master2.kvm1.user1.local   Ready    master   35mins   v1.23.5+012e945
master3.kvm1.user1.local   Ready    master   34mins   v1.23.5+012e945

Step 2.4. Create the compute plane nodes (worker nodes)

Log on to your appropriate KVM host system and run the next script to install the control nodes (formerly known as the master nodes).
```
# cd /home/l4root/ocp_vms
# ./3-make-worker-vms.sh
```
When this script runs, it creates the VMs for the control nodes. The VMs do start automatically. To start the VMs, run the following command.
```
$ virsh start kvm1-worker1
$ virsh start kvm1-worker2
$ virsh start kvm1-worker3
```

Step 2.5. Check for CSR requests

Log on to the appropriate Bastion guest VM.

Export the KUBECONFIG shell variable.

# export KUBECONFIG=/root/ocp-install/ocp-deploy/auth/kubeconfig

Run the following command to check for pending CSRs.

# oc get csr

Example:

NAME        AGE   REQUESTOR                           CONDITION
csr-2qwv8   106m  system:node:worker1…                 pending
csr-2sjrr   61m   system:node:worker2….                pending

Run the following command to approve pending CSRs.
```
# oc get csr | grep -i Pending | awk '{print $1}' | xargs oc adm certificate approve
```
Note: Do not proceed if you have pending CSRs.

Check whether all nodes have joined your Red Hat OpenShift cluster.

# oc get nodes
NAME                       STATUS   ROLES    AGE   VERSION
master1.kvm1.user1.local   Ready    master   40m   v1.23.5+012e945
master2.kvm1.user1.local   Ready    master   40m   v1.23.5+012e945
master3.kvm1.user1.local   Ready    master   40m   v1.23.5+012e945
worker1.kvm1.user1.local   Ready    worker   10m   v1.23.5+012e945
worker2.kvm1.user1.local   Ready    worker   10m   v1.23.5+012e945
worker3.kvm1.user1.local   Ready    worker   10m   v1.23.5+012e945

You need to wait for the Red Hat OpenShift Operators to finish their task. To check the progress of the Operators, run the following command.

Example:

# oc get co
NAME                              VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                     4.13.4   True        False         False      1h
baremetal                          4.13.4   True        False         False      1h
cloud-controller-manager           4.13.4   True        False         False      1h
cloud-credential                   4.13.4   True        False         False      1h
cluster-autoscaler                 4.13.4   True        False         False      1h
config-operator                    4.13.4   True        False         False      1h
console                            4.13.4   True        False         False      1h
csi-snapshot-controlle             4.13.4   True        False         False      1h
dns                                4.13.4   True        False         False      1h
etcd                               4.13.4   True        False         False      1h
…
service-ca                         4.13.4   True        False         False      1h
storage                            4.13.4   True        False         False      1h

Note: There are multiple Red Hat OpenShift Operators, and this task can take 15-20 minutes to complete. When the Available column displays all TRUE results, you have completed the Red Hat OpenShift Container Platform deployment.

Step 3. Access web UI

To access the web UI for Red Hat OpenShift, you use the kubeadmin login ID. To get the password for kubeadmin, complete the following steps.

Log on to your respective Bastion guest VM.

List the content of the kubeadmin-password from your ocp-deploy directory.

Example:

# cat /root/ocp-install/ocp-deploy/auth/kubeadmin-password
XH39i-pKkWK-9pkDo-g4PQi

To access the Red Hat OpenShift web UI, open a browser on your laptop or workstation and go to the web console.

Note: To access that Red Hat OpenShift Console URL from your workstation/laptop:

On Linux/MacOS: Edit the /etc/hosts file.

<bastion IP> console-openshift-console.apps.kvm1.user1.local
<bastion IP> oauth-openshift.apps.kvm1.user1.local
<bastion IP> api.kvm1.user1.local

On Windows OS: Edit the C:\Windows\System32\drivers\etc\hosts file.

<bastion IP> console-openshift-console.apps.kvm1.user1.local
<bastion IP> oauth-openshift.apps.kvm1.user1.local
<bastion IP> api.kvm1.user1.local

Example:

In your browser, go to: https://console-openshift-console.apps.kvm1.user1.local/.

Note: Use Username: kubeadmin.

Fig 7

Summary

You have completed all the steps to deploy the KVM, Red Hat OpenShift Container Platform, and Red Hat OpenShift Data Foundation. Let's take a moment to review you have completed. You have:

Installed all the required resources to enable KVM on your RHEL Host
Built the Bastion KVM guest system
Set up the DNS (Domain Name Service) in your Bastion system
Set up the HAProxy (Load Balancer) in your Bastion system
Set up the HTTPd server in your Bastion system
Prepared the infrastructure Red Hat OpenShift installation
Built all the VMs that will be part of the Red Hat OpenShift cluster
Deployed a Red Hat OpenShift Container Platform cluster

Next steps

This tutorial only covers the installation process. For stateful workloads, you will need to choose between the different options currently available, such as Red Hat Data Foundation, only available with Red Hat OpenShift Plus, IBM Fusion Data Foundation, or for nonproduction clusters, a simple external NFS server. But for now, you can take satisfaction in all the steps you've completed. Red Hat OpenShift 4 is ready to be explored.

Deploy Red Hat OpenShift Container Platform on IBM LinuxONE and Kernel-based Virtual Machine hypervisor

Deploy Red Hat OpenShift Container Platform on IBM LinuxONE and Kernel-based Virtual Machine hypervisor