Update all the external PRG references with links to the internal PRG document

gocallag · sandrobonazzola · commit 3249141cb3a1 · 2025-04-08T13:40:43.000+02:00
Signed-off-by: geoff o'callaghan &lt;geoffocallaghan@gmail.com&gt;
diff --git a/source/documentation/administration_guide/topics/Cluster_General_Settings_Explained.adoc b/source/documentation/administration_guide/topics/Cluster_General_Settings_Explained.adoc
@@ -23,7 +23,7 @@ On existing clusters, the management network can only be changed using the *Mana
 
 * *ppc64*: For IBM POWER CPU types.
 
-|*CPU Type* |The oldest CPU family in the cluster. For a list of CPU types, see link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#CPU_Requirements_RHV_planning[CPU Requirements] in the _Planning and Prerequisites Guide_. You cannot change this after creating the cluster without significant disruption. Set CPU type to the oldest CPU model in the cluster. Only features present in all models can be used. For both Intel and AMD CPU types, the listed CPU models are in logical order from the oldest to the newest.
+|*CPU Type* |The oldest CPU family in the cluster. For a list of CPU types, see link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#CPU_Requirements_RHV_planning[CPU Requirements] in the _Planning and Prerequisites Guide_. You cannot change this after creating the cluster without significant disruption. Set CPU type to the oldest CPU model in the cluster. Only features present in all models can be used. For both Intel and AMD CPU types, the listed CPU models are in logical order from the oldest to the newest.
 |*Chipset/Firmware Type* a|This setting is only available if the *CPU Architecture* of the cluster is set to *x86_64*. This setting specifies the chipset and firmware type. Options are:
 
 * *Auto Detect*: This setting automatically detects the chipset and firmware type. When *Auto Detect* is selected, the chipset and firmware are determined by the first host up in the cluster.
diff --git a/source/documentation/administration_guide/topics/Preparing_GPU_Passthrough.adoc b/source/documentation/administration_guide/topics/Preparing_GPU_Passthrough.adoc
@@ -6,7 +6,7 @@ The Graphics Processing Unit (GPU) device from a host can be directly assigned t
 
 This procedure is relevant for hosts with either x86_64 or ppc64le architecture.
 
-For more information on the hardware requirements for direct device assignment, see link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#PCI_Device_Requirements_RHV_planning[PCI Device Requirements] in the _Planning and Prerequisites Guide_.
+For more information on the hardware requirements for direct device assignment, see link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#PCI_Device_Requirements_RHV_planning[PCI Device Requirements] in the _Planning and Prerequisites Guide_.
 
 [IMPORTANT]
 ====
diff --git a/source/documentation/common/install/assembly-Installing_the_self-hosted_engine_deployment_host.adoc b/source/documentation/common/install/assembly-Installing_the_self-hosted_engine_deployment_host.adoc
@@ -9,7 +9,7 @@ A self-hosted engine can be deployed from a xref:Installing_Red_Hat_Virtualizati
 
 [IMPORTANT]
 ====
-If you plan to use bonded interfaces for high availability or VLANs to separate different types of traffic (for example, for storage or management connections), you should configure them on the host before beginning the self-hosted engine deployment. See link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#networking-recommendations[Networking Recommendations] in the _Planning and Prerequisites Guide_.
+If you plan to use bonded interfaces for high availability or VLANs to separate different types of traffic (for example, for storage or management connections), you should configure them on the host before beginning the self-hosted engine deployment. See link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#networking-recommendations[Networking Recommendations] in the _Planning and Prerequisites Guide_.
 ====
 
 include::proc-Installing_Red_Hat_Virtualization_Hosts.adoc[leveloffset=+1]
diff --git a/source/documentation/common/install/proc-Configuring_a_Host_for_PCI_Passthrough.adoc b/source/documentation/common/install/proc-Configuring_a_Host_for_PCI_Passthrough.adoc
@@ -9,7 +9,7 @@ Enabling PCI passthrough allows a virtual machine to use a host device as if the
 
 .Prerequisites
 
