openshift · mburke5678 · Jun 15, 2026
diff --git a/modules/byoh-configuring.adoc b/modules/byoh-configuring.adoc
@@ -6,7 +6,8 @@
 [id="configuring-byoh-windows-instance"]
 = Configuring a BYOH Windows instance
 
-Creating a BYOH Windows instance requires creating a config map in the Windows Machine Config Operator (WMCO) namespace.
+[role="_abstract"]
+To create a Bring-Your-Own-Host (BYOH) Windows instance, you must create a config map in the Windows Machine Config Operator (WMCO) namespace.
 
 .Prerequisites
 Any Windows instances that are to be attached to the cluster as a node must fulfill the following requirements:
@@ -45,10 +46,15 @@ metadata:
   name: windows-instances
   namespace: openshift-windows-machine-config-operator
 data:
-  10.1.42.1: |- <1>
-    username=Administrator <2>
+  10.1.42.1: |-
+    username=Administrator
   instance.example.com: |-
     username=core
 ----
-<1> The address that the WMCO uses to reach the instance over SSH, either a DNS name or an IPv4 address. A DNS PTR record must exist for this address. It is recommended that you use a DNS name with your BYOH instance if your organization uses DHCP to assign IP addresses. If not, you need to update the `windows-instances` ConfigMap whenever the instance is assigned a new IP address.
-<2> The name of the administrator user created in the prerequisites.
+where:
++
+--
+`data`:: Specifies the address that the WMCO uses to reach the instance over SSH, either a DNS name or an IPv4 address. A DNS PTR record must exist for this address. You should use a DNS name with your BYOH instance if your organization uses DHCP to assign IP addresses. If not, you need to update the `windows-instances` ConfigMap whenever the instance is assigned a new IP address. 
++
+Also, specify the user name of the administrator user created in the prerequisites.
+--
diff --git a/modules/byoh-removal.adoc b/modules/byoh-removal.adoc
@@ -2,11 +2,14 @@
 //
 // * windows_containers/creating_windows_machinesets/byoh-windows-instance.adoc
 
-:_mod-docs-content-type: PROCEDURE
+:_mod-docs-content-type: REFERENCE
 [id="removing-byoh-windows-instance"]
 = Removing BYOH Windows instances
 
-You can remove BYOH instances attached to the cluster by deleting the instance's entry in the config map. Deleting an instance reverts that instance back to its state prior to adding to the cluster. Any logs and container runtime artifacts are not added to these instances.
+[role="_abstract"]
+You can remove a Bring-Your-Own-Host (BYOH) instance that is attached to the cluster by deleting the instance's entry in the BYOH config map. Deleting an instance reverts that instance back to its previous state, before it was added to the cluster. 
+
+Any logs and container runtime artifacts are not added to these instances.
 
 For an instance to be cleanly removed, it must be accessible with the current private key provided to WMCO. For example, to remove the `10.1.42.1` instance from the previous example, the config map would be changed to the following:
 

diff --git a/modules/machineset-creating.adoc b/modules/machineset-creating.adoc
@@ -104,7 +104,6 @@ $ oc get machineset <machineset_name> \
   -n openshift-machine-api -o yaml
 ----
 +
---
 .Example output
 [source,yaml]
 ----
@@ -132,9 +131,9 @@ spec:
       providerSpec:
         ...
 ----
-
 where:
-
++
+--
 `metadata.labels.machine.openshift.io/cluster-api-cluster`:: Specifies the cluster infrastructure ID.
 `metadata.labels.name`:: Specifies a default node label.
 +
@@ -184,7 +183,6 @@ template:
           resourcepool: <vsphere_resource_pool>
           server: <vcenter_server_address>
 ----
-
 where:
 
 `vsphere-cloud-credentials`:: Specifies the name of the secret in the `openshift-machine-api` namespace that contains the required vCenter credentials.

diff --git a/modules/windows-machineset-nutanix.adoc b/modules/windows-machineset-nutanix.adoc
@@ -6,91 +6,99 @@
 [id="windows-machineset-nutanix_{context}"]
 = Sample YAML for a Windows MachineSet object on Nutanix
 
-This sample YAML defines a Windows `MachineSet` object running on Nutanix that the Windows Machine Config Operator (WMCO) can react upon.
+[role="_abstract"]
+You can define a Windows `MachineSet` object running on Nutanix by creating a YAML file similar to the following example that the Windows Machine Config Operator (WMCO) can react upon.
 
 [source,yaml]
 ----
 apiVersion: machine.openshift.io/v1beta1
 kind: MachineSet
 metadata:
   labels:
