openshift · JoeAldinger · Aug 3, 2026 · ocpdocs-vale-bot · Aug 3, 2026 · ocpdocs-vale-bot
diff --git a/hardware_enablement/kmm-kernel-module-management.adoc b/hardware_enablement/kmm-kernel-module-management.adoc
@@ -6,7 +6,8 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-Learn about the Kernel Module Management (KMM) Operator and how you can use it to deploy out-of-tree kernel modules and device plugins on {product-title} clusters.
+[role="_abstract"]
+The Kernel Module Management (KMM) Operator deploys out-of-tree kernel modules and device plugins on {product-title} clusters. You can use KMM to build, load, and manage kernel modules across cluster lifecycle stages.
 
 :FeatureName: Kernel Module Management Operator
 

diff --git a/modules/kmm-about-kmm.adoc b/modules/kmm-about-kmm.adoc
@@ -6,9 +6,9 @@
 [id="about-kmm_{context}"]
 = About the Kernel Module Management Operator
 
-The Kernel Module Management (KMM) Operator manages, builds, signs, and deploys out-of-tree kernel modules and device plugins on {product-title} clusters.
+[role="_abstract"]
+The Kernel Module Management (KMM) Operator on {product-title} manages the full lifecycle of out-of-tree kernel modules and device plugins, from build and signing through deployment.
+You can use `Module` custom resources to define module loaders, device plugins, and version-specific build instructions across kernel upgrades.
 
 KMM adds a new `Module` CRD which describes an out-of-tree kernel module and its associated device plugin.
-You can use `Module` resources to configure how to load the module, define `ModuleLoader` images for kernel versions, and include instructions for building and signing modules for specific kernel versions.
-
-KMM is designed to accommodate multiple kernel versions at once for any kernel module, allowing for seamless node upgrades and reduced application downtime.
+You can use `Module` resources to configure how to load the module, define `ModuleLoader` images for kernel versions, and include instructions for building and signing modules for specific kernel versions.
diff --git a/modules/kmm-adding-the-keys-for-secureboot.adoc b/modules/kmm-adding-the-keys-for-secureboot.adoc
@@ -6,7 +6,10 @@
 [id="kmm-adding-the-keys-for-secureboot_{context}"]
 = Adding the keys for secureboot
 
-To use KMM Kernel Module Management (KMM) to sign kernel modules, a certificate and private key are required. For details on how to create these, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/signing-a-kernel-and-modules-for-secure-boot_managing-monitoring-and-updating-the-kernel#generating-a-public-and-private-key-pair_signing-a-kernel-and-modules-for-secure-boot[Generating a public and private key pair].
+[role="_abstract"]
+To sign kernel modules with Kernel Module Management (KMM) on {product-title}, you can add Secure Boot certificate and private key files as Kubernetes secrets.
+
+For details on how to create these, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/signing-a-kernel-and-modules-for-secure-boot_managing-monitoring-and-updating-the-kernel#generating-a-public-and-private-key-pair_signing-a-kernel-and-modules-for-secure-boot[Generating a public and private key pair].
 
 For details on how to extract the public and private key pair, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/signing-a-kernel-and-modules-for-secure-boot_managing-monitoring-and-updating-the-kernel#signing-kernel-modules-with-the-private-key_signing-a-kernel-and-modules-for-secure-boot[Signing kernel modules with the private key]. Use steps 1 through 4 to extract the keys into files.
 

diff --git a/modules/kmm-applying-tolerations-to-kernel-module-pods.adoc b/modules/kmm-applying-tolerations-to-kernel-module-pods.adoc
@@ -6,6 +6,9 @@
 [id="kmm-applying-tolerations-to-kernel-module-pods_{context}"]
 = Applying tolerations to kernel module pods 
 
