CCSINTL-3575: Short desc CQA fixes

modules/virt-customizing-vm-template-web.adoc

@@ -7,9 +7,12 @@
 = Removing a deprecated designation from a customized VM template by using the web console
 
 [role="_abstract"]
-You can customize an existing virtual machine (VM) template by modifying the VM or template parameters, such as data sources, cloud-init, or SSH keys, before you start the VM. If you customize a template by copying it and including all of its labels and annotations, the customized template is marked as deprecated when a new version of the Scheduling, Scale, and Performance (SSP) Operator is deployed.
+You can customize an existing virtual machine (VM) template before you start the VM, by modifying the VM or template parameters, such as data sources, cloud-init, or SSH keys.
 
-You can remove the deprecated designation from the customized template.
+[NOTE]
+====
+If you customize a template by copying it and including all of its labels and annotations, the customized template is marked as deprecated when a new version of the Scheduling, Scale, and Performance (SSP) Operator is deployed. You can remove the deprecated designation from the customized template.
+====
 
 .Procedure
 

virt/live_migration/virt-about-live-migration.adoc

@@ -8,7 +8,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
 toc::[]
 
 [role="_abstract"]
-Live migration is the process of moving a running virtual machine (VM) to another node in the cluster without interrupting the virtual workload. Live migration enables smooth transitions during cluster upgrades or any time a node needs to be drained for maintenance or configuration changes. By default, live migration traffic is encrypted using Transport Layer Security (TLS).
+Live migration moves a running virtual machine to another node without interrupting the workload. It enables smooth transitions during cluster upgrades and node maintenance. Traffic is encrypted using TLS by default.
 
 include::modules/virt-live-migration-requirements.adoc[leveloffset=+1]
 

virt/managing_vms/virt-installing-qemu-guest-agent.adoc

@@ -7,9 +7,8 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 [role="_abstract"]
-Enable advanced features like quiesced snapshots and improved monitoring by installing the QEMU guest agent on your virtual machines (VMs). The QEMU guest agent is a daemon that runs on the VM and passes information to the host about the VM, users, file systems, and secondary networks. You must install the QEMU guest agent on VMs created from operating system images that are not provided by Red{nbsp}Hat.
+The QEMU guest agent is a daemon that runs on the VM and passes information to the host about the VM, users, file systems, and secondary networks. You must install the QEMU guest agent on VMs created from operating system images that are not provided by Red{nbsp}Hat.
 
 include::modules/virt-installing-qemu-guest-agent-on-linux-vm.adoc[leveloffset=+1]
 
 include::modules/virt-installing-qemu-guest-agent-on-windows-vm.adoc[leveloffset=+1]
-

virt/post_installation_configuration/virt-post-install-storage-config.adoc

@@ -7,13 +7,10 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 [role="_abstract"]
-ifdef::openshift-enterprise[]
-After you install {VirtProductName}, you must configure a default storage class. If your storage provider is not recognized by the Containerized Data Importer (CDI), you must also configure storage profiles.
-Configuring a storage class allows your cluster to receive automated boot source updates. Storage profiles provide recommended storage settings based on the associated storage class.
+ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
+After you install {VirtProductName}, you must configure a default storage class. Configuring a storage class allows your cluster to receive automated boot source updates.
 endif::[]
-ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
 If your storage provider is not recognized by the Containerized Data Importer (CDI), you must configure storage profiles after you install {VirtProductName}. Storage profiles provide recommended storage settings based on the associated storage class.
-endif::[]
 
 Optional: You can configure local storage by using the hostpath provisioner (HPP).
 

virt/post_installation_configuration/virt-self-validation-checkups.adoc

@@ -7,10 +7,6 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 [role="_abstract"]
-As a cluster administrator, you can run a self validation checkup to validate the stability, health, and compliance of an {VirtProductName} installation. A self validation checkup enables you to run conformance tests on critical subsystems, such as networking and storage, to verify that the environment is fully functional and self-sustained before you deploy production workloads.
-
-Running a self validation checkup streamlines the process of running functional tests, which are fully aligned with the exact build version of {VirtProductName} currently installed on the cluster.
-
-You can view high-level summaries and detailed logs in a downloaded results file, or run tier 2 tests, enabling you to identify and resolve configuration issues without requiring external support immediately.
+Run a self validation checkup to validate the stability, health, and compliance of an {VirtProductName} installation. A self validation checkup runs conformance tests on critical subsystems to verify that the environment is fully functional and self-sustained before you deploy production workloads.
 
 include::modules/virt-run-self-validation-checkup-web-console.adoc[leveloffset=+1]

virt/vm_networking/virt-accessing-vm-internal-fqdn.adoc

@@ -1,20 +1,19 @@
 :_mod-docs-content-type: ASSEMBLY
-[id="virt-accessing-vm-internal-fqdn"]                            
-= Accessing a virtual machine  by using its internal FQDN                                             
-include::_attributes/common-attributes.adoc[]                   
-:context: virt-accessing-vm-internal-fqdn                        
-                                                                
-toc::[]         
+[id="virt-accessing-vm-internal-fqdn"]
+= Accessing a virtual machine  by using its internal FQDN
+include::_attributes/common-attributes.adoc[]
+:context: virt-accessing-vm-internal-fqdn
+
+toc::[]
 
 [role="_abstract"]