-* Ensure that the host hardware meets the requirements for PCI device passthrough and assignment. See link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#PCI_Device_Requirements_RHV_planning[PCI Device Requirements] for more information.
+* Ensure that the host hardware meets the requirements for PCI device passthrough and assignment. See link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#PCI_Device_Requirements_RHV_planning[PCI Device Requirements] for more information.
 
 .Configuring a Host for PCI Passthrough
 
diff --git a/source/documentation/common/install/proc-Installing_Red_Hat_Enterprise_Linux_Hosts.adoc b/source/documentation/common/install/proc-Installing_Red_Hat_Enterprise_Linux_Hosts.adoc
@@ -13,7 +13,7 @@ endif::[]
 
 For detailed installation instructions, see the link:{URL_rhel_docs_latest}html/performing_a_standard_rhel_installation/index.html[_Performing a standard {enterprise-linux-shortname} installation_].
 
-The host must meet the minimum link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#host-requirements[host requirements].
+The host must meet the minimum link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#host-requirements[host requirements].
 
 include::../upgrade/snip_WARNING-detach_data_storage.adoc[]
 
diff --git a/source/documentation/common/install/proc-Installing_Red_Hat_Virtualization_Hosts.adoc b/source/documentation/common/install/proc-Installing_Red_Hat_Virtualization_Hosts.adoc
@@ -7,7 +7,7 @@
 {hypervisor-shortname} supports NIST 800-53 partitioning requirements to improve security. {hypervisor-shortname} uses a NIST 800-53 partition layout by default.
 
 ifdef::rhv-doc[]
-The host must meet the minimum  link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#host-requirements[host requirements].
+The host must meet the minimum  link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#host-requirements[host requirements].
 endif::rhv-doc[]
 
 ifdef::ovirt-doc[]
diff --git a/source/documentation/common/upgrade/snip-RHV_upgrade_prerequisites.adoc b/source/documentation/common/upgrade/snip-RHV_upgrade_prerequisites.adoc
@@ -18,7 +18,7 @@ endif::upgrade[]
 // This link must always be the latest version.
 * Ensure your environment meets the requirements for {virt-product-fullname} {vername_rhv}.
 ifdef::rhv-doc[]
-For a complete list of prerequisites, see the link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#RHV_requirements[__Planning and Prerequisites Guide__].
+For a complete list of prerequisites, see the link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#RHV_requirements[__Planning and Prerequisites Guide__].
 endif::rhv-doc[]
 
 * When upgrading {virt-product-fullname} {engine-name}, it is recommended that you use one of the existing hosts. If you decide to use a new host, you must assign a unique name to the new host and then add it to the existing cluster before you begin the upgrade procedure.
diff --git a/source/documentation/doc-Product_Guide/asm-Components.adoc b/source/documentation/doc-Product_Guide/asm-Components.adoc
@@ -30,7 +30,7 @@ See: link:{URL_virt_product_docs}{URL_format}administration_guide/index#chap-Hos
 
 Setting up storage and attaching it to your {virt-product-fullname} environment is a prerequisite before you can start creating end-user virtual machines. {virt-product-fullname} has three types of storage domains; however, only the data domain is now fully supported:
 
-* The data domain contains all the data associated with virtual machines. The data domain supports all storage types that are supported for use with {virt-product-fullname}. See link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#storage-types[Storage Types] in the _Planning and Prerequisites Guide_. For information on uploading to a data domain, see link:{URL_virt_product_docs}{URL_format}administration_guide/index#Uploading_Images_to_a_Data_Storage_Domain_storage_tasks[Uploading Images to a Data Storage Domain] in the __Administration Guide__.
+* The data domain contains all the data associated with virtual machines. The data domain supports all storage types that are supported for use with {virt-product-fullname}. See link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#storage-types[Storage Types] in the _Planning and Prerequisites Guide_. For information on uploading to a data domain, see link:{URL_virt_product_docs}{URL_format}administration_guide/index#Uploading_Images_to_a_Data_Storage_Domain_storage_tasks[Uploading Images to a Data Storage Domain] in the __Administration Guide__.
 
 * The ISO domain is a deprecated storage domain type that was used to store ISO files for installing a virtual machine operating system or additional applications, such as the Windows guest agents and drivers. Virtual machine images can now be uploaded to data domains instead. For information on uploading to an ISO domain, see link:{URL_virt_product_docs}{URL_format}administration_guide/index#Copy_ISO_to_ISO_domain[Uploading images to an ISO domain] in the __Administration Guide__.
 
