CNV-17386: Consolidate support files

Signed-off-by: Avital Pinnick <[email protected]>

Author: apinnick

_topic_maps/_topic_map.yml

@@ -3561,8 +3561,6 @@ Topics:
       File: virt-configuring-vgpu-passthrough
     - Name: Configuring mediated devices
       File: virt-configuring-mediated-devices
-    - Name: Configuring a watchdog device
-      File: virt-configuring-a-watchdog
     - Name: Automatic importing and updating of pre-defined boot sources
       File: virt-automatic-bootsource-updates
     - Name: Enabling descheduler evictions on virtual machines
@@ -3702,35 +3700,32 @@ Topics:
   - Name: Preventing node reconciliation
     File: virt-preventing-node-reconciliation
 # Removed the Node Networking content from the topic map because this section is now part of the OCP docs
-# Logging, events, and monitoring
+# Support, was Logging, events, and monitoring
 - Name: Support
   Dir: support
   Topics:
-  - Name: Viewing OpenShift Virtualization logs
-    File: virt-logs
-  - Name: Viewing events
-    File: virt-events
-  - Name: Monitoring live migration
-    File: virt-monitor-vmi-migration
-  - Name: Diagnosing data volumes using events and conditions
-    File: virt-diagnosing-datavolumes-using-events-and-conditions
-  - Name: Monitoring virtual machine health with health probes
-    File: virt-monitoring-vm-health
-  - Name: Viewing cluster information
-    File: virt-using-dashboard-to-get-cluster-info
-  - Name: OpenShift cluster monitoring, logging, and Telemetry
-    File: virt-openshift-cluster-monitoring
-  - Name: Running OpenShift cluster checkups
-    File: virt-running-cluster-checkups
-  - Name: Prometheus queries for virtual resources
-    File: virt-prometheus-queries
-  - Name: Exposing custom metrics for virtual machines
-    File: virt-exposing-custom-metrics-for-vms
-  - Name: OpenShift Virtualization runbooks
-    File: virt-runbooks
+  - Name: Support overview
+    File: virt-support-overview
   - Name: Collecting data for Red Hat Support
     File: virt-collecting-virt-data
     Distros: openshift-enterprise
+  - Name: Monitoring
+    Dir: monitoring
+    Topics:
+    - Name: Monitoring overview
+      File: virt-monitoring-overview
+    - Name: OpenShift cluster checkup framework
+      File: virt-running-cluster-checkups
+    - Name: Prometheus queries for virtual resources
+      File: virt-prometheus-queries
+    - Name: Virtual machine custom metrics
+      File: virt-exposing-custom-metrics-for-vms
+    - Name: Virtual machine health checks
+      File: virt-monitoring-vm-health
+  - Name: Troubleshooting
+    File: virt-troubleshooting
+  - Name: Runbooks
+    File: virt-runbooks
 - Name: Backup and restore
   Dir: backup_restore
   Topics:

modules/cluster-logging-about-components.adoc

@@ -1,12 +1,6 @@
 // Module included in the following assemblies:
 //
 // * logging/cluster-logging.adoc
-// * virt/support/virt-openshift-cluster-monitoring.adoc
-
-
-ifeval::["{context}" == "virt-openshift-cluster-monitoring"]
-:virt-logging:
-endif::[]
 
 :_content-type: CONCEPT
 [id="cluster-logging-about-components_{context}"]
@@ -21,10 +15,3 @@ The major components of the {logging} are:
 * log store - This is where the logs are stored. The default implementation is Elasticsearch. You can use the default Elasticsearch log store or forward logs to external log stores. The default log store is optimized and tested for short-term storage.
 * visualization - This is the UI component you can use to view logs, graphs, charts, and so forth. The current implementation is Kibana.
 
-ifndef::virt-logging[]
-This document might refer to log store or Elasticsearch, visualization or Kibana, collection or Fluentd, interchangeably, except where noted.
-endif::virt-logging[]
-
-ifeval::["{context}" == "virt-openshift-cluster-monitoring"]
-:!virt-logging:
-endif::[]

modules/monitoring-about-cluster-monitoring.adoc

