--- title: Preparing for image-based installation for single-node OpenShift clusters --- # Preparing for image-based installation for single-node OpenShift clusters {#ibi-preparing-for-image-based-install} To prepare for an image-based installation for single-node OpenShift clusters, you must complete the following tasks: - Create a seed image by using the Lifecycle Agent. - Verify that all software components meet the required versions. For further information, see "Software prerequisites for an image-based installation and deployment". **Additional resources** {._additional-resources} - [Software prerequisites for an image-based installation and deployment](/openshift-docs-markdown/edge_computing/image_base_install/ibi-understanding-image-based-install#ztp-image-based-upgrade-prereqs_ibi-understanding-image-based-install) ## Installing the Lifecycle Agent {#_installing_the_lcao ._additional-resources} Use the Lifecycle Agent to generate a seed image from a seed cluster. You can install the Lifecycle Agent using the OpenShift CLI (`oc`) or the web console. ### Installing the Lifecycle Agent by using the CLI {#cnf-image-based-upgrade-installing-lifecycle-agent-using-cli_ibi-preparing-image-based-install} You can use the OpenShift CLI (`oc`) to install the Lifecycle Agent. **Prerequisites** - You have installed the OpenShift CLI (`oc`). - You have logged in as a user with `cluster-admin` privileges. **Procedure** 1. Create a `Namespace` object YAML file for the Lifecycle Agent: ```yaml apiVersion: v1 kind: Namespace metadata: name: openshift-lifecycle-agent annotations: workload.openshift.io/allowed: management ``` 1. Create the `Namespace` CR by running the following command: ```terminal $ oc create -f .yaml ``` 2. Create an `OperatorGroup` object YAML file for the Lifecycle Agent: ```yaml apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-lifecycle-agent namespace: openshift-lifecycle-agent spec: targetNamespaces: - openshift-lifecycle-agent ``` 1. Create the `OperatorGroup` CR by running the following command: ```terminal $ oc create -f .yaml ``` 3. Create a `Subscription` CR for the Lifecycle Agent: ```yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-lifecycle-agent-subscription namespace: openshift-lifecycle-agent spec: channel: "stable" name: lifecycle-agent source: redhat-operators sourceNamespace: openshift-marketplace ``` 1. Create the `Subscription` CR by running the following command: ```terminal $ oc create -f .yaml ``` **Verification** 1. To verify that the installation succeeded, inspect the CSV resource by running the following command: ```terminal $ oc get csv -n openshift-lifecycle-agent ``` Example output: ```terminal NAME DISPLAY VERSION REPLACES PHASE lifecycle-agent.v4.22.0 Openshift Lifecycle Agent 4.22.0 Succeeded ``` 2. Verify that the Lifecycle Agent is up and running by running the following command: ```terminal $ oc get deploy -n openshift-lifecycle-agent ``` Example output: ```terminal NAME READY UP-TO-DATE AVAILABLE AGE lifecycle-agent-controller-manager 1/1 1 1 14s ``` ### Installing the Lifecycle Agent by using the web console {#cnf-image-based-upgrade-installing-lifecycle-agent-using-web-console_ibi-preparing-image-based-install} You can use the OpenShift Container Platform web console to install the Lifecycle Agent. **Prerequisites** - You have logged in as a user with `cluster-admin` privileges. **Procedure** 1. In the OpenShift Container Platform web console, navigate to **Ecosystem** → **Software Catalog**. 2. Search for the **Lifecycle Agent** from the list of available Operators, and then click **Install**. 3. On the **Install Operator** page, under **A specific namespace on the cluster** select **openshift-lifecycle-agent**. 4. Click **Install**. **Verification** 1. To confirm that the installation is successful: 1. Click **Ecosystem** → **Installed Operators**. 2. Ensure that the Lifecycle Agent is listed in the **openshift-lifecycle-agent** project with a **Status** of **InstallSucceeded**. > [!NOTE] > During installation an Operator might display a **Failed** status. If the installation later succeeds with an **InstallSucceeded** message, you can ignore the **Failed** message. If the Operator is not installed successfully: 1. Click **Ecosystem** → **Installed Operators**, and inspect the **Operator Subscriptions** and **Install Plans** tabs for any failure or errors under **Status**. 2. Click **Workloads** → **Pods**, and check the logs for pods in the **openshift-lifecycle-agent** project. ## Configuring a shared container partition between ostree stateroots {#cnf-image-based-upgrade-shared-container-partition_ibi-preparing-image-based-install} > [!IMPORTANT] > You must complete this procedure at installation time. Apply a `MachineConfig` to the seed cluster to create a separate partition and share the `/var/lib/containers` partition between the two `ostree` stateroots that will be used during the preinstall process. **Procedure** - Apply a `MachineConfig` to create a separate partition: ```yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 98-var-lib-containers-partitioned spec: config: ignition: version: 3.2.0 storage: disks: - device: /dev/disk/by-path/ partitions: - label: var-lib-containers startMiB: sizeMiB: filesystems: - device: /dev/disk/by-partlabel/var-lib-containers format: xfs mountOptions: - defaults - prjquota path: /var/lib/containers wipeFilesystem: true systemd: units: - contents: |- # Generated by Butane [Unit] Before=local-fs.target Requires=systemd-fsck@dev-disk-by\x2dpartlabel-var\x2dlib\x2dcontainers.service After=systemd-fsck@dev-disk-by\x2dpartlabel-var\x2dlib\x2dcontainers.service [Mount] Where=/var/lib/containers What=/dev/disk/by-partlabel/var-lib-containers Type=xfs Options=defaults,prjquota [Install] RequiredBy=local-fs.target enabled: true name: var-lib-containers.mount ``` where: `` : Specifies the root disk, for example `pci-0000:01:00.0-scsi-0:2:0:0`. `` : Specifies the start of the partition in MiB. If the value is too small, the installation will fail. `` : Specifies a minimum size for the partition of 500 GB (512000 MiB) to ensure adequate disk space for precached images. If the value is too small, the deployments after installation will fail. ## Seed image configuration {#cnf-image-based-upgrade-seed-image-config_ibi-preparing-image-based-install} You can create a seed image from a single-node OpenShift cluster with the same hardware as your bare-metal host, and with a similar target cluster configuration. However, the seed image generated from the seed cluster cannot contain any cluster-specific configuration. The following table lists the components, resources, and configurations that you must and must not include in your seed image: **Seed image configuration**
Cluster configuration Include in seed image
Performance profile Yes
MachineConfig resources for the target cluster Yes
IP version configuration, either IPv4, IPv6, or dual-stack networking Yes
Set of Day 2 Operators, including the Lifecycle Agent and the OADP Operator Yes
Disconnected registry configuration [2] Yes
Valid proxy configuration [3] Yes
FIPS configuration Yes
Dedicated partition on the primary disk for container storage that matches the size of the target clusters Yes
Local volumes

  • StorageClass used in LocalVolume for LSO
  • LocalVolume for LSO
  • LVMCluster CR for LVMS
 No
