Doc: Replace absolute links with relative ones

docs/guides/VLAN-trunking-vm.md

@@ -26,7 +26,7 @@ This document is about the alternative approach, but a quick summary of how this
 * Make sure the pif connected to your xcp-ng server is carrying all the required tagged vlans
 * Within XO or XCP Center, create multiple networks off of the pif, adding the VLAN tag as needed for each VLAN
 * For each VLAN you want your router to route for, add a vif for that specific VLAN to the VM
-* For pfSense, disable TX offloading for each vif added and reboot the VM. This [page](https://github.com/xcp-ng/xcp/wiki/pfSense-in-a-VM) will fully explain all of the config changes required when running pfSense in xcp-ng.
+* For pfSense, disable TX offloading for each vif added and reboot the VM. This [page](pfsense) will fully explain all of the config changes required when running pfSense in xcp-ng.
 
 ## Adding VLAN Trunk to VM
 

docs/guides/pfsense.md

@@ -40,7 +40,7 @@ Now is the most important step: we must disable TX checksum offload on the virtu
 The solution is to simply turn off checksum-offload on the virtual xen interfaces for pfSense in the TX direction only (TX towards the VM itself). Then the packets will be checksummed like normal and `pf` will no longer complain.
 
 :::tip
-Disabling checksum offloading is only necessary for virtual interfaces. When using [PCI Passthrough](https://github.com/xcp-ng/xcp/wiki/PCI-Passtrough) to provide a VM with direct access to physical or virtual (using [SR-IOV](https://en.wikipedia.org/wiki/Single-root_input/output_virtualization)) devices it is unnecessary to disable TX checksum offloading on any interfaces on those devices.
+Disabling checksum offloading is only necessary for virtual interfaces. When using [PCI Passthrough](../compute/#-pci-passthrough) to provide a VM with direct access to physical or virtual (using [SR-IOV](https://en.wikipedia.org/wiki/Single-root_input/output_virtualization)) devices it is unnecessary to disable TX checksum offloading on any interfaces on those devices.
 :::
 
 :::warning

docs/guides/xcpng-in-a-vm.md

@@ -10,10 +10,10 @@ This practice is not recommended for production, nested virtualization has only
 
 Here is the list of hypervisors on which you can try XCP-ng :
 
-* [XCP-ng](https://github.com/xcp-ng/xcp/wiki/Testing-XCP-ng-in-Virtual-Machine-%28Nested-Virtualization%29/#nested-xcp-ng-using-xcp-ng)
-* [VMware ESXi & Workstation](https://github.com/xcp-ng/xcp/wiki/Testing-XCP-ng-in-Virtual-Machine-(Nested-Virtualization)#nested-xcp-ng-using-vmware-esxi-and-workstation)
-* [Hyper-V 2016](https://github.com/xcp-ng/xcp/wiki/Testing-XCP-ng-in-Virtual-Machine-(Nested-Virtualization)#nested-xcp-ng-using-microsoft-hyper-v-windows-10---windows-server-2016)
-* [QEMU/KVM](https://github.com/xcp-ng/xcp/wiki/Testing-XCP-ng-in-Virtual-Machine-(Nested-Virtualization)#nested-xcp-ng-using-qemukvm)
+* [XCP-ng](#nested-xcp-ng-using-xcp-ng)
+* [VMware ESXi & Workstation](#nested-xcp-ng-using-vmware-esxi-and-workstation)
+* [Hyper-V 2016](#nested-xcp-ng-using-microsoft-hyper-v-windows-10---windows-server-2016)
+* [QEMU/KVM](#nested-xcp-ng-using-qemukvm)
 * [Virtualbox](https://www.virtualbox.org) (Nested Virtualisation implemented only in v6.1.x and above - [https://www.virtualbox.org/ticket/4032](https://www.virtualbox.org/ticket/4032))
 
 ## Nested XCP-ng using XCP-ng

docs/project/development-process/ISO-modification.md

@@ -119,7 +119,7 @@ Then you can either read the next section or jump to "Build a new ISO image with
 
 You may want the installer to install more packages, or updated packages.
 
-Read [the usual warnings about the installation of third party RPMs on XCP-ng.](https://github.com/xcp-ng/xcp/wiki/Updates-Howto#be-cautious-with-third-party-repositories-and-packages)
+Read [the usual warnings about the installation of third party RPMs on XCP-ng.](../../management/updates/#be-cautious-with-third-party-repositories-and-packages)
 
 To achieve this:
 * Change the RPMs in the `Packages/` directory. If you add new packages, be careful about dependencies, else they'll fail to install and the whole installation process will fail.

docs/project/development-process/tests.md

@@ -14,9 +14,9 @@ For every release it's important to check if everything works correctly on diffe
 
 Not everyone can test everything, but everything must get tested in the end.
 
-If anything goes wrong, try to isolate [the logs](https://github.com/xcp-ng/xcp/wiki/Logfiles) related to that failure (and what happened just before), and try to identify a way to reproduce if possible. You can also [create a full status report](https://github.com/xcp-ng/xcp/wiki/Logfiles#produce-a-status-report) to let someone else try to identify the issue.
+If anything goes wrong, try to isolate [the logs](../../troubleshooting/log-files) related to that failure (and what happened just before), and try to identify a way to reproduce if possible. You can also [create a full status report](../../troubleshooting/log-files/#produce-a-status-report) to let someone else try to identify the issue.
 
-Give priority to tests on actual hardware, but if you don't have any hardware available for those, then [testing in a nested environment](https://github.com/xcp-ng/xcp/wiki/Testing-XCP-ng-in-Virtual-Machine-%28Nested-Virtualization%29) is useful too.
+Give priority to tests on actual hardware, but if you don't have any hardware available for those, then [testing in a nested environment](../compute/#-nested-virtualization) is useful too.
 
 ## Basic tests
 
@@ -30,7 +30,7 @@ Give priority to tests on actual hardware, but if you don't have any hardware av
 - verify migration of a VM from an old host to (this) release one
 - verify migration of a VM from a newest host to the old one (this test should be fail)
 - verify change of the pool master from an host to another
-- [check your logs](https://github.com/xcp-ng/xcp/wiki/Logfiles) for uncommon info or warnings.
+- [check your logs](../../troubleshooting/log-files) for uncommon info or warnings.
 - (add more here...)
 
 ## Installer
@@ -86,9 +86,9 @@ and
 This one is the most important and not the easiest to test. During a pool upgrade, the hosts of your pool have heterogeneous versions of XAPI, Xen and other components, and many features are disabled. This is a situation that is meant to be as short as possible. When live migration fails at this stage, it is never a nice situation.
 **That's why this is the kind of live migration that requires the most testing**.
 
-Note: if you don't have the hardware and VMs to test this, you can create a virtual pool using [nested virtualization](https://github.com/xcp-ng/xcp/wiki/Testing-XCP-ng-in-Virtual-Machine-%28Nested-Virtualization%29).
+Note: if you don't have the hardware and VMs to test this, you can create a virtual pool using [nested virtualization](../../compute/#-nested-virtualization).
 
-If anything fails and you absolutely need to move forward, we advise to produce and save a full [status report](https://github.com/xcp-ng/xcp/wiki/Logfiles#produce-a-status-report) on both hosts involved before continuing.
+If anything fails and you absolutely need to move forward, we advise to produce and save a full [status report](../../troubleshooting/log-files/#produce-a-status-report) on both hosts involved before continuing.
 
 Testing the upgrade from the N-1 release is very important. Testing from older releases is important too because the likeliness of a breakage is higher.