CNV - API object style changes

_topic_map.yml

@@ -2337,7 +2337,7 @@ Topics:
     File: virt-installing-qemu-guest-agent
   - Name: Viewing the QEMU guest agent information for virtual machines
     File: virt-viewing-qemu-guest-agent-web
-  - Name: Managing ConfigMaps, secrets, and service accounts in virtual machines
+  - Name: Managing config maps, secrets, and service accounts in virtual machines
     File: virt-managing-configmaps-secrets-service-accounts
   - Name: Installing VirtIO driver on an existing Windows virtual machine
     File: virt-installing-virtio-drivers-on-existing-windows-vm
@@ -2363,11 +2363,11 @@ Topics:
   - Name: Importing virtual machines
     Dir: importing_vms
     Topics:
-    - Name: TLS certificates for DataVolume imports
+    - Name: TLS certificates for data volume imports
       File: virt-tls-certificates-for-dv-imports
-    - Name: Importing virtual machine images with DataVolumes
+    - Name: Importing virtual machine images with data volumes
       File: virt-importing-virtual-machine-images-datavolumes
-    - Name: Importing virtual machine images to block storage with DataVolumes
+    - Name: Importing virtual machine images to block storage with data volumes
       File: virt-importing-virtual-machine-images-datavolumes-block
     - Name: Importing a Red Hat Virtualization virtual machine
       File: virt-importing-rhv-vm
@@ -2377,19 +2377,19 @@ Topics:
   - Name: Cloning virtual machines
     Dir: cloning_vms
     Topics:
-    - Name: Enabling user permissions to clone DataVolumes across namespaces
+    - Name: Enabling user permissions to clone data volumes across namespaces
       File: virt-enabling-user-permissions-to-clone-datavolumes
-    - Name: Cloning a virtual machine disk into a new DataVolume
+    - Name: Cloning a virtual machine disk into a new data volume
       File: virt-cloning-vm-disk-into-new-datavolume
-    - Name: Cloning a virtual machine by using a DataVolumeTemplate
+    - Name: Cloning a virtual machine by using a data volume template
       File: virt-cloning-vm-using-datavolumetemplate
-    - Name: Cloning a virtual machine disk into a new block storage DataVolume
+    - Name: Cloning a virtual machine disk into a new block storage data volume
       File: virt-cloning-vm-disk-into-new-datavolume-block
 # Virtual machine networking
   - Name: Virtual machine networking
     Dir: vm_networking
     Topics:
-    - Name: Using the default Pod network with OpenShift Virtualization
+    - Name: Using the default pod network with OpenShift Virtualization
       File: virt-using-the-default-pod-network-with-virt
     - Name: Attaching a virtual machine to multiple networks
       File: virt-attaching-vm-multiple-networks
@@ -2417,17 +2417,17 @@ Topics:
       File: virt-uploading-local-disk-images-web
     - Name: Uploading local disk images by using the virtctl tool
       File: virt-uploading-local-disk-images-virtctl
-    - Name: Uploading a local disk image to a block storage DataVolume
+    - Name: Uploading a local disk image to a block storage data volume
       File: virt-uploading-local-disk-images-block
     - Name: Managing offline virtual machine snapshots
       File: virt-managing-offline-vm-snapshots
     - Name: Moving a local virtual machine disk to a different node
       File: virt-moving-local-vm-disk-to-different-node
     - Name: Expanding virtual storage by adding blank disk images
       File: virt-expanding-virtual-storage-with-blank-disk-images
-    - Name: Cloning a DataVolume using smart-cloning
+    - Name: Cloning a data volume using smart-cloning
       File: virt-cloning-a-datavolume-using-smart-cloning
-    - Name: Storage defaults for DataVolumes
+    - Name: Storage defaults for data volumes
       File: virt-storage-defaults-for-datavolumes
     - Name: Creating and using default OS images
       File: virt-creating-and-using-default-os-images
@@ -2437,7 +2437,7 @@ Topics:
       File: virt-preparing-cdi-scratch-space
     - Name: Re-using statically provisioned persistent volumes
       File: virt-reusing-statically-provisioned-persistent-volumes
-    - Name: Deleting DataVolumes
+    - Name: Deleting data volumes
       File: virt-deleting-datavolumes
 # Templates
 - Name: Virtual machine templates
@@ -2499,7 +2499,7 @@ Topics:
     File: virt-logs
   - Name: Viewing events
     File: virt-events
-  - Name: Diagnosing DataVolumes using events and conditions
+  - Name: Diagnosing data volumes using events and conditions
     File: virt-diagnosing-datavolumes-using-events-and-conditions
   - Name: Viewing information about virtual machine workloads
     File: virt-viewing-information-about-vm-workloads