+[role="_abstract"]
+Kernel module pods in {product-title} can tolerate node taints so KMM schedules them on designated nodes. You can configure toleration parameters in the `Module` custom resource to match taint effects, keys, and values on target nodes.
+
 Taints and tolerations consist of `effect`, `key`, and `value` parameters. Tolerations include additional `operator` and `tolerationSeconds` parameters. 
 
 `effect`:: Indicates the taint effect to match. If left empty, all taint effects are matched. When you set `effect`, valid values are: `NoSchedule`, `PreferNoSchedule`, or `NoExecute`.

diff --git a/modules/kmm-building-a-kmod-image.adoc b/modules/kmm-building-a-kmod-image.adoc
@@ -6,6 +6,9 @@
 [id="kmm-building-a-kmod-image_{context}"]
 = Building a kmod image
 
+[role="_abstract"]
+To build a kmod image with firmware support in {product-title}, you can include the binary firmware in the builder image alongside the kernel module.
+
 .Procedure
 
 * In addition to building the kernel module itself, include the binary firmware in the builder image:

diff --git a/modules/kmm-building-and-signing-a-kmod-image.adoc b/modules/kmm-building-and-signing-a-kmod-image.adoc
@@ -6,7 +6,8 @@
 [id="kmm-building-and-signing-a-kmod-image_{context}"]
 = Building and signing a kmod image
 
-Use this procedure if you have source code and must build your image first.
+[role="_abstract"]
+To build and sign a kmod image from source code on {product-title}, you can apply a `Module` custom resource that builds an unsigned image and then signs it with your key and certificate secrets.
 
 The following YAML file builds a new container image using the source code from the repository. The image produced is saved back in the registry with a temporary name, and this temporary image is then signed using the parameters in the `sign` section.
 

diff --git a/modules/kmm-building-in-cluster.adoc b/modules/kmm-building-in-cluster.adoc
@@ -7,7 +7,8 @@
 
 = Building in the cluster
 
-KMM can build kmod images in the cluster. Follow these guidelines:
+[role="_abstract"]
+Kernel Module Management (KMM) can build kmod container images in the cluster on {product-title} when the image does not already exist in the registry. You configure in-cluster builds through the `build` section of a kernel mapping in the `Module` CR.
 
 * Provide build instructions using the `build` section of a kernel mapping.
 * Copy the Dockerfile for your container image into a `ConfigMap` resource, under the `dockerfile` key.

diff --git a/modules/kmm-checking-the-keys.adoc b/modules/kmm-checking-the-keys.adoc
@@ -6,7 +6,8 @@
 [id="kmm-checking-the-keys_{context}"]
 = Checking the keys
 
-After you have added the keys, you must check them to ensure they are set correctly.
+[role="_abstract"]
+To verify that your secure boot signing keys are configured correctly in {product-title}, you can inspect the public certificate and private key secrets with the OpenShift CLI.
 
 .Procedure
 

diff --git a/modules/kmm-configuring-kmmo.adoc b/modules/kmm-configuring-kmmo.adoc
@@ -6,7 +6,8 @@
 [id="kmm-configuring-kmmo_{context}"]
 = Configuring the Kernel Module Management Operator
 
-In most cases, the default configuration for the Kernel Module Management (KMM) Operator does not need to be modified. However, you can modify the Operator settings to suit your environment.
+[role="_abstract"]
+To adapt the Kernel Module Management (KMM) Operator to your {product-title} environment, you can create a `ConfigMap` with custom settings and restart the controller.
 
 .Procedure
 

diff --git a/modules/kmm-configuring-the-lookup-path-on-nodes.adoc b/modules/kmm-configuring-the-lookup-path-on-nodes.adoc
@@ -6,6 +6,9 @@
 [id="kmm-configuring-the-lookup-path-on-nodes_{context}"]
 = Configuring the lookup path on nodes
 
+[role="_abstract"]
+To add `/var/lib/firmware` to the kernel firmware lookup path on {product-title} nodes, you can create a `MachineConfig` custom resource that sets the `firmware_class.path` kernel argument.
+
 On {product-title} nodes, the set of default lookup paths for firmwares does not include the `/var/lib/firmware` path.
 
 .Procedure