@@ -1,6 +1,5 @@
 // Module included in the following assemblies:
 //
-// * virt/support/virt-openshift-cluster-monitoring.adoc
 // * monitoring/monitoring-overview.adoc
 
 // This module uses a conditionalized title so that the module

modules/telemetry-about-telemetry.adoc

@@ -1,13 +1,12 @@
 // Module included in the following assemblies:
 //
-// * virt/support/virt-openshift-cluster-monitoring.adoc
 // * support/remote_health_monitoring/about-remote-health-monitoring.adoc
 
 :_content-type: CONCEPT
 [id="telemetry-about-telemetry_{context}"]
 = About Telemetry
 
-Telemetry sends a carefully chosen subset of the cluster monitoring metrics to Red Hat. The Telemeter Client fetches the metrics values every four minutes and thirty seconds and uploads the data to Red Hat. These metrics are described in this document. 
+Telemetry sends a carefully chosen subset of the cluster monitoring metrics to Red Hat. The Telemeter Client fetches the metrics values every four minutes and thirty seconds and uploads the data to Red Hat. These metrics are described in this document.
 
 This stream of data is used by Red Hat to monitor the clusters in real-time and to react as necessary to problems that impact our customers. It also allows Red Hat to roll out {product-title} upgrades to customers to minimize service impact and continuously improve the upgrade experience.
 

modules/telemetry-what-information-is-collected.adoc

@@ -1,12 +1,8 @@
 // Module included in the following assemblies:
 //
-// * virt/support/virt-openshift-cluster-monitoring.adoc
 // * support/remote_health_monitoring/about-remote-health-monitoring.adoc
 
-ifeval::["{context}" == "virt-openshift-cluster-monitoring"]
-:virt-cluster:
-endif::[]
-
+:_content-type: REFERENCE
 [id="what-information-is-collected_{context}"]
 = Information collected by Telemetry
 
@@ -35,6 +31,3 @@ endif::openshift-dedicated[]
 
 Telemetry does not collect identifying information such as user names or passwords. Red Hat does not intend to collect personal information. If Red Hat discovers that personal information has been inadvertently received, Red Hat will delete such information. To the extent that any telemetry data constitutes personal data, please refer to the link:https://www.redhat.com/en/about/privacy-policy[Red Hat Privacy Statement] for more information about Red Hat's privacy practices.
 
-ifeval::["{context}" == "virt-openshift-cluster-monitoring"]
-:!virt-cluster:
-endif::[]

modules/virt-about-conditions-and-events.adoc renamed to modules/virt-about-dv-conditions-and-events.adoc

@@ -1,20 +1,20 @@
 // Module included in the following assemblies:
 //
-// * virt/support/virt-diagnosing-datavolumes-using-events-and-conditions.adoc
+// * virt/support/virt-troubleshooting.adoc
 
 :_content-type: CONCEPT
-[id="virt-about-conditions-and-events.adoc_{context}"]
-= About conditions and events
+[id="virt-about-dv-conditions-and-events.adoc_{context}"]
+= About data volume conditions and events
 
-Diagnose data volume issues by examining the output of the `Conditions` and `Events` sections
+You can diagnose data volume issues by examining the output of the `Conditions` and `Events` sections
 generated by the command:
 
 [source,terminal]
 ----
 $ oc describe dv <DataVolume>
 ----
 
-There are three `Types` in the `Conditions` section that display:
+The `Conditions` section displays the following `Types`:
 
 * `Bound`
 * `Running`
@@ -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.
+An event is generated when the `Status`, `Reason`, or `Message` changes.
 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

modules/virt-about-the-overview-dashboard.adoc

@@ -1,6 +1,5 @@
 // Module included in the following assemblies:
 //
-// * virt/support/virt-using-dashboard-to-get-cluster-info.adoc
 // * web_console/using-dashboard-to-get-cluster-information.adoc
 
 ifeval::["{context}" == "virt-using-dashboard-to-get-cluster-info"]

modules/virt-about-vm-events.adoc

@@ -1,9 +1,9 @@
 // Module included in the following assemblies:
 //
