Generate install-config.yaml and agent-config.yaml for a compact,
user-provisioned OpenShift cluster.
Use this guide to decide the best OpenShift installation path before filling full cluster details.
Use the choices on the right to pick where you install and who provisions the machines. Then get a recommended method and platform before you fill in cluster details.
You provide hosts/VMs and networking (DNS, load balancers).
Installer creates machines (needs platform credentials).
If you are new to OpenShift, review this checklist before you run the installer. Choose the scenario that best matches your environment.
For full details and supported topologies, refer to the official OpenShift bare metal and virtualization install documentation.
Enterprises often block Assisted / connected installs because firewall teams must whitelist many Red Hat endpoints. A dedicated mirror registry lets you pull once from the internet on a bastion, then install the cluster from an internal registry only.
This guide follows Red Hat’s mirror registry for Red Hat OpenShift (a small Quay-based appliance included with an OpenShift subscription). It is for bootstrapping disconnected clusters — not a HA production Quay.
mirror.example.com)podman installed; SSH access if installing to a remote hostoc-mirrormirror-registry from the
OpenShift console Downloads
page (included with your subscription), or from the
quay/mirror-registry releases.
./mirror-registry is executable.Replace the hostname and install directory with your values:
./mirror-registry install \ --quayHostname mirror.example.com \ --quayRoot $HOME/quay-install
The installer creates local storage/config under --quayRoot, systemd units for persistence, and an
initial user named init with a generated password (printed at the end — save it).
./mirror-registry install -v \ --targetHostname mirror.example.com \ --targetUsername someuser \ --ssh-key ~/.ssh/id_rsa \ --quayHostname mirror.example.com \ --quayRoot /home/someuser/quay-install
Prefer trusting the generated root CA long term. For a first smoke test you can use
--tls-verify=false (not recommended permanently):
podman login -u init \ -p '<password-from-install>' \ mirror.example.com:8443 \ --tls-verify=false
UI: https://mirror.example.com:8443. Add the registry CA to this app’s
additionalTrustBundle placeholder later when you generate install-config.yaml.
registry.redhat.io and to your mirror.operator-mirror-config.yaml this app generates
(day-2 OperatorHub — not required to bring the cluster up).
ImageContentSourcePolicy / mirror mappings into your install config
(this app provides placeholders under Disconnected).If you already run Quay, Harbor, Artifactory, Nexus, or another Docker v2-2 registry reachable from the cluster, you can skip installing the appliance. Point “Mirror registry host” at that registry and trust its CA. The rest of the oc-mirror workflow is the same.
Operator packages are not required to install the cluster (you still must mirror the OpenShift release payload). Packages below are recommended day-2 OperatorHub content for typical disconnected UPI / on-prem environments. Adjust the multi-select freely.
Sensitive value: you can add or update this later in generated install-config.yaml.
Sensitive value: you can add or update this later in generated install-config.yaml.
Use this page to sketch concrete DNS, VIP, and firewall values for your environment. Examples are dummy values — replace them with your own.
| Name | Type | Value | Purpose |
|---|---|---|---|
| api.ocp4.lab.example.com | A | 192.168.50.5 | API VIP (port 6443) |
| api-int.ocp4.lab.example.com | A | 192.168.50.5 | Internal API / machine config (22623) |
| *.apps.ocp4.lab.example.com | Wildcard | 192.168.50.6 | Ingress VIP (80/443) |
| master-0.ocp4.lab.example.com | A | 192.168.50.10 | Control plane node 1 |
| master-1.ocp4.lab.example.com | A | 192.168.50.11 | Control plane node 2 |
| master-2.ocp4.lab.example.com | A | 192.168.50.12 | Control plane node 3 |
| worker-0.ocp4.lab.example.com | A | 192.168.50.20 | Worker node 1 |
| worker-1.ocp4.lab.example.com | A | 192.168.50.21 | Worker node 2 |
| LB FQDN | VIP | Ports | Backends (example nodes) |
|---|---|---|---|
| api.ocp4.lab.example.com | 192.168.50.5 | 6443 | master-0, master-1, master-2 |
| api-int.ocp4.lab.example.com | 192.168.50.5 | 22623 | master-0, master-1, master-2 |
| *.apps.ocp4.lab.example.com | 192.168.50.6 | 80, 443 | worker-0, worker-1 |
| Source | Destination | Port/Protocol | Reason |
|---|---|---|---|
| Admins / automation | api.ocp4.lab.example.com | 6443/TCP | Kubernetes API access |
| Cluster nodes | api-int.ocp4.lab.example.com | 22623/TCP | Machine config server |
| Users / browsers | *.apps.ocp4.lab.example.com | 80,443/TCP | App and console ingress |
In a lab, the bastion VM often provides DNS, NTP, HTTPD, proxy, and HAProxy VIPs. These examples assume a single vSphere or KVM environment.
| Name | Type | Value | Purpose |
|---|---|---|---|
| api.ocp4.lab.example.com | A | 192.168.50.5 | API VIP on bastion HAProxy |
| api-int.ocp4.lab.example.com | A | 192.168.50.5 | Internal API / machine config |
| *.apps.ocp4.lab.example.com | Wildcard | 192.168.50.6 | Ingress VIP on bastion HAProxy |
| master-0.ocp4.lab.example.com | A | 192.168.50.10 | Control plane node 1 |
| master-1.ocp4.lab.example.com | A | 192.168.50.11 | Control plane node 2 |
| master-2.ocp4.lab.example.com | A | 192.168.50.12 | Control plane node 3 |
| worker-0.ocp4.lab.example.com | A | 192.168.50.20 | Worker node 1 |
| worker-1.ocp4.lab.example.com | A | 192.168.50.21 | Worker node 2 |
| LB FQDN | VIP | Ports | Backends (example nodes) |
|---|---|---|---|
| api.ocp4.lab.example.com | 192.168.50.5 | 6443 | master-0, master-1, master-2 |
| api-int.ocp4.lab.example.com | 192.168.50.5 | 22623 | master-0, master-1, master-2 |
| *.apps.ocp4.lab.example.com | 192.168.50.6 | 80, 443 | worker-0, worker-1 |
| Source | Destination | Port/Protocol | Reason |
|---|---|---|---|
| Bastion / admin host | api.ocp4.lab.example.com | 6443/TCP | Install and `oc` API connectivity |
| Nodes | api-int.ocp4.lab.example.com | 22623/TCP | Machine config during bootstrapping |
| Workstation users | *.apps.ocp4.lab.example.com | 80,443/TCP | Console and application ingress |
These examples are for learning labs only. For supported configurations and full port lists, always refer to the official OpenShift installation and firewall documentation.
Platform-specific install details for the platform chosen in Installation profile (vSphere, Nutanix, AWS, or Azure). Bare Metal (none) has nothing to configure here and this step is skipped automatically when you use Next/Back.
Bare Metal (none) selected: no platform credentials or cloud settings are required. Use Next to continue.
vSphere and Nutanix
AWS and Azure
For a compact cluster, define three master hosts and zero workers.
| Hostname | Role | IP | MAC | Primary NIC | Bond? | Secondary NIC | Secondary MAC | Static IP? | Gateway | DNS servers (comma) |
|---|
Required for agent-based installs. Optional for UPI/IPI.
Compact cluster, bare metal / agent-based
After generating YAML:
install-config.yaml and (if present) agent-config.yaml to a working directory.imageContentSources, additionalTrustBundle, and
operator-mirror-config.yaml with oc-mirror /
oc adm release mirror to mirror content to your internal registry.
openshift-install agent create image --dir . in that directory to
create a discovery ISO.
Copy these commands and run them on your jump host / workstation as indicated.