1. If the seed cluster is installed in a disconnected environment, the target clusters must also be installed in a disconnected environment. 2. The proxy configuration must be either enabled or disabled in both the seed and target clusters. However, the proxy servers configured on the clusters does not have to match. ### Seed image configuration using the RAN DU profile {#ztp-image-based-upgrade-seed-image-config-ran_ibi-preparing-image-based-install} The following table lists the components, resources, and configurations that you must and must not include in the seed image when using the RAN DU profile: **Seed image configuration with RAN DU profile** | Resource | Include in seed image | | --- | --- | | All extra manifests that are applied as part of Day 0 installation | Yes | | All Day 2 Operator subscriptions | Yes | | `DisableOLMPprof.yaml` | Yes | | `TunedPerformancePatch.yaml` | Yes | | `PerformanceProfile.yaml` | Yes | | `SriovOperatorConfig.yaml` | Yes | | `DisableSnoNetworkDiag.yaml` | Yes | | `StorageClass.yaml` | No, if it is used in `StorageLV.yaml` | | `StorageLV.yaml` | No | | `StorageLVMCluster.yaml` | No | | `SriovFecClusterConfig.yaml` | No | | `SriovVrbClusterConfig.yaml` | No | The following list of resources and configurations can be applied as extra manifests or by using RHACM policies: - `ClusterLogForwarder.yaml` - `ReduceMonitoringFootprint.yaml` - `PtpOperatorConfigForEvent.yaml` - `DefaultCatsrc.yaml` - `PtpConfig.yaml` - `SriovNetwork.yaml` > [!IMPORTANT] > If you are using GitOps ZTP, enable these resources by using RHACM policies to ensure configuration changes can be applied throughout the cluster lifecycle. ## Generating a seed image with the Lifecycle Agent {#cnf-image-based-upgrade-generate-seed-image_ibi-preparing-image-based-install} Use the Lifecycle Agent to generate a seed image from a managed cluster. The Operator checks for required system configurations, performs any necessary system cleanup before generating the seed image, and launches the image generation. The seed image generation includes the following tasks: - Stopping cluster Operators - Preparing the seed image configuration - Generating and pushing the seed image to the image repository specified in the `SeedGenerator` CR - Restoring cluster Operators - Expiring seed cluster certificates - Generating new certificates for the seed cluster - Restoring and updating the `SeedGenerator` CR on the seed cluster **Prerequisites** - RHACM and multicluster engine for Kubernetes Operator are not installed on the seed cluster. - You have configured a shared container directory on the seed cluster. - You have installed the minimum version of the OADP Operator and the Lifecycle Agent on the seed cluster. - Ensure that persistent volumes are not configured on the seed cluster. - Ensure that the `LocalVolume` CR does not exist on the seed cluster if the Local Storage Operator is used. - Ensure that the `LVMCluster` CR does not exist on the seed cluster if LVM Storage is used. - Ensure that the `DataProtectionApplication` CR does not exist on the seed cluster if OADP is used. **Procedure** 1. Detach the managed cluster from the hub to delete any RHACM-specific resources from the seed cluster that must not be in the seed image: 1. Manually detach the seed cluster by running the following command: ```terminal $ oc delete managedcluster sno-worker-example ``` 1. Wait until the managed cluster is removed. After the cluster is removed, create the proper `SeedGenerator` CR. The Lifecycle Agent cleans up the RHACM artifacts. 2. If you are using GitOps ZTP, detach your cluster by removing the seed cluster’s `ClusterInstance` CR from the `kustomization.yaml`. 1. If you have a `kustomization.yaml` file that references multiple `ClusterInstance` CRs, remove your seed cluster’s `ClusterInstance` CR from the `kustomization.yaml`: ```yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: #- clusterinstance-seed-sno1.yaml - clusterinstance-target-sno2.yaml - clusterinstance-target-sno3.yaml ``` 2. If you have a `kustomization.yaml` that references one `ClusterInstance` CR, remove your seed cluster’s `ClusterInstance` CR from the `kustomization.yaml` and add the `resources: []` line: ```yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: [] ``` 3. Commit the `kustomization.yaml` changes in your Git repository and push the changes to your repository. The ArgoCD pipeline detects the changes and removes the managed cluster. 2. Create the `Secret` object so that you can push the seed image to your registry. 1. Create the authentication file by running the following commands: ```terminal $ MY_USER=myuserid ``` ```terminal $ AUTHFILE=/tmp/my-auth.json ``` ```terminal $ podman login --authfile ${AUTHFILE} -u ${MY_USER} quay.io/${MY_USER} ``` ```terminal $ base64 -w 0 ${AUTHFILE} ; echo ``` 2. Copy the output into the `seedAuth` field in the `Secret` YAML file named `seedgen` in the `openshift-lifecycle-agent` namespace: ```yaml apiVersion: v1 kind: Secret metadata: name: namespace: openshift-lifecycle-agent type: Opaque data: seedAuth: ``` where: `` : Specifies the name of the `Secret` resource. The value must be `seedgen`. `` : Specifies a base64-encoded authfile for write-access to the registry for pushing the generated seed images. 3. Apply the `Secret` by running the following command: ```terminal $ oc apply -f secretseedgenerator.yaml ``` 3. Create the `SeedGenerator` CR: ```yaml apiVersion: lca.openshift.io/v1 kind: SeedGenerator metadata: name: spec: seedImage: ``` where: `` : Specifies the name of the `SeedGenerator` CR. The value must be `seedimage`. `` : Specifies the container image URL, for example, `quay.io/example/seed-container-image:`. It is recommended to use the `:` format. 4. Generate the seed image by running the following command: ```terminal $ oc apply -f seedgenerator.yaml ``` > [!IMPORTANT] > The cluster reboots and loses API capabilities while the Lifecycle Agent generates the seed image. Applying the `SeedGenerator` CR stops the `kubelet` and the CRI-O operations, then it starts the image generation. **Verification** - After the cluster recovers and it is available, you can check the status of the `SeedGenerator` CR by running the following command: ```terminal $ oc get seedgenerator -o yaml ``` The following example shows the output when the seed image generation is complete: ```yaml status: conditions: - lastTransitionTime: "2024-02-13T21:24:26Z" message: Seed Generation completed observedGeneration: 1 reason: Completed status: "False" type: SeedGenInProgress - lastTransitionTime: "2024-02-13T21:24:26Z" message: Seed Generation completed observedGeneration: 1 reason: Completed status: "True" type: SeedGenCompleted observedGeneration: 1 ``` The `SeedGenCompleted` type indicates that the seed image generation is complete. > [!IMPORTANT] > After the seed image generation completes, do not use the seed cluster. Do not continue to run `oc` commands against the seed cluster or use it to manage managed clusters. > > If you access the seed cluster after generating the seed image, you can meet TLS certificate validation errors because the seed cluster certificates expire during seed image generation. If you need to generate another seed image, provision a new seed cluster.