-// * virt/support/virt-analyzing-datavolumes-using-events-and-conditions.adoc
+// * virt/support/virt-troubleshooting.adoc
 
 [id="virt-analyzing-datavolume-conditions-and-events_{context}"]
-= Analyzing data volumes using conditions and events
+= Analyzing data volume conditions and events
 
 By inspecting the `Conditions` and `Events` sections generated by the `describe`
 command, you determine the state of the data volume
@@ -16,7 +16,7 @@ There are many different combinations of conditions. Each must be evaluated in i
 
 Examples of various combinations follow.
 
-* `Bound` – A successfully bound PVC displays in this example.
+* `Bound` - A successfully bound PVC displays in this example.
 +
 Note that the `Type` is `Bound`, so the `Status` is `True`.
 If the PVC is not bound, the `Status` is `False`.
@@ -33,21 +33,21 @@ in this case `datavolume-controller`:
 [source,terminal]
 ----
 Status:
-	Conditions:
-		Last Heart Beat Time:  2020-07-15T03:58:24Z
-		Last Transition Time:  2020-07-15T03:58:24Z
-		Message:               PVC win10-rootdisk Bound
-		Reason:                Bound
-		Status:                True
-		Type:                  Bound
-
-	Events:
-		Type     Reason     Age    From                   Message
-		----     ------     ----   ----                   -------
-		Normal   Bound      24s    datavolume-controller  PVC example-dv Bound
+  Conditions:
+    Last Heart Beat Time:  2020-07-15T03:58:24Z
+    Last Transition Time:  2020-07-15T03:58:24Z
+    Message:               PVC win10-rootdisk Bound
+    Reason:                Bound
+    Status:                True
+    Type:                  Bound
+...
+  Events:
+    Type     Reason     Age    From                   Message
+    ----     ------     ----   ----                   -------
+    Normal   Bound      24s    datavolume-controller  PVC example-dv Bound
 ----
 
-* `Running` – In this case, note that `Type` is `Running` and `Status` is `False`,
+* `Running` - In this case, note that `Type` is `Running` and `Status` is `False`,
 indicating that an event has occurred that caused an attempted
 operation to fail, changing the Status from `True` to `False`.
 +
@@ -67,19 +67,19 @@ attempting to access the data volume:
 [source,terminal]
 ----
 Status:
-	 Conditions:
-		 Last Heart Beat Time:  2020-07-15T04:31:39Z
-		 Last Transition Time:  2020-07-15T04:31:39Z
-		 Message:               Import Complete
-		 Reason:                Completed
-		 Status:                False
-		 Type:                  Running
-
-	Events:
-		Type     Reason           Age                From                   Message
-		----     ------           ----               ----                   -------
-		Warning  Error            12s (x2 over 14s)  datavolume-controller  Unable to connect
-		to http data source: expected status code 200, got 404. Status: 404 Not Found
+  Conditions:
+    Last Heart Beat Time:  2020-07-15T04:31:39Z
+    Last Transition Time:  2020-07-15T04:31:39Z
+    Message:               Import Complete
+    Reason:                Completed
+    Status:                False
+    Type:                  Running
+...
+  Events:
+    Type     Reason       Age                From                   Message
+    ----     ------       ----               ----                   -------
+    Warning  Error        12s (x2 over 14s)  datavolume-controller  Unable to connect
+    to http data source: expected status code 200, got 404. Status: 404 Not Found
 ----
 
 * `Ready` – If `Type` is `Ready` and `Status` is `True`, then the data volume is ready
@@ -90,9 +90,9 @@ used, the `Status` is `False`:
 [source,terminal]
 ----
 Status:
-	 Conditions:
-		 Last Heart Beat Time: 2020-07-15T04:31:39Z
-		 Last Transition Time:  2020-07-15T04:31:39Z
-		 Status:                True
-		 Type:                  Ready
+  Conditions:
+    Last Heart Beat Time: 2020-07-15T04:31:39Z
+    Last Transition Time:  2020-07-15T04:31:39Z
+    Status:                True
+    Type:                  Ready
 ----