OSDOCS-16572: second batch of rec visibility changes

skopacz1 · skopacz1 · commit 0849157b05fc · 2025-11-03T12:41:40.000-05:00
diff --git a/modules/nw-sriov-configuring-device.adoc b/modules/nw-sriov-configuring-device.adoc
@@ -27,10 +27,10 @@ You can configure an SR-IOV network device by creating a SriovNetworkNodePolicy
 When applying the configuration specified in a `SriovNetworkNodePolicy` object, the SR-IOV Operator might drain the nodes, and in some cases, reboot nodes.
 Reboot only happens in the following cases:
 
-* With Mellanox NICs (`mlx5` driver) a node reboot happens every time the number of virtual functions (VFs) increase on a physical function (PF). 
+* With Mellanox NICs (`mlx5` driver) a node reboot happens every time the number of virtual functions (VFs) increase on a physical function (PF).
 * With Intel NICs, a reboot only happens if the kernel parameters do not include `intel_iommu=on` and `iommu=pt`.
 
-It might take several minutes for a configuration change to apply. 
+It might take several minutes for a configuration change to apply.
 =====
 
 .Prerequisites
@@ -68,6 +68,8 @@ spec:
   deviceType: vfio-pci <13>
   isRdma: false <14>
 ----
++
+--
 <1> Specify a name for the CR object.
 <2> Specify the namespace where the SR-IOV Operator is installed.
 <3> Specify the resource name of the SR-IOV device plugin. You can create multiple `SriovNetworkNodePolicy` objects for a resource name.
@@ -77,8 +79,13 @@ Container Network Interface (CNI) plugin and device plugin are deployed only on
 <5> Optional: Specify an integer value between `0` and `99`. A smaller number gets higher priority, so a priority of `10` is higher than a priority of `99`. The default value is `99`.
 <6> Optional: Specify a value for the maximum transmission unit (MTU) of the virtual function. The maximum MTU value can vary for different NIC models.
 <7> Specify the number of the virtual functions (VF) to create for the SR-IOV physical network device. For an Intel network interface controller (NIC), the number of VFs cannot be larger than the total VFs supported by the device. For a Mellanox NIC, the number of VFs cannot be larger than `127`.
-<8> The `nicSelector` mapping selects the Ethernet device for the Operator to configure. You do not need to specify values for all the parameters. It is recommended to identify the Ethernet adapter with enough precision to minimize the possibility of selecting an Ethernet device unintentionally.
+<8> The `nicSelector` mapping selects the Ethernet device for the Operator to configure. You do not need to specify values for all the parameters.
++
+[NOTE]
+====
+It is recommended to identify the Ethernet adapter with enough precision to minimize the possibility of selecting an Ethernet device unintentionally.
 If you specify `rootDevices`, you must also specify a value for `vendor`, `deviceID`, or `pfNames`.
+====
 If you specify both `pfNames` and `rootDevices` at the same time, ensure that they point to an identical device.
 <9> Optional: Specify the vendor hex code of the SR-IOV network device. The only allowed values are either `8086` or `15b3`.
 <10> Optional: Specify the device hex code of SR-IOV network device. The only allowed values are `158b`, `1015`, `1017`.
@@ -92,6 +99,7 @@ If you specify both `pfNames` and `rootDevices` at the same time, ensure that th
 If `isRDMA` flag is set to `true`, you can continue to use the RDMA enabled VF as a normal network device.
 A device can be used in either mode.
 ====
+--
 endif::virt-sriov[]
 
 . Optional: Label the SR-IOV capable cluster nodes with `SriovNetworkNodePolicy.Spec.NodeSelector` if they are not already labeled. For more information about labeling nodes, see "Understanding how to update labels on nodes".
diff --git a/modules/virt-access-configuration-considerations.adoc b/modules/virt-access-configuration-considerations.adoc
@@ -8,7 +8,10 @@
 
 Each method for configuring access to a virtual machine (VM) has advantages and limitations, depending on the traffic load and client requirements.
 
+[NOTE]
+====
 Services provide excellent performance and are recommended for applications that are accessed from outside the cluster.
+====
 
 If the internal cluster network cannot handle the traffic load, you can configure a secondary network.
 
diff --git a/modules/virt-aws-bm.adoc b/modules/virt-aws-bm.adoc
@@ -43,7 +43,11 @@ Accessing virtual machines (VMs)::
 --
 * There is no change to how you access VMs by using the `virtctl` CLI tool or the {product-title} web console.
 * You can expose VMs by using a `NodePort` or `LoadBalancer` service.
-** The load balancer approach is preferable because {product-title} automatically creates the load balancer in AWS and manages its lifecycle. A security group is also created for the load balancer, and you can use annotations to attach existing security groups. When you remove the service, {product-title} removes the load balancer and its associated resources.
++
+[NOTE]
+====
+The load balancer approach is preferable because {product-title} automatically creates the load balancer in AWS and manages its lifecycle. A security group is also created for the load balancer, and you can use annotations to attach existing security groups. When you remove the service, {product-title} removes the load balancer and its associated resources.
+====
 --
 
 Networking::