-    machine.openshift.io/cluster-api-cluster: <infrastructure_id> <1>
-  name: <infrastructure_id>-windows-worker-<zone> <2>
+    machine.openshift.io/cluster-api-cluster: <infrastructure_id>
+  name: <infrastructure_id>-windows-worker-<zone>
   namespace: openshift-machine-api
 spec:
   replicas: 1
   selector:
     matchLabels:
-      machine.openshift.io/cluster-api-cluster: <infrastructure_id> <1>
-      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone> <2>
+      machine.openshift.io/cluster-api-cluster: <infrastructure_id>
+      machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
   template:
     metadata:
       labels:
-        machine.openshift.io/cluster-api-cluster: <infrastructure_id> <1>
+        machine.openshift.io/cluster-api-cluster: <infrastructure_id>
         machine.openshift.io/cluster-api-machine-role: worker
         machine.openshift.io/cluster-api-machine-type: worker
-        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone> <2>
-        machine.openshift.io/os-id: Windows <3>
+        machine.openshift.io/cluster-api-machineset: <infrastructure_id>-windows-worker-<zone>
+        machine.openshift.io/os-id: Windows
     spec:
       metadata:
         labels:
-          node-role.kubernetes.io/worker: "" <4>
+          node-role.kubernetes.io/worker: ""
       providerSpec:
         value:
           apiVersion: machine.openshift.io/v1
-          bootType: "" <5>
+          bootType: ""
           categories: null
-          cluster: <6>
+          cluster:
             type: uuid
             uuid: <cluster_uuid>
           credentialsSecret:
-            name: nutanix-credentials <7>
-          image: <8>
+            name: nutanix-credentials
+          image:
             name: <image_id>
             type: name
-          kind: NutanixMachineProviderConfig <9>
-          memorySize: 16Gi <10>
+          kind: NutanixMachineProviderConfig
+          memorySize: 16Gi
           project:
             type: ""
-          subnets: <11>
+          subnets:
           - type: uuid
             uuid: <subnet_uuid>
-          systemDiskSize: 120Gi <12>
+          systemDiskSize: 120Gi
           userDataSecret:
-            name: windows-user-data <13>
-          vcpuSockets: 4 <14>
-          vcpusPerSocket: 1 <15>
+            name: windows-user-data
+          vcpuSockets: 4
+          vcpusPerSocket: 1
 ----
-<1> Specify the infrastructure ID that is based on the cluster ID that you set when you provisioned the cluster. You can obtain the infrastructure ID by running the following command:
+where:
+
+`metadata.labels.machine.openshift.io/cluster-api-cluster`:: Replace `<infrastructure_id>` with the infrastructure ID. You can obtain the infrastructure ID by running the following command:
 +
 [source,terminal]
 ----
 $ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
 ----
-<2> Specify the infrastructure ID, worker label, and zone.
-<3> Configure the compute machine set as a Windows machine.
-<4> Configure the Windows node as a compute machine.
-<5> Specifies the boot type that the compute machines use. For more information about boot types, see link:https://portal.nutanix.com/page/documents/kbs/details?targetId=kA07V000000H3K9SAK[Understanding UEFI, Secure Boot, and TPM in the Virtualized Environment]. Valid values are `Legacy`, `SecureBoot`, or `UEFI`. The default is `Legacy`.
+`metadata.name`:: Replace the infrastructure ID, worker label, and zone.
+`spec.selector.matchLabels`:: Replace the parameters for the following labels: 
+* `machine.openshift.io/cluster-api-cluster`. Replace the infrastructure ID.
+* `machine.openshift.io/cluster-api-machineset`. Replace the infrastructure ID, worker label, and zone.
+`spec.template.metadata.labels`:: Replace the parameters for the following labels: 
+* `machine.openshift.io/cluster-api-cluster`. Replace the infrastructure ID.
+* `machine.openshift.io/cluster-api-machineset`. Replace the infrastructure ID, worker label, and zone.
+* `machine.openshift.io/os-id: Windows`. When set to `Windows`, configures the compute machine set as a Windows machine.
+`spec.template.spec.metadata.labels`::  When set to `node-role.kubernetes.io/worker`, configures the node as a compute machine.
+`spec.template.spec.providerSpec`:: Specify the following parameters:
++
+* `value.bootType`. Specifies the boot type that the compute machines use. Valid values are `Legacy`, `SecureBoot`, or `UEFI`. The default is `Legacy`. For more information about boot types, see "Understanding UEFI, Secure Boot, and TPM in the Virtualized Environment (Nutanix documentaiton)" in the _Additional resources_ section.
 +
 [NOTE]
 ====
 You must use the `Legacy` boot type in {product-title} {product-version}.
 ====