diff --git a/modules/kmm-creating-kmod-image.adoc b/modules/kmm-creating-kmod-image.adoc
@@ -6,8 +6,8 @@
 [id="kmm-creating-kmod-image_{context}"]
 = Creating a kmod image
 
-Kernel Module Management (KMM) works with purpose-built kmod images, which are standard OCI images that contain `.ko` files.
-The location of the `.ko` files must match the following pattern: `<prefix>/lib/modules/[kernel-version]/`.
+[role="_abstract"]
+A kmod image is a standard OCI container image that holds `.ko` kernel module files for use with Kernel Module Management (KMM) on {product-title}. You must place `.ko` files under a path that matches `<prefix>/lib/modules/[kernel-version]/`.
 
 Keep the following in mind when working with the `.ko` files:
 

diff --git a/modules/kmm-creating-module-cr.adoc b/modules/kmm-creating-module-cr.adoc
@@ -7,7 +7,8 @@
 
 = The Module custom resource definition
 
-The `Module` custom resource definition (CRD) represents a kernel module that can be loaded on all or select nodes in the cluster, through a kmod image. A `Module` custom resource (CR) specifies one or more kernel versions with which it is compatible, and a node selector.
+[role="_abstract"]
+The `Module` custom resource in {product-title} defines an out-of-tree kernel module and the nodes where KMM loads it. KMM reconciles each `Module` by matching kernel versions, building or signing images when needed, and deploying module loader and device plugin workloads.
 
 The compatible versions for a `Module` resource are listed under `.spec.moduleLoader.container.kernelMappings`. A kernel mapping can either match a `literal` version, or use `regexp` to match many of them at the same time.
 

diff --git a/modules/kmm-day0-day2-installation.adoc b/modules/kmm-day0-day2-installation.adoc
@@ -6,7 +6,8 @@
 [id="kmm-day0-day2-installation_{context}"]
 = Day 0 through Day 2 kmod installation
 
-You can install some kernel modules (kmods) during Day 0 through Day 2 operations without Kernel Module Management (KMM). This could assist in the transition of the kmods to KMM.
+[role="_abstract"]
+Day 0 through Day 2 kernel module (kmod) installation describes when you can load kmods outside Kernel Module Management (KMM) on {product-title}. You can use these stages to plan kmod transitions to KMM.
 
 Use the following criteria to determine suitable kmod installations.
 

diff --git a/modules/kmm-day0-day2-lifecycle-management.adoc b/modules/kmm-day0-day2-lifecycle-management.adoc
@@ -6,7 +6,9 @@
 [id="kmm-day0-day2-lifecycle-management_{context}"]
 = Lifecycle management
 
-You can leverage KMM to manage the Day 0 through Day 2 lifecycle of kmods without a reboot when the driver allows it.
+[role="_abstract"]
+KMM lifecycle management on {product-title} lets you upgrade kmods from Day 0 through Day 2 without rebooting nodes when the driver supports it.
+You can treat kmods as in-tree drivers or use ordered upgrade to control rollout pace and minimize downtime.
 
 [NOTE]
 ====

diff --git a/modules/kmm-day1-in-tree-module-replacement.adoc b/modules/kmm-day1-in-tree-module-replacement.adoc
@@ -6,4 +6,5 @@
 [id="kmm-day1-in-tree-module-replacement_{context}"]
 = In-tree module replacement
 
-The Day 1 functionality always tries to replace the in-tree kernel module with the OOT version. If the in-tree kernel module is not loaded, the flow is not affected; the service proceeds and loads the OOT kernel module.
+[role="_abstract"]
+Day 1 kernel module loading in {product-title} replaces in-tree kernel modules with out-of-tree (OOT) versions when present. If the in-tree module is not loaded, KMM loads the OOT module without affecting the flow.
diff --git a/modules/kmm-day1-kernel-module-image.adoc b/modules/kmm-day1-kernel-module-image.adoc
@@ -6,4 +6,7 @@
 [id="kmm-day1-kernel-module-image_{context}"]
 = The kernel module image
 