diff --git a/modules/virt-vm-storage-volume-types.adoc b/modules/virt-vm-storage-volume-types.adoc
@@ -33,11 +33,11 @@ Specify `type: dataVolume` or `type: ""`. If you specify any other value for `ty
 
 A `containerDisk` volume is not limited to a single virtual machine and is useful for creating large numbers of virtual machine clones that do not require persistent storage.
 
-Only RAW and QCOW2 formats are supported disk types for the container image registry. QCOW2 is recommended for reduced image size.
-
 [NOTE]
 ====
-A `containerDisk` volume is ephemeral. It is discarded when the virtual machine is stopped, restarted, or deleted. A `containerDisk` volume is useful for read-only file systems such as CD-ROMs or for disposable virtual machines.
+* Only RAW and QCOW2 formats are supported disk types for the container image registry. QCOW2 is recommended for reduced image size.
+
+* A `containerDisk` volume is ephemeral. It is discarded when the virtual machine is stopped, restarted, or deleted. A `containerDisk` volume is useful for read-only file systems such as CD-ROMs or for disposable virtual machines.
 ====
 
 |emptyDisk
diff --git a/modules/ztp-talo-integration.adoc b/modules/ztp-talo-integration.adoc
@@ -34,10 +34,13 @@ All CRs in the same policy must have the same setting for the `ztp-deploy-wave`
 +
 The {cgu-operator} applies the configuration policies in the order specified by the wave annotations. The {cgu-operator} waits for each policy to be compliant before moving to the next policy. It is important to ensure that the wave annotation for each CR takes into account any prerequisites for those CRs to be applied to the cluster. For example, an Operator must be installed before or concurrently with the configuration for the Operator. Similarly, the `CatalogSource` for an Operator must be installed in a wave before or concurrently with the Operator Subscription. The default wave value for each CR takes these prerequisites into account.
 +
+[NOTE]
+====
 Multiple CRs and policies can share the same wave number. Having fewer policies can result in faster deployments and lower CPU usage. It is a best practice to group many CRs into relatively few waves.
-
+====
++
 To check the default wave value in each source CR, run the following command against the `out/source-crs` directory that is extracted from the `ztp-site-generate` container image:
-
++
 [source,terminal]
 ----
 $ grep -r "ztp-deploy-wave" out/source-crs
diff --git a/virt/install/preparing-cluster-for-virt.adoc b/virt/install/preparing-cluster-for-virt.adoc
@@ -33,7 +33,7 @@ You can use the following platforms with {VirtProductName}:
 
 endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 
-// hiding in rosa/osd 
+// hiding in rosa/osd
 ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 // the following section is in the assembly for xref reasons
 Cloud platforms::
@@ -278,7 +278,11 @@ The default xref:../../virt/live_migration/virt-configuring-live-migration.adoc#
 ====
 
 * If the virtual machine uses a host model CPU, the nodes must support the virtual machine's host model CPU.
-* A xref:../../virt/vm_networking/virt-dedicated-network-live-migration.adoc#virt-dedicated-network-live-migration[dedicated Multus network] for live migration is highly recommended. A dedicated network minimizes the effects of network saturation on tenant workloads during migration.
+
+[NOTE]
+====
+A xref:../../virt/vm_networking/virt-dedicated-network-live-migration.adoc#virt-dedicated-network-live-migration[dedicated Multus network] for live migration is highly recommended. A dedicated network minimizes the effects of network saturation on tenant workloads during migration.
+====
 
 include::modules/virt-cluster-resource-requirements.adoc[leveloffset=+1]
 
@@ -317,7 +321,7 @@ Currently, IPI is not supported on {ibm-z-name}.
 ====
 
 * Automatic high availability for both IPI and non-IPI is available by using the *Node Health Check Operator* on the {product-title} cluster to deploy the `NodeHealthCheck` controller. The controller identifies unhealthy nodes and uses a remediation provider, such as the Self Node Remediation Operator or Fence Agents Remediation  Operator, to remediate the unhealthy nodes. For more information on remediation, fencing, and maintaining nodes, see the link:https://access.redhat.com/documentation/en-us/workload_availability_for_red_hat_openshift[Workload Availability for Red Hat OpenShift] documentation.
-
++
 [NOTE]
 ====
 Fence Agents Remediation uses supported fencing agents to reset failed nodes faster than the Self Node Remediation Operator. This improves overall virtual machine high availability. For more information, see the link:https://access.redhat.com/articles/7057929[OpenShift Virtualization - Fencing and VM High Availability Guide] knowledgebase article.
diff --git a/virt/managing_vms/virt-accessing-vm-ssh.adoc b/virt/managing_vms/virt-accessing-vm-ssh.adoc
@@ -102,7 +102,10 @@ include::modules/virt-using-virtctl-port-forward-command.adoc[leveloffset=+1]
 
 You can create a service for a virtual machine (VM) and connect to the IP address and port exposed by the service.
 
+[NOTE]
+====
 Services provide excellent performance and are recommended for applications that are accessed from outside the cluster or within the cluster. Ingress traffic is protected by firewalls.
+====
 
 If the cluster network cannot handle the traffic load, consider using a secondary network for VM access.
 