-<6> Specifies a Nutanix Prism Element cluster configuration. In this example, the cluster type is `uuid`, so there is a `uuid` stanza.
-<7> Specifies the secret name for the cluster. Do not change this value.
-<8> Specifies the image to use. Use an image from an existing default compute machine set for the cluster, one of the following options: 
-+
---
-* `nutanix-windows-server-2022` for Windows Server 2022
-* `nutanix-windows-server-2025` for Windows Server 2025
---
-<9> Specifies the cloud provider platform type. Do not change this value.
-<10> Specifies the amount of memory for the cluster in Gi.
-<11> Specifies a subnet configuration. In this example, the subnet type is `uuid`, so there is a `uuid` stanza.
-<12> Specifies the size of the system disk in Gi.
-<13> Specifies the name of the secret in the user data YAML file that is in the `openshift-machine-api` namespace. Use the value that installation program populates in the default compute machine set.
-<14> Specifies the number of vCPU sockets.
-<15> Specifies the number of vCPUs per socket.
+* `value.cluster`. Specifies a Nutanix Prism Element cluster configuration. In this example, the cluster type is `uuid`, so there is a `uuid` stanza. Replace `<cluster_uuid>` with the cluster UUID.
+* `value.credentialsSecret.name`. Specifies the secret name for the cluster. Do not change this value.
+* `value.image`. Specifies the image to use. Replace `<image_id>` with an image from an existing default compute machine set for the cluster, one of the following options: 
+** `nutanix-windows-server-2022` for Windows Server 2022
+** `nutanix-windows-server-2025` for Windows Server 2025
+* `value.kind`. Specifies the cloud provider platform type. Do not change this value.
+* `value.memorySize`. Specifies the amount of memory for the cluster in Gi.
+* `value.subnets`. Specifies a subnet configuration. In this example, the subnet type is `uuid`, so there is a `uuid` stanza. Replace `<subnet_uuid>` with the subnet UUID.
+* `value.systemDiskSize`. Specifies the size of the system disk in Gi.
+* `value.userDataSecret.name`. Specifies the name of the secret in the user data YAML file that is in the `openshift-machine-api` namespace. Use the value that installation program populates in the default compute machine set.
+* `value.vcpuSockets`. Specifies the number of vCPU sockets.
+* `value.vcpusPerSocket`. Specifies the number of vCPUs per socket.
 
 // providerSpec section is based on cpmso-yaml-provider-spec-nutanix.adoc 
 
diff --git a/windows_containers/byoh-windows-instance.adoc b/windows_containers/byoh-windows-instance.adoc
@@ -6,7 +6,8 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-Bring-Your-Own-Host (BYOH) allows for users to repurpose Windows Server VMs and bring them to {product-title}. BYOH Windows instances benefit users looking to mitigate major disruptions in the event that a Windows server goes offline.
+[role="_abstract"]
+You can create Bring-Your-Own-Host (BYOH) Windows instances to repurpose Windows Server VMs and bring them to {product-title}. By using BYOH Windows instances, you can mitigate major disruptions if a Windows server goes offline.
 
 include::modules/byoh-configuring.adoc[leveloffset=+1]
 

diff --git a/...ontainers/creating_windows_machinesets/creating-windows-machineset-nutanix.adoc b/...ontainers/creating_windows_machinesets/creating-windows-machineset-nutanix.adoc
@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
+[role="_abstract"]
 You can create a Windows `MachineSet` object to serve a specific purpose in your {product-title} cluster on Nutanix. For example, you might create infrastructure Windows machine sets and related machines so that you can move supporting Windows workloads to the new Windows machines.
 
 
@@ -24,4 +25,5 @@ include::modules/machineset-creating.adoc[leveloffset=+1]
 [role="_additional-resources"]
 == Additional resources
 
-* xref:../../machine_management/index.adoc#overview-of-machine-management[Overview of machine management].
+* xref:../../machine_management/index.adoc#overview-of-machine-management[Overview of machine management]
+* link:https://portal.nutanix.com/page/documents/kbs/details?targetId=kA07V000000H3K9SAK[Understanding UEFI, Secure Boot, and TPM in the Virtualized Environment (Nutanix documenation)]