-The Day 1 functionality uses the same DTK based image leveraged by Day 2 KMM builds. The out-of-tree kernel module should be located under `/opt/lib/modules/${kernelVersion}`.
+[role="_abstract"]
+Day 1 kernel module loading in {product-title} uses Driver Toolkit-based container images shared with Day 2 KMM builds. These images must contain your out-of-tree kernel modules so the Machine Config Operator can pull and load them during node boot.
+
+The out-of-tree kernel module should be located under `/opt/lib/modules/${kernelVersion}`.
diff --git a/modules/kmm-day1-kernel-module-loading.adoc b/modules/kmm-day1-kernel-module-loading.adoc
@@ -6,4 +6,5 @@
 [id="kmm-day1-kernel-module-loading_{context}"]
 = Day 1 kernel module loading
 
-Kernel Module Management (KMM) is typically a Day 2 Operator. Kernel modules are loaded only after the complete initialization of a Linux (RHCOS) server. However, in some scenarios the kernel module must be loaded at an earlier stage. Day 1 functionality allows you to use the Machine Config Operator (MCO) to load kernel modules during the Linux `systemd` initialization stage.
+[role="_abstract"]
+Day 1 kernel module loading lets you insert kernel modules during Linux `systemd` initialization on {product-title}, before standard KMM Day 2 loading. You can use the Machine Config Operator (MCO) when a module must load earlier than full node initialization.
diff --git a/modules/kmm-day1-machineconfigpool.adoc b/modules/kmm-day1-machineconfigpool.adoc
@@ -6,7 +6,9 @@
 [id="kmm-day1-machineconfigpool_{context}"]
 = The MachineConfigPool
 
-The `MachineConfigPool` identifies a collection of nodes that are affected by the applied MCO.
+[role="_abstract"]
+A `MachineConfigPool` identifies a collection of {product-title} nodes affected by Machine Config Operator changes.
+You use it to target `MachineConfig` resources to specific node groups such as workers or masters.
 
 [source,yaml]
 ----

diff --git a/modules/kmm-day1-mco-yaml-creation.adoc b/modules/kmm-day1-mco-yaml-creation.adoc
@@ -6,7 +6,8 @@
 [id="kmm-day1-mco-yaml-creation_{context}"]
 = MCO yaml creation
 
-KMM provides an API to create an MCO YAML manifest for the Day 1 functionality:
+[role="_abstract"]
+Kernel Module Management (KMM) exposes a `ProduceMachineConfig` API that generates Machine Config Operator (MCO) YAML for Day 1 out-of-tree kernel module loading on {product-title}. You apply the returned manifest to target nodes in a specified `MachineConfigPool`.
 
 [source,console]
 ----

diff --git a/modules/kmm-day1-oot-kernel-module-loading-flow.adoc b/modules/kmm-day1-oot-kernel-module-loading-flow.adoc
@@ -6,7 +6,8 @@
 [id="kmm-day1-oot-kernel-module-loading-flow_{context}"]
 = OOT kernel module loading flow
 
-The loading of the out-of-tree (OOT) kernel module leverages the Machine Config Operator (MCO). The flow sequence is as follows:
+[role="_abstract"]
+To load an out-of-tree kernel module during {product-title} node boot, you can apply a `MachineConfig` through the Machine Config Operator (MCO). MCO reboots nodes and deploys `systemd` services that pull the kernel module image and swap in-tree modules for OOT modules.
 
 .Procedure
 

diff --git a/modules/kmm-day1-supported-use-cases.adoc b/modules/kmm-day1-supported-use-cases.adoc
@@ -6,7 +6,8 @@
 [id="kmm-day1-supported-use-cases_{context}"]
 = Day 1 supported use cases
 
-The Day 1 functionality supports a limited number of use cases. The main use case is to allow loading out-of-tree (OOT) kernel modules prior to NetworkManager service initialization. It does not support loading kernel module at the `initramfs` stage.
+[role="_abstract"]
+Day 1 supported use cases define when {product-title} can load out-of-tree (OOT) kernel modules before NetworkManager starts. This functionality does not support loading modules during the `initramfs` stage.
 
 The following are the conditions needed for Day 1 functionality:
 