-You can access a virtual machine (VM) that is connected to the default internal pod network on a stable fully qualified domain name (FQDN) by using headless services. A Kubernetes _headless service_ creates a DNS record for each pod associated with the service instead of providing a single virtual IP address for the service. You can expose a VM through its FQDN without having to expose a specific TCP or UDP port. 
- 
+You can access a virtual machine on a stable, fully qualified domain name (FQDN) by using headless services. A headless service creates DNS records for each pod instead of a virtual IP, enabling FQDN access without exposing specific ports.
+
 [IMPORTANT]
 ====
 If you created a VM by using the {product-title} web console, you can find its internal FQDN listed in the *Network* tile on the *Overview* tab of the *VirtualMachine details* page.
 ====
 
-
 include::modules/virt-creating-headless-services.adoc[leveloffset=+1]
 
 include::modules/virt-discovering-vm-internal-fqdn.adoc[leveloffset=+1]
@@ -24,4 +23,4 @@ include::modules/virt-connecting-vm-internal-fqdn.adoc[leveloffset=+1]
 [role="_additional-resources"]
 [id="additional-resources_{context}"]
 == Additional resources
-* xref:../../virt/vm_networking/virt-exposing-vm-with-service.adoc#virt-exposing-vm-with-service[Exposing a VM by using a service]
+* xref:../../virt/vm_networking/virt-exposing-vm-with-service.adoc#virt-exposing-vm-with-service[Exposing a VM by using a service]

virt/vm_networking/virt-connecting-vm-to-primary-udn.adoc

@@ -1,16 +1,15 @@
-:_mod-docs-content-type: ASSEMBLY                               
-[id="virt-connecting-vm-to-primary-udn"]                                    
+:_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
+[id="virt-connecting-vm-to-primary-udn"]
 = Connecting a virtual machine to a primary user-defined network
-
-include::_attributes/common-attributes.adoc[]                   
-:context: virt-connecting-vm-to-primary-udn                                    
-
-toc::[]                
+:context: virt-connecting-vm-to-primary-udn
+
+toc::[]
 
 [role="_abstract"]
-You can connect a virtual machine (VM) to a user-defined network (UDN) on the VM's primary interface by using the {product-title} web console or the CLI. The primary user-defined network replaces the default pod network in your specified namespace. Unlike the pod network, you can define the primary UDN per project, where each project can use its specific subnet and topology.
+You can connect a virtual machine (VM) to a user-defined network (UDN) on the VM's primary interface. The primary UDN replaces the default pod network in your specified namespace. You can define the primary UDN per project, where each project can use its specific subnet and topology.
 
-{VirtProductName} supports the namespace-scoped `UserDefinedNetwork` and the cluster-scoped `ClusterUserDefinedNetwork` custom resource definitions (CRD). 
+{VirtProductName} supports the namespace-scoped `UserDefinedNetwork` and the cluster-scoped `ClusterUserDefinedNetwork` custom resource definitions (CRD).
 
 Cluster administrators can configure a primary `UserDefinedNetwork` CRD to create a tenant network that isolates the tenant namespace from other namespaces without requiring network policies. Additionally, cluster administrators can use the `ClusterUserDefinedNetwork` CRD to create a shared OVN network across multiple namespaces.
 
@@ -19,17 +18,15 @@ Cluster administrators can configure a primary `UserDefinedNetwork` CRD to creat
 You must add the `k8s.ovn.org/primary-user-defined-network` label when you create a namespace that is to be used with user-defined networks.
 ====
 
-With the layer 2 topology, OVN-Kubernetes creates an overlay network between nodes. You can use this overlay network to connect VMs on different nodes without having to configure any additional physical networking infrastructure. 
+With the layer 2 topology, OVN-Kubernetes creates an overlay network between nodes. You can use this overlay network to connect VMs on different nodes without having to configure any additional physical networking infrastructure.
 
-The layer 2 topology enables seamless migration of VMs without the need for Network Address Translation (NAT) because persistent IP addresses are preserved across cluster nodes during live migration. 
+The layer 2 topology enables seamless migration of VMs without the need for Network Address Translation (NAT) because persistent IP addresses are preserved across cluster nodes during live migration.
 
 You must consider the following limitations before implementing a primary UDN:
 
 * You cannot use the `virtctl ssh` command to configure SSH access to a VM.
 * You cannot use the `oc port-forward` command to forward ports to a VM.
 * You cannot use headless services to access a VM.
-
-
 
 include::modules/virt-creating-primary-udn-web-intro.adoc[leveloffset=+1]
 
@@ -41,7 +38,6 @@ include::modules/virt-creating-a-localnet-cudn-web.adoc[leveloffset=+2]
 
 include::modules/virt-creating-primary-cluster-udn-web.adoc[leveloffset=+2]
 
-
 include::modules/virt-creating-primary-udn-cli-intro.adoc[leveloffset=+1]
 
 include::modules/virt-creating-udn-namespace-cli.adoc[leveloffset=+2]
@@ -50,7 +46,6 @@ include::modules/virt-creating-a-primary-udn.adoc[leveloffset=+2]
 
 include::modules/virt-creating-a-primary-cluster-udn.adoc[leveloffset=+2]
 
-
 include::modules/virt-attaching-vm-to-primary-udn-intro.adoc[leveloffset=+1]
 
 include::modules/virt-attaching-vm-to-primary-udn-web.adoc[leveloffset=+2]