diff --git a/source/documentation/doc-Release_Notes/topics/ref-Removed_Features_RHV.adoc b/source/documentation/doc-Release_Notes/topics/ref-Removed_Features_RHV.adoc
@@ -27,7 +27,7 @@ Administrators can also send metrics and logs to a standalone Elasticsearch inst
 *iptables* is only supported on {enterprise-linux} 7 hosts, in clusters with compatibility version 4.2 or 4.3. You can only add {enterprise-linux} 8 hosts to clusters with firewall type *firewalld*.
 ====
 
-|Conroe, Penryn, Opteron G1, Opteron G2, and Opteron G3 CPU types |Use link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#CPU_Requirements_RHV_planning[newer CPU types].
+|Conroe, Penryn, Opteron G1, Opteron G2, and Opteron G3 CPU types |Use link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#CPU_Requirements_RHV_planning[newer CPU types].
 |link:https://access.redhat.com/solutions/3307851[IBRS CPU types] |Use link:https://access.redhat.com/articles/3311301[newer fixes].
 
 |3.6, 4.0 and 4.1 cluster compatibility versions |Use a newer cluster compatibility version. link:{URL_virt_product_docs}{URL_format}administration_guide/index#Changing_the_Cluster_Compatibility_Version_admin[Upgrade the compatibility version] of existing clusters.
diff --git a/source/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/index.adoc b/source/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/index.adoc
@@ -17,7 +17,7 @@ Hosts that can run the {engine-name} virtual machine are referred to as self-hos
 
 A storage domain dedicated to the {engine-name} virtual machine is referred to as the self-hosted engine storage domain. This storage domain is created by the installation script, so the underlying storage must be prepared before beginning the installation.
 
-See the link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration. See link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#self-hosted-engine-recommendations[Self-Hosted Engine Recommendations] for configuration specific to a self-hosted engine environment.
+See the link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration. See link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#self-hosted-engine-recommendations[Self-Hosted Engine Recommendations] for configuration specific to a self-hosted engine environment.
 
 [discrete]
 include::common/arch/con-RHV_key_components.adoc[leveloffset=+1]
diff --git a/source/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/master.adoc b/source/documentation/installing_ovirt_as_a_self-hosted_engine_using_the_command_line/master.adoc
@@ -11,7 +11,7 @@ Hosts that can run the {engine-name} virtual machine are referred to as self-hos
 
 A storage domain dedicated to the {engine-name} virtual machine is referred to as the self-hosted engine storage domain. This storage domain is created by the installation script, so the underlying storage must be prepared before beginning the installation.
 
-See the link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration. See link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#self-hosted-engine-recommendations[Self-Hosted Engine Recommendations] for configuration specific to a self-hosted engine environment.
+See the link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration. See link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#self-hosted-engine-recommendations[Self-Hosted Engine Recommendations] for configuration specific to a self-hosted engine environment.
 
 [discrete]
 include::common/arch/con-RHV_key_components.adoc[leveloffset=+1]
diff --git a/source/documentation/installing_ovirt_as_a_standalone_manager_with_local_databases/index.adoc b/source/documentation/installing_ovirt_as_a_standalone_manager_with_local_databases/index.adoc
@@ -15,7 +15,7 @@ Standalone {engine-name} installation is manual and customizable. You must insta
 
 In a local database environment, the {engine-name} database and Data Warehouse database can be created automatically by the {engine-name} configuration script. Alternatively, you can create these databases manually on the {engine-name} machine before running `engine-setup`.
 