diff --git a/modules/kmm-debugging-and-troubleshooting.adoc b/modules/kmm-debugging-and-troubleshooting.adoc
@@ -6,7 +6,11 @@
 [id="kmm-debugging-and-troubleshooting_{context}"]
 = Debugging and troubleshooting
 
-If the kmods in your driver container are not signed or are signed with the wrong key, then the container can enter a `PostStartHookError` or `CrashLoopBackOff` status. You can verify by running the `oc describe` command on your container, which displays the following message in this scenario:
+[role="_abstract"]
+Unsigned or incorrectly signed kmods in KMM driver containers on {product-title} can cause `PostStartHookError` or `CrashLoopBackOff` states.
+You can verify signing issues by running `oc describe` on the container and checking for a `Required key not available` error.
+
+The following message appears in this scenario:
 
 [source,terminal]
 ----

diff --git a/modules/kmm-deploying-modules.adoc b/modules/kmm-deploying-modules.adoc
@@ -6,7 +6,8 @@
 [id="kmm-deploy-kernel-modules_{context}"]
 = Kernel module deployment
 
-Kernel Module Management (KMM) monitors `Node` and `Module` resources in the cluster to determine if a kernel module should be loaded on or unloaded from a node.
+[role="_abstract"]
+Kernel Module Management (KMM) monitors `Node` and `Module` resources on {product-title} to load or unload kernel modules on eligible nodes. KMM creates worker pods on target nodes to reconcile the desired module state.
 
 To be eligible for a module, a node must contain the following:
 

diff --git a/modules/kmm-example-module-cr.adoc b/modules/kmm-example-module-cr.adoc
@@ -7,7 +7,8 @@
 
 = Example Module CR
 
-The following is an annotated `Module` example:
+[role="_abstract"]
+Use this annotated `Module` custom resource example as a reference when you configure kernel module loading, device plugins, builds, and signing in {product-title}.
 
 [source,yaml]
 ----

diff --git a/modules/kmm-firmware-support.adoc b/modules/kmm-firmware-support.adoc
@@ -6,7 +6,8 @@
 [id="kmm-firmware-support_{context}"]
 = KMM firmware support
 
-Kernel modules sometimes need to load firmware files from the file system. KMM supports copying firmware files from the kmod image to the node's file system.
+[role="_abstract"]
+KMM firmware support copies firmware files from the kmod image to a node on {product-title} before loading a kernel module. You can configure the source path in the `Module` custom resource.
 
 The contents of `.spec.moduleLoader.container.modprobe.firmwarePath` are copied into the `/var/lib/firmware` path on the node before running the `modprobe` command to insert the kernel module.
 

diff --git a/modules/kmm-gathering-data-for-kmm-hub.adoc b/modules/kmm-gathering-data-for-kmm-hub.adoc
@@ -6,6 +6,9 @@
 [id="kmm-gathering-data-for-kmm-hub_{context}"]
 = Gathering data for KMM-Hub
 
+[role="_abstract"]
+To collect diagnostic data for the KMM-Hub Operator on {product-title}, you can run the must-gather tool with the hub controller image and review Operator logs.
+
 .Procedure
 
 . Gather the data for the KMM Operator hub controller manager:

diff --git a/modules/kmm-gathering-data-for-kmm.adoc b/modules/kmm-gathering-data-for-kmm.adoc
@@ -6,6 +6,9 @@
 [id="kmm-gathering-data-for-kmm_{context}"]
 = Gathering data for KMM
 
+[role="_abstract"]
+To troubleshoot Kernel Module Management (KMM) on {product-title}, you can gather Operator data with the must-gather tool and review controller manager logs.
+
 .Procedure
 
 . Gather the data for the KMM Operator controller manager:

diff --git a/modules/kmm-hub-hub-and-spoke.adoc b/modules/kmm-hub-hub-and-spoke.adoc
@@ -6,9 +6,8 @@
 [id="kmm-hub-hub-and-spoke_{context}"]
 = KMM hub and spoke
 