modules/virt-about-block-pvs.adoc

@@ -5,11 +5,11 @@
 // * virt/virtual_machines/importing_vms/virt-importing-virtual-machine-images-datavolumes-block.adoc
 
 [id="virt-about-block-pvs_{context}"]
-= About block PersistentVolumes
+= About block persistent volumes
 
-A block PersistentVolume (PV) is a PV that is backed by a raw block device. These volumes
-do not have a filesystem and can provide performance benefits for
+A block persistent volume (PV) is a PV that is backed by a raw block device. These volumes
+do not have a file system and can provide performance benefits for
 virtual machines by reducing overhead.
 
 Raw block volumes are provisioned by specifying `volumeMode: Block` in the
-PV and PersistentVolumeClaim (PVC) specification.
+PV and persistent volume claim (PVC) specification.

modules/virt-about-collecting-virt-data.adoc

@@ -13,7 +13,7 @@ cluster, including features and objects associated with {VirtProductName}:
 * The Hyperconverged Cluster Operator namespaces (and child objects)
 * All namespaces (and their child objects) that belong to any {VirtProductName}
 resources
-* All {VirtProductName} Custom Resource Definitions (CRDs)
+* All {VirtProductName} custom resource definitions (CRDs)
 * All namespaces that contain virtual machines
 * All virtual machine definitions
 

modules/virt-about-conditions-and-events.adoc

@@ -5,7 +5,7 @@
 [id="virt-about-conditions-and-events.adoc_{context}"]
 = About conditions and events
 
-Diagnose DataVolume issues by examining the output of the `Conditions` and `Events` sections
+Diagnose data volume issues by examining the output of the `Conditions` and `Events` sections
 generated by the command:
 
 [source,terminal]
@@ -29,7 +29,7 @@ The `Events` section provides the following additional information:
 The output from `oc describe` does not always contains `Events`.
 
 An event is generated when either `Status`, `Reason`, or `Message` changes.
-Both conditions and events react to changes in the state of the DataVolume.
+Both conditions and events react to changes in the state of the data volume.
 
 For example, if you misspell the URL during an import operation, the import
 generates a 404 message. That message change generates an event with a reason.

modules/virt-about-container-disks.adoc

@@ -8,20 +8,20 @@
 
 A container disk is a virtual machine image that is stored as a container image in a container image registry. You can use container disks to deliver the same disk images to multiple virtual machines and to create large numbers of virtual machine clones.
 
-A container disk can either be imported into a persistent volume claim (PVC) by using a DataVolume that is attached to a virtual machine, or attached directly to a virtual machine as an ephemeral `containerDisk` volume.
+A container disk can either be imported into a persistent volume claim (PVC) by using a data volume that is attached to a virtual machine, or attached directly to a virtual machine as an ephemeral `containerDisk` volume.
 
-== Importing a container disk into a PVC by using a DataVolume
+== Importing a container disk into a PVC by using a data volume
 
-Use the Containerized Data Importer (CDI) to import the container disk into a PVC by using a DataVolume. You can then attach the DataVolume to a virtual machine for persistent storage.
+Use the Containerized Data Importer (CDI) to import the container disk into a PVC by using a data volume. You can then attach the data volume to a virtual machine for persistent storage.
 
 == Attaching a container disk to a virtual machine as a `containerDisk` volume
 
 A `containerDisk` volume is ephemeral. It is discarded when the virtual machine is stopped, restarted, or deleted. When a virtual machine with a `containerDisk` volume starts, the container image is pulled from the registry and hosted on the node that is hosting the virtual machine.
 
-Use `containerDisk` volumes for read-only filesystems such as CD-ROMs or for disposable virtual machines.
+Use `containerDisk` volumes for read-only file systems such as CD-ROMs or for disposable virtual machines.
 
 [IMPORTANT]
 ====
-Using `containerDisk` volumes for read-write filesystems is not recommended because the data is temporarily written to local storage on the hosting node. This slows live migration of the virtual machine, such as in the case of node maintenance, because the data must be migrated to the destination node. Additionally, all data is lost if the node loses power or otherwise shuts down unexpectedly.
+Using `containerDisk` volumes for read-write file systems is not recommended because the data is temporarily written to local storage on the hosting node. This slows live migration of the virtual machine, such as in the case of node maintenance, because the data must be migrated to the destination node. Additionally, all data is lost if the node loses power or otherwise shuts down unexpectedly.
 ====
 

modules/virt-about-datavolumes.adoc

@@ -11,10 +11,10 @@
 // * virt/virtual_machines/importing_vms/virt-importing-virtual-machine-images-datavolumes-block.adoc
 
 [id="virt-about-datavolumes_{context}"]