-See the link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration.
+See the link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration.
 
 [discrete]
 include::common/arch/con-RHV_key_components.adoc[leveloffset=+1]
diff --git a/source/documentation/installing_ovirt_as_a_standalone_manager_with_local_databases/master.adoc b/source/documentation/installing_ovirt_as_a_standalone_manager_with_local_databases/master.adoc
@@ -9,7 +9,7 @@ Standalone {engine-name} installation is manual and customizable. You must insta
 
 In a local database environment, the {engine-name} database and Data Warehouse database can be created automatically by the {engine-name} configuration script. Alternatively, you can create these databases manually on the {engine-name} machine before running `engine-setup`.
 
-See the link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration.
+See the link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration.
 
 [discrete]
 include::common/arch/con-RHV_key_components.adoc[leveloffset=+1]
diff --git a/source/documentation/installing_ovirt_as_a_standalone_manager_with_remote_databases/index.adoc b/source/documentation/installing_ovirt_as_a_standalone_manager_with_remote_databases/index.adoc
@@ -15,7 +15,7 @@ Standalone {engine-name} installation is manual and customizable. You must insta
 
 To install the {engine-name} with a remote {engine-name} database, manually create the database on the remote machine before running `engine-setup`. To install the Data Warehouse database on a remote machine, run the Data Warehouse configuration script (`ovirt-engine-dwh-setup`) on the remote machine. This script installs the Data Warehouse service and can create the Data Warehouse database automatically.
 
-See the link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration.
+See the link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration.
 
 [discrete]
 include::common/arch/con-RHV_key_components.adoc[leveloffset=+1]
diff --git a/source/documentation/installing_ovirt_as_a_standalone_manager_with_remote_databases/master.adoc b/source/documentation/installing_ovirt_as_a_standalone_manager_with_remote_databases/master.adoc
@@ -9,7 +9,7 @@ Standalone {engine-name} installation is manual and customizable. You must insta
 
 To install the {engine-name} with a remote {engine-name} database, manually create the database on the remote machine before running `engine-setup`. To install the Data Warehouse database on a remote machine, run the Data Warehouse configuration script (`ovirt-engine-dwh-setup`) on the remote machine. This script installs the Data Warehouse service and can create the Data Warehouse database automatically.
 
-See the link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration.
+See the link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index[_Planning and Prerequisites Guide_] for information on environment options and recommended configuration.
 
 [discrete]
 include::common/arch/con-RHV_key_components.adoc[leveloffset=+1]
diff --git a/source/documentation/virtual_machine_management_guide/topics/Opening_a_Serial_Console_to_a_Virtual_Machine.adoc b/source/documentation/virtual_machine_management_guide/topics/Opening_a_Serial_Console_to_a_Virtual_Machine.adoc
@@ -13,8 +13,8 @@ The serial console is accessed through TCP port 2222 on the {engine-name}. This
 
 You must configure the following firewall rules to allow a serial console:
 
-* link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#RHV-manager-firewall-requirements_RHV_planning[Rule "M3"] for the {engine-name} firewall
-* link:{URL_downstream_virt_product_docs}planning_and_prerequisites_guide/index#host-firewall-requirements_RHV_planning[Rule "H2"] for the host firewall
+* link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#RHV-manager-firewall-requirements_RHV_planning[Rule "M3"] for the {engine-name} firewall
+* link:{URL_virt_product_docs}{URL_format}planning_and_prerequisites_guide/index#host-firewall-requirements_RHV_planning[Rule "H2"] for the host firewall
 
 The serial console relies on the `ovirt-vmconsole` package and the `ovirt-vmconsole-proxy` on the {engine-name} and the `ovirt-vmconsole` package and the `ovirt-vmconsole-host` package on the hosts.
 