-In hub and spoke scenarios, many spoke clusters are connected to a central, powerful hub cluster. Kernel Module Management (KMM) depends on Red{nbsp}Hat Advanced Cluster Management (RHACM) to operate in hub and spoke environments.
-
-KMM is compatible with hub and spoke environments through decoupling KMM features. A `ManagedClusterModule` custom resource definition (CRD) is provided to wrap the existing `Module` CRD and extend it to select Spoke clusters. Also provided is KMM-Hub, a new standalone controller that builds images and signs modules on the hub cluster.
+[role="_abstract"]
+Kernel Module Management in {product-title} hub-and-spoke deployments uses Red{nbsp}Hat Advanced Cluster Management (RHACM) to build and sign modules on the hub while loading them on spoke clusters. A `ManagedClusterModule` custom resource extends the `Module` CRD to target spoke clusters with resource-constrained KMM installations.
 
 In hub and spoke setups, spokes are focused, resource-constrained clusters that are centrally managed by a hub cluster. Spokes run the single-cluster edition of KMM, with those resource-intensive features disabled. To adapt KMM to this environment, you should reduce the workload running on the spokes to the minimum, while the hub takes care of the expensive tasks.
 

diff --git a/modules/kmm-hub-installing-kmm-hub-creating-resources.adoc b/modules/kmm-hub-installing-kmm-hub-creating-resources.adoc
@@ -6,6 +6,9 @@
 [id="kmm-hub-installing-kmm-hub-creating-resources_{context}"]
 = Installing KMM-Hub by creating KMM resources
 
+[role="_abstract"]
+To install KMM-Hub programmatically on {product-title}, you can create `Namespace`, `OperatorGroup`, and `Subscription` resources.
+
 .Procedure
 
 * If you want to install KMM-Hub programmatically, you can use the following resources to create

diff --git a/modules/kmm-hub-installing-kmm-hub-olm.adoc b/modules/kmm-hub-installing-kmm-hub-olm.adoc
@@ -6,4 +6,5 @@
 [id="kmm-hub-installing-kmm-hub-olm_{context}"]
 = Installing KMM-Hub using the Operator Lifecycle Manager
 
-Use the *Operators* section of the OpenShift console to install KMM-Hub.
+[role="_abstract"]
+To install KMM-Hub on {product-title} using Operator Lifecycle Manager, you can use the *Operators* section of the OpenShift web console.
diff --git a/modules/kmm-hub-installing-kmm-hub.adoc b/modules/kmm-hub-installing-kmm-hub.adoc
@@ -6,7 +6,5 @@
 [id="kmm-hub-installing-kmm-hub_{context}"]
 = Installing KMM-Hub
 
-You can use one of the following methods to install KMM-Hub:
-
-* With the Operator Lifecycle Manager (OLM)
-* Creating KMM resources
+[role="_abstract"]
+To deploy KMM-Hub for multi-cluster kernel module management on {product-title}, you can install it with Operator Lifecycle Manager (OLM) or by creating KMM resources manually.
diff --git a/modules/kmm-hub-kmm-hub.adoc b/modules/kmm-hub-kmm-hub.adoc
@@ -6,9 +6,8 @@
 [id="kmm-hub-kmm-hub_{context}"]
 = KMM-Hub
 
-The KMM project provides KMM-Hub, an edition of KMM dedicated to hub clusters. KMM-Hub monitors all kernel versions running on the spokes and determines the nodes on the cluster that should receive a kernel module.
-
-KMM-Hub runs all compute-intensive tasks such as image builds and kmod signing, and prepares the trimmed-down `Module` to be transferred to the spokes through RHACM.
+[role="_abstract"]
+KMM-Hub is a hub-cluster edition of Kernel Module Management for {product-title} multi-cluster deployments. It monitors spoke kernel versions, runs image builds and kmod signing on the hub, and delivers trimmed `Module` resources to spokes through RHACM.
 
 [NOTE]
 ====