-= About DataVolumes
+= About data volumes
 
 `DataVolume` objects are custom resources that are provided by the Containerized
-Data Importer (CDI) project. DataVolumes orchestrate import, clone, and upload
-operations that are associated with an underlying PersistentVolumeClaim (PVC).
-DataVolumes are integrated with KubeVirt, and they prevent a virtual machine
+Data Importer (CDI) project. Data volumes orchestrate import, clone, and upload
+operations that are associated with an underlying persistent volume claim (PVC).
+Data volumes are integrated with {VirtProductName}, and they prevent a virtual machine
 from being started before the PVC has been prepared.

modules/virt-about-hostpath-provisioner.adoc

@@ -13,14 +13,14 @@ When you install the {VirtProductName} Operator, the hostpath provisioner Operat
 is automatically installed. To use it, you must:
 
 * Configure SELinux:
-** If you use Red Hat Enterprise Linux CoreOS 8 workers, you must create a MachineConfig
+** If you use Red Hat Enterprise Linux CoreOS 8 workers, you must create a `MachineConfig`
 object on each node.
-** Otherwise, apply the SELinux label `container_file_t` to the PersistentVolume (PV) backing
+** Otherwise, apply the SELinux label `container_file_t` to the persistent volume (PV) backing
 directory on each node.
-* Create a HostPathProvisioner custom resource.
+* Create a `HostPathProvisioner` custom resource.
 * Create a `StorageClass` object for the hostpath provisioner.
 
 The hostpath provisioner Operator deploys the provisioner as a _DaemonSet_ on each
 node when you create its custom resource. In the custom resource file, you specify
-the backing directory for the PersistentVolumes that the hostpath provisioner
+the backing directory for the persistent volumes that the hostpath provisioner
 creates.

modules/virt-about-liveness-readiness-probes.adoc

@@ -6,11 +6,7 @@
 
 = About liveness and readiness probes
 
-When a VirtualMachineInstance (VMI) fails, _liveness probes_ stop the VMI.
-Controllers such as VirtualMachine then spawn other VMIs, restoring virtual
-machine responsiveness.
+_Liveness probes_ determine if a virtual machine instance (VMI) is still responding. If the probe fails, the VMI is stopped. A replacement VMI is then created to restore virtual machine responsiveness.
 
-_Readiness probes_ tell services and endpoints that the VirtualMachineInstance
-is ready to receive traffic from services. If readiness probes fail,
-the VirtualMachineInstance is removed from
-applicable endpoints until the probe recovers.
+_Readiness probes_ tell services and endpoints that the virtual machine instance
+is ready to receive traffic from services. If readiness probes fail, the virtual machine instance is removed from applicable endpoints until the probe recovers.

modules/virt-about-storage-setting-for-datavolumes.adoc

@@ -3,25 +3,25 @@
 // * virt/virtual_machines/virtual_disks/virt-storage-defaults-for-datavolumes.adoc
 
 [id="virt-about-kubevirtstorageclassdefaults_{context}"]
-= About storage settings for DataVolumes
+= About storage settings for data volumes
 
-DataVolumes require a defined _access mode_ and _volume mode_ to be created in the web console.
+Data volumes require a defined _access mode_ and _volume mode_ to be created in the web console.
 These storage settings are configured by default with a `ReadWriteOnce` access mode and `Filesystem` volume mode.
 
-You can modify these settings by editing the `kubevirt-storage-class-defaults` ConfigMap in the `openshift-cnv` namespace.
-You can also add settings for other storage classes in order to create DataVolumes in the web console for different storage types.
+You can modify these settings by editing the `kubevirt-storage-class-defaults` config map in the `openshift-cnv` namespace.
+You can also add settings for other storage classes in order to create data volumes in the web console for different storage types.
 
 [NOTE]
 ====
 You must configure storage settings that are supported by the underlying storage.
 ====
 
-All DataVolumes that you create in the web console use the default storage settings unless you specify a storage class that is also defined in the ConfigMap.
+All data volumes that you create in the web console use the default storage settings unless you specify a storage class that is also defined in the config map.
 
 [id="virt-datavolumes-access-modes_{context}"]
 == Access modes
 
-DataVolumes support the following access modes:
+Data volumes support the following access modes:
 
 * `ReadWriteOnce`: The volume can be mounted as read-write by a single node. `ReadWriteOnce` has greater versatility and is the default setting.
 * `ReadWriteMany`: The volume can be mounted as read-write by many nodes. `ReadWriteMany` is required for some features, such as live migration of virtual machines between nodes.
@@ -31,7 +31,7 @@ DataVolumes support the following access modes:
 [id="virt-datavolumes-volume-modes_{context}"]
 == Volume modes
 
-The volume mode defines if a volume is intended to be used with a formatted filesystem or to remain in raw block state. DataVolumes support the following volume modes:
+The volume mode defines if a volume is intended to be used with a formatted file system or to remain in raw block state. Data volumes support the following volume modes:
 
-* `Filesystem`: Creates a filesystem on the DataVolume. This is the default setting.
-* `Block`: Creates a block DataVolume. Only use `Block` if the underlying storage supports it.
+* `Filesystem`: Creates a file system on the data volume. This is the default setting.
+* `Block`: Creates a block data volume. Only use `Block` if the underlying storage supports it.

modules/virt-about-upgrading-virt.adoc

@@ -28,14 +28,14 @@ virtual machine.
 +
 [NOTE]
 ====
-Each virtual machine has a `virt-launcher` Pod that runs the virtual machine
-instance. The `virt-launcher` Pod runs an instance of `libvirt`, which is
+Each virtual machine has a `virt-launcher` pod that runs the virtual machine
+instance. The `virt-launcher` pod runs an instance of `libvirt`, which is
 used to manage the virtual machine process.
 ====
 
 * Upgrading does not interrupt network connections.
 
-* DataVolumes and their associated PersistentVolumeClaims are preserved during
+* Data volumes and their associated persistent volume claims are preserved during
 upgrade.
 +
 [IMPORTANT]

modules/virt-about-vm-snapshots.adoc

@@ -18,7 +18,7 @@ With the offline VM snapshots feature, cluster administrators and application de
 * Restore a VM from a snapshot
 * Delete an existing VM snapshot
 
-== Virtual machine snapshot controller and Custom Resource Definitions (CRDs)
+== Virtual machine snapshot controller and custom resource definitions (CRDs)
 
 The VM snapshot feature introduces three new API objects defined as CRDs for managing snapshots:
 

modules/virt-about-vmis.adoc

@@ -20,5 +20,5 @@ When you delete a VM, the associated VMI is automatically deleted. You delete a
 
 [NOTE]
 ====
-Before you uninstall {VirtProductName}, list and view the standalone VMIs by  using the CLI or the web console. Then, delete any outstanding VMIs.
+Before you uninstall {VirtProductName}, list and view the standalone VMIs by using the CLI or the web console. Then, delete any outstanding VMIs.
 ====

modules/virt-accessing-vmi-ssh.adoc

@@ -15,7 +15,7 @@ machine.
 .Prerequisites
 * You must be in the same project as the VMI.
 * The VMI you want to access must be connected
-to the default Pod network by using the `masquerade` binding method.
+to the default pod network by using the `masquerade` binding method.
 * The VMI you want to access must be running.
 * Install the OpenShift CLI (`oc`).
 
@@ -44,7 +44,7 @@ fedora-vm-ssh   NodePort   127.0.0.1      <none>        22:32551/TCP   6s
 +
 In this example, the service acquired the `32551` port.
 
-. Log in to  the VMI via SSH. Use the `ipAddress` of any of the cluster
+. Log in to the VMI via SSH. Use the `ipAddress` of any of the cluster
 nodes and the port that you found in the previous step:
 +
 [source,terminal]

modules/virt-add-boot-order-web.adoc

@@ -20,7 +20,7 @@ Add items to a boot order list by using the web console.
 
 . Click the pencil icon that is located on the right side of *Boot Order*. If a YAML configuration does not exist, or if this is the first time that you are creating a boot order list, the following message displays: *No resource selected. VM will attempt to boot from disks by order of appearance in YAML file.*
 
-. Click *Add Source* and select a bootable disk or Network Interface Card (NIC) for the virtual machine.
+. Click *Add Source* and select a bootable disk or network interface card (NIC) for the virtual machine.
 
 . Add any additional disks or NICs to the boot order list.
 

modules/virt-add-disk-to-vm.adoc

@@ -32,7 +32,7 @@ Use this procedure to add a virtual disk to a {object}.
 . Click the *Disks* tab.
 . Click *Add Disk* to open the *Add Disk* window.
 . In the *Add Disk* window, specify the *Source*, *Name*, *Size*, *Interface*, *Type*, and *Storage Class*.
-.. Optional: In the *Advanced* list, specify the *Volume Mode* and *Access Mode* for the virtual disk. If you do not specify these parameters, the system uses the default values from the `kubevirt-storage-class-defaults` ConfigMap.
+.. Optional: In the *Advanced* list, specify the *Volume Mode* and *Access Mode* for the virtual disk. If you do not specify these parameters, the system uses the default values from the `kubevirt-storage-class-defaults` config map.
 . Click *Add*.
 
 ifdef::virt-vm[]