docs(project): remove the 'Project resources' page

Its links (blog, changelog, roadmap) are on the What's new page, where
its URL now redirects.

@xen-orchestra/web/src/shared/components/modals/FirstConnectionModal.vue

@@ -10,7 +10,7 @@
           <I18nT keypath="popup-first-connection-default-interface">
             <template #documentationLink>
               <UiLink
-                href="https://docs.xen-orchestra.com/getting-started/configuration#using-xo-5-as-the-default-interface"
+                href="https://docs.xen-orchestra.com/getting-started/installation#change-the-default-interface"
                 size="medium"
               >
                 {{ t('popup-first-connection-follow-this-guide') }}

@xen-orchestra/web/src/shared/constants.ts

@@ -8,9 +8,9 @@ export const XO_LINKS = {
   COMMUNITY: 'https://xcp-ng.org/forum/category/12/xen-orchestra',
   DOC: 'https://docs.xen-orchestra.com',
   DOC_SDN_CONTROLLER_MIGRATION:
-    'https://docs.xen-orchestra.com/manage-your-infrastructure/sdn_controller#migration-path',
+    'https://docs.xen-orchestra.com/manage-your-infrastructure/networking/sdn_controller#migration-path',
   DOC_SDN_CONTROLLER_XAPI_PLUGIN:
-    'https://docs.xen-orchestra.com/manage-your-infrastructure/sdn_controller#xapi-plugin',
+    'https://docs.xen-orchestra.com/manage-your-infrastructure/networking/sdn_controller#xapi-plugin',
   TRANSLATION: 'https://translate.vates.tech/engage/xen-orchestra/',
 }
 

docs/docs/airgap.md

@@ -19,11 +19,11 @@ In this scenario, you will need a QA/pre-production XCP-ng pool with Internet ac
 
 ### Deployment
 
-[Follow the standard procedure](./getting-started/installation.md) to deploy the XOA on your pool with Internet access.
+[Follow the standard procedure](./getting-started/installation/xoa.md) to deploy the XOA on your pool with Internet access.
 
-Make sure that your appliance is [properly registered](./getting-started/installation.md#registration) and [up-to-date](./getting-started/updater.md).
+Make sure that your appliance is [properly registered](./getting-started/installation/xoa.md#registration) and [up-to-date](./getting-started/updater.md).
 
-It's also good to take a quick look at [the XOA check](./getting-started/troubleshooting.md#first-reflex-xoa-check) to detect issues early.
+It's also good to take a quick look at [the XOA check](./support-and-reference/troubleshooting.md#first-reflex-xoa-check) to detect issues early.
 
 When everything is good, you can shutdown your XOA and export it:
 

docs/docs/automation/_category_.json

@@ -1,8 +1,9 @@
 {
-    "label": "Automation",
-    "position": 8,
-    "link": {
-      "type": "generated-index",
-      "description": "Various tools to automate your workflow in XO"
-    }
-  }
+  "label": "Automation & API",
+  "position": 10,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/automation",
+    "description": "Various tools to automate your workflow in XO"
+  }
+}

docs/docs/automation/ansible.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 1
+---
+
 # Ansible dynamic inventory
 
 ## Introduction

docs/docs/automation/kubernetes.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 2
+---
+
 # Deploy Kubernetes with recipes
 
 ## Introduction

docs/docs/automation/mcp.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 3
+---
+
 # Model Context Protocol (MCP)
 
 ## What is MCP?

docs/docs/automation/packer-provider.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 4
+---
+
 # Packer plugin
 
 ## Introduction

docs/docs/automation/powershell-module.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 5
+---
+
 # PowerShell module
 
 ## Introduction

docs/docs/automation/pulumi-provider.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 6
+---
+
 # Pulumi provider
 
 ## Introduction

docs/docs/automation/restapi.md

@@ -1,10 +1,10 @@
 ---
-sidebar_position: 1
+sidebar_position: 7
 ---
 
 # REST API
 
-The Xen Orchestra REST API is the modern, public way to automate your infrastructure. We built it from scratch, next to [our historical JSON-RPC API](../getting-started/architecture.md#apis), to be [REST-like](https://en.wikipedia.org/wiki/Representational_state_transfer) and usable with a plain `curl` command. It is now almost complete: nearly all of Xen Orchestra's capabilities are exposed through it, and it is ready to be used in production. It is also the API we are building the future of Xen Orchestra on, so it is the right choice for any new automation.
+The Xen Orchestra REST API is the modern, public way to automate your infrastructure. We built it from scratch, next to [our historical JSON-RPC API](../core-concepts/architecture.md#apis), to be [REST-like](https://en.wikipedia.org/wiki/Representational_state_transfer) and usable with a plain `curl` command. It is now almost complete: nearly all of Xen Orchestra's capabilities are exposed through it, and it is ready to be used in production. It is also the API we are building the future of Xen Orchestra on, so it is the right choice for any new automation.
 
 This page teaches the principles: how to authenticate, then how each HTTP verb behaves, with one example per pattern. For the complete, always up-to-date list of endpoints, use the [built-in Swagger UI](#openapiswagger) shipped with your Xen Orchestra: it documents every route and lets you try them from your browser.
 
@@ -22,7 +22,7 @@ Endpoints require authentication. Two forms are accepted, and you must pick exac
 An invalid token or invalid credentials get a `401 Unauthorized` response.
 
 :::tip
-Admin users have access to all REST API endpoints. Non-admin users can use the REST API according to the [RBAC](../users-and-access/rbac.md) permissions defined on their account.
+Admin users have access to all REST API endpoints. Non-admin users can use the REST API according to the [RBAC](../security/user-management/rbac.md) permissions defined on their account.
 :::
 
 For scripts and integrations, prefer a token: it does not expose your password and it can be revoked at any time.

docs/docs/automation/terraform-provider.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 8
+---
+
 # Terraform provider
 
 ## Introduction

docs/docs/backups-and-dr/_category_.json

@@ -1,8 +1,9 @@
 {
-    "label": "Backups and DR",
-    "position": 5,
-    "link": {
-      "type": "generated-index",
-      "description": "Detailed information on backups and disaster recovery"
-    }
-  }
+  "label": "Backups",
+  "position": 7,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/backups-and-dr",
+    "description": "Detailed information on backups and disaster recovery"
+  }
+}

docs/docs/backups-and-dr/backup-features-and-settings.md

@@ -14,8 +14,8 @@ The two replication job types now have clearer names, but the XO 5 screens below
 
 | Current name                                                       | Former name, still shown in XO 5 |
 | ------------------------------------------------------------------ | -------------------------------- |
-| [Full replication](./backup-types/full_replication.md)                          | Disaster Recovery (DR)           |
-| [Incremental replication](./backup-types/incremental_replication.md)               | Continuous Replication (CR)      |
+| [Full replication](../replication/full_replication.md)                          | Disaster Recovery (DR)           |
+| [Incremental replication](../replication/incremental_replication.md)               | Continuous Replication (CR)      |
 
 Nothing changed in behaviour: only the labels differ. XO 6 uses the current names, and the tags XO puts on replicas (`Disaster Recovery`, `Continuous Replication`) kept the former ones.
 :::

docs/docs/backups-and-dr/backup_howto.md

@@ -23,9 +23,9 @@ This part explains the terminology of backup types and features.
   - Azurite
 - [**File restore**](./backup-features-and-settings.md#restore-a-file): A feature that allows you to restore individual files from a VM backup without restoring the full VM.
 - [**Full backup**](./backup-types/full_backups.md): Copies the entire VM to backup repositories each time, regardless of previous backups.
-- [**Full replication**](./backup-types/full_replication.md): Creates a replica of a VM on other storage repositories (on the same pool or on another) by copying it completely on each run.
+- [**Full replication**](../replication/full_replication.md): Creates a replica of a VM on other storage repositories (on the same pool or on another) by copying it completely on each run.
 - [**Incremental backup**](./backup-types/incremental_backups.md): Transfers and stores only the changes since the last backup to backup repositories, reducing storage and network needs. The first run transfers the VM completely.
-- [**Incremental replication**](./backup-types/incremental_replication.md): Transfers and stores only the changes since the last backup to storage repositories (on the same pool or on another), reducing network needs. The first run transfers the VM completely.
+- [**Incremental replication**](../replication/incremental_replication.md): Transfers and stores only the changes since the last backup to storage repositories (on the same pool or on another), reducing network needs. The first run transfers the VM completely.
 - [**Long-term retention**](./backup-features-and-settings.md#long-term-backup-retention-with-gfs-strategy): Keeps backups over extended periods (weeks, months, or years) for compliance or archival purposes.
 - [**Mirror backup**](./backup-types/mirror_backup.md): Mirror a backup repository to another. Retention and encryption of source and destination can be different.
 - [**Distributed backup and replication**](./scale-and-security/distributed_backups.md): Distribute the backups and replications across multiple targets.
@@ -73,8 +73,8 @@ Here is the whole toolbox at a glance. Most infrastructures combine several of t
 | [Rolling snapshots](./backup-types/rolling_snapshots.md)                | Instant restore points, on the same storage | SR space only               | Instant revert                   | Oops protection, before risky changes  |
 | [Full backup](./backup-types/full_backups.md)                           | Complete standalone archive on a BR         | High, every run             | Simple, anywhere                 | Small fleets, simplicity first         |
 | [Incremental backup](./backup-types/incremental_backups.md)             | Compact archives after the first full       | Low per run                 | Whole VM or single files         | The default choice for most VMs        |
-| [Full replication (DR)](./backup-types/full_replication.md)             | Boot-ready copy on another host/SR          | High, every run             | Start the copy                   | DR with a modest RPO                   |
-| [Incremental replication (CR)](./backup-types/incremental_replication.md) | Boot-ready copy, updated by deltas        | Low per run                 | Clone and start                  | Low-RPO DR for critical VMs            |
+| [Full replication (DR)](../replication/full_replication.md)             | Boot-ready copy on another host/SR          | High, every run             | Start the copy                   | DR with a modest RPO                   |
+| [Incremental replication (CR)](../replication/incremental_replication.md) | Boot-ready copy, updated by deltas        | Low per run                 | Clone and start                  | Low-RPO DR for critical VMs            |
 | [Mirror backup](./backup-types/mirror_backup.md)                        | A second copy of a backup repository        | Follows the source          | Same as the source backups       | 3-2-1 strategies, offsite archives     |
 | [Metadata backup](./backup-types/metadata_backup.md)                    | XO config and pool metadata                 | Tiny                        | Rebuild your orchestration       | Always: it protects the tool itself    |
 

docs/docs/backups-and-dr/backup_reports.md

@@ -131,7 +131,7 @@ Xen Orchestra is able to send backup reports to Slack or Mattermost. Both are ha
 
 ### Plugin configuration
 
-Like all other xo-server plugins, it can be configured directly via the web interface, see [the plugin documentation](../getting-started/architecture.md#plugins). The plugin needs:
+Like all other xo-server plugins, it can be configured directly via the web interface, see [the plugin documentation](../manage-your-infrastructure/plugins/plugins.md). The plugin needs:
 
 - **Webhook URI**: the Mattermost or Slack webhook URL (see below to generate it)
 - **Channel**: the channel, private group or IM channel to send the message to
@@ -323,4 +323,4 @@ Backup results are mapped to the standard Icinga 2 states: `OK` for a success, `
 
 ## Web hooks
 
-You can also configure web hooks to be sent to a custom server before and/or after a backup job runs. This won't send a formatted report but raw JSON data that you can use in custom scripts on your side. Follow the [web-hooks plugin documentation](../manage-your-infrastructure/advanced#web-hooks) to configure it.
+You can also configure web hooks to be sent to a custom server before and/or after a backup job runs. This won't send a formatted report but raw JSON data that you can use in custom scripts on your side. Follow the [web-hooks plugin documentation](../manage-your-infrastructure/advanced.md#web-hooks) to configure it.

docs/docs/backups-and-dr/backup_troubleshooting.md

@@ -20,7 +20,7 @@ _Incremental Backup_ and _Incremental Replication_ usually produce delta exports
 
 Nevertheless, there are several reasons for XO to trigger a key (full) export instead:
 
-- the configured [_Full backup interval_](./backup-types/incremental_backups#key-backup-interval) advanced setting has been reached for this VM
+- the configured [_Full backup interval_](./backup-types/incremental_backups.md#key-backup-interval) advanced setting has been reached for this VM
 - the _Force full backup_ option is enabled for the current schedule
 - a new disk has been added to the VM (only this disk is completely exported)
 - the reference snapshot for this backup job is missing on the source VM

docs/docs/backups-and-dr/backups-in-xo6.md

@@ -4,7 +4,7 @@ sidebar_position: 3
 
 # Backups in XO 6
 
-XO 6 puts backup health where you look every day: on the dashboards. This page covers what you can see and follow from XO 6; creating and editing backup jobs is currently done in XO 5 (see [XO 6 and XO 5](../discover-xen-orchestra/xo6vsxo5.md)).
+XO 6 puts backup health where you look every day: on the dashboards. This page covers what you can see and follow from XO 6; creating and editing backup jobs is currently done in XO 5 (see [XO 6 and XO 5](../whats-new/xo6vsxo5.md)).
 
 ## Backup health on the dashboard
 

docs/docs/backups-and-dr/intro_backup.md

@@ -19,8 +19,8 @@ New to backups in XO? Start with these two:
 - **[Rolling snapshots](./backup-types/rolling_snapshots.md)**: scheduled snapshots kept on a rotation. No repository needed, instant restore points.
 - **[Full backups](./backup-types/full_backups.md)**: a complete export of the VM to a backup repository (BR), every time. Simple and self-contained.
 - **[Incremental backups](./backup-types/incremental_backups.md)**: after an initial full, only the changed blocks are sent. Fast, compact, deduplicable.
-- **[Full replication](./backup-types/full_replication.md)** (formerly Disaster Recovery, DR): a ready-to-boot copy of your VMs, kept up to date on another host or SR.
-- **[Incremental replication](./backup-types/incremental_replication.md)** (formerly Continuous Replication, CR): the same standby copy, sending only the deltas.
+- **[Full replication](../replication/full_replication.md)** (formerly Disaster Recovery, DR): a ready-to-boot copy of your VMs, kept up to date on another host or SR.
+- **[Incremental replication](../replication/incremental_replication.md)** (formerly Continuous Replication, CR): the same standby copy, sending only the deltas.
 - **[Mirror backups](./backup-types/mirror_backup.md)**: replicate a whole backup repository to another one, the key to [3-2-1 strategies](backup_howto.md#long-term-retention-strategy).
 - **[Metadata backup](./backup-types/metadata_backup.md)**: the XO configuration and pool metadata themselves, so the orchestrator is never your single point of failure.
 

docs/docs/core-concepts/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Core concepts",
+  "position": 4,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/core-concepts",
+    "description": "How Xen Orchestra is built and how XO 6 is organized"
+  }
+}

docs/docs/core-concepts/architecture.md

@@ -1,10 +1,11 @@
 ---
-sidebar_position: 9
+sidebar_label: XO architecture
+sidebar_position: 2
 ---
 
-# Architecture
+# XO architecture and components
 
-Xen Orchestra (XO) is built as **one server and several clients**: the two web interfaces ([XO 6](../discover-xen-orchestra/gettingstarted.md) and XO 5), the command line client `xo-cli`, and anything speaking the [REST API](automation/restapi.md). The server, `xo-server`, is the only piece that talks to your infrastructure.
+Xen Orchestra (XO) is built as **one server and several clients**: the two web interfaces ([XO 6](coreconcepts/coreconcepts.md) and XO 5), the command line client `xo-cli`, and anything speaking the [REST API](../automation/restapi.md). The server, `xo-server`, is the only piece that talks to your infrastructure.
 
 :::tip
 XO is totally agent-less: nothing to install on your hosts. `xo-server` speaks XAPI, the native toolstack of XCP-ng, directly over the network.
@@ -90,7 +91,7 @@ Note that `xo-server` only needs to reach the **master** of each pool: the maste
 
 ## XOA
 
-The _Xen Orchestra Appliance_ (XOA) is a VM with the whole stack pre-installed, configured and QA validated. It is the way we recommend and support running XO: see [Installing XOA](installation.md).
+The _Xen Orchestra Appliance_ (XOA) is a VM with the whole stack pre-installed, configured and QA validated. It is the way we recommend and support running XO: see [Installing XOA](../getting-started/installation/xoa.md).
 
 ## xo-server
 
@@ -172,19 +173,19 @@ Legacy clients ask the servers "anything new?" every few seconds: slow, and it c
 
 Two web UIs currently ship with Xen Orchestra, served by `xo-server` and talking to it over WebSockets:
 
-- **XO 6** (`@xen-orchestra/web`), the new default interface, built with Vue.js on a dedicated design system. See the [XO 6 documentation](../discover-xen-orchestra/gettingstarted.md).
+- **XO 6** (`@xen-orchestra/web`), the new default interface, built with Vue.js on a dedicated design system. See [How XO is organized](coreconcepts/coreconcepts.md).
 - **XO 5** (`xo-web`), the complete historical interface, built with React. See [the infrastructure management section](../manage-your-infrastructure/manage_infrastructure.md) for what you can do with it.
 
 <UiShot light="/img/xo6/dashboard-light.png" dark="/img/xo6/dashboard-dark.png" alt="XO 6, the new default web interface" url="https://your-xo/v6/#/dashboard" />
 
-Both run against the same server and the same data at the same time: see [XO 6 and XO 5](../discover-xen-orchestra/xo6vsxo5.md).
+Both run against the same server and the same data at the same time: see [XO 6 and XO 5](../whats-new/xo6vsxo5.md).
 
 ## xo-cli
 
 [`xo-cli`](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-cli) sends commands to `xo-server` from a shell. Thanks to introspection, it discovers every method the server exposes, plus a convenient wrapper around the REST API.
 
 :::warning
-`xo-cli` is mainly a debug and power-user tool: there is no absolute guarantee on its stability. Prefer the [REST API](automation/restapi.md) for automation.
+`xo-cli` is mainly a debug and power-user tool: there is no absolute guarantee on its stability. Prefer the [REST API](../automation/restapi.md) for automation.
 :::
 
 Register your XO instance first (only a token is stored):
@@ -217,16 +218,10 @@ Parameters are strings by default (`true`/`false` are parsed as booleans); prefi
 
 ## APIs
 
-The public, supported API of Xen Orchestra is the **[REST API](automation/restapi.md)**: plain HTTP, easy to call from any language or tool, with its own documentation page and a live OpenAPI reference at `/rest/v0/docs/` on your XO.
+The public, supported API of Xen Orchestra is the **[REST API](../automation/restapi.md)**: plain HTTP, easy to call from any language or tool, with its own documentation page and a live OpenAPI reference at `/rest/v0/docs/` on your XO.
 
 Internally, the web UIs and `xo-cli` talk to `xo-server` over a JSON-RPC-over-WebSockets protocol: that connected mode is what lets clients subscribe to events and stay current in real time. This internal API is not designed for third parties: if you automate against XO, use the REST API.
 
 ## Plugins
 
-Plugins extend Xen Orchestra without touching its core. They live in "Settings, then Plugins":
-
-<UiDetail src="/img/xoa/plugins-menu.png" alt="The Plugins page in Settings" width={520} />
-
-Each plugin can be activated or deactivated, loaded at startup, and configured entirely from the web interface:
-
-<UiDetail src="/img/xoa/plugins-page.png" alt="Configuring a plugin from the web interface" width={520} />
+Plugins are modules of `xo-server` that extend Xen Orchestra without touching its core: authentication providers, backup reports, load balancing, SDN controller and more. To activate and configure them, see [Management → Plugins](../manage-your-infrastructure/plugins/plugins.md).

docs/docs/core-concepts/coreconcepts/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "XO interface",
+  "position": 1
+}

docs/docs/core-concepts/coreconcepts/coreconcepts.md

@@ -0,0 +1,30 @@
+---
+sidebar_position: 2
+---
+
+# How XO is organized
+
+XO 6 organizes everything around a simple idea: **every level of your infrastructure gets the same treatment**. Your whole Xen Orchestra, a pool, a host or a single VM each have their own page, with a dashboard and a consistent set of tabs. Once you know how one page works, you know them all.
+
+## The object hierarchy
+
+Xen Orchestra manages any number of pools, wherever they are:
+
+- **Xen Orchestra** (the top level): everything connected to this XO, across all pools and sites.
+- **Pool**: a group of XCP-ng hosts sharing storage and networks, managed as one unit.
+- **Host**: an XCP-ng server inside a pool.
+- **VM**: a virtual machine running on a host.
+
+The tree view on the left mirrors this hierarchy, and every page shows its object's place in it (a VM page links to its host and pool, and so on).
+
+## Find your way in XO 6
+
+Every page of XO 6 relies on the same building blocks:
+
+- [Dashboards at every level](dashboards.md): the health of your infrastructure, at the scale of the page you are on.
+- [Tabs, tables and the side panel](tabs-tables-side-panel.md): how object pages and their tables are organized.
+- [Tasks: everything is tracked](tasks.md): the history of every operation on your infrastructure.
+
+## Where XO 5 fits
+
+XO 6 is an official release under active development. A few operations still live in XO 5, and XO 6 tells you explicitly: buttons and links marked with an external-link icon (for example **Manage VM lifecycle in XO 5**, or the **Stats** tab) open the right XO 5 page for that same object. Both interfaces work on the same data at the same time, so there is no synchronization to think about. The current split is documented in [XO 6 and XO 5](../../whats-new/xo6vsxo5.md).

docs/docs/core-concepts/coreconcepts/dashboards.md

@@ -0,0 +1,18 @@
+---
+sidebar_label: Dashboards
+sidebar_position: 1
+---
+
+# Dashboards at every level
+
+Each level opens on a **dashboard** that answers "is everything fine here?" at its own scale.
+
+At the top level, the dashboard aggregates the whole infrastructure: pool, host and VM status, total memory, CPUs and storage, alarms, missing patches per pool and host, backup job health and how many VMs are protected by a backup job:
+
+<UiShot light="/img/xo6/dashboard-light.png" dark="/img/xo6/dashboard-dark.png" alt="The Xen Orchestra dashboard" url="https://your-xo/v6/#/dashboard" />
+
+At the pool level, the same layout narrows to the pool: host and VM status, alarms, the exact list of missing patches, storage and RAM usage per host, and CPU provisioning:
+
+<UiShot light="/img/xo6/pool-dashboard-light.png" dark="/img/xo6/pool-dashboard-dark.png" alt="A pool dashboard" url="https://your-xo/v6/#/pool/…/dashboard" />
+
+Host and VM dashboards follow the same principle, down to the quick info of a single VM (state, IP address reported by the guest tools, OS, vCPUs, RAM, virtualization mode) and its individual backup protection status.

docs/docs/core-concepts/coreconcepts/tabs-tables-side-panel.md

@@ -0,0 +1,23 @@
+---
+sidebar_label: Tabs and tables
+sidebar_position: 2
+---
+
+# Tabs, tables and the side panel
+
+Object pages are organized in tabs. The exact set depends on the object:
+
+| Level         | Tabs                                                                        |
+| ------------- | --------------------------------------------------------------------------- |
+| Xen Orchestra | Dashboard, Backups, Tasks, Pools, Hosts, VMs                                |
+| Pool          | Dashboard, Stats, System, Network, Traffic rules, Storage, Tasks, Hosts, VMs     |
+| Host          | Dashboard, Console, Stats, System, Network, Storage, Tasks, VMs             |
+| VM            | Dashboard, Console, Backups, Stats, System, Network, VDIs, Snapshots, Tasks |
+
+Tables (networks, tasks, backup jobs, snapshots and so on) share the same tooling everywhere:
+
+- a **Search Engine** field with a query builder, to filter large tables precisely,
+- pagination controls,
+- an eye icon per row that opens the **side panel** with the details of that row, so you never lose the context of the list.
+
+<UiShot light="/img/xo6/pool-networks-light.png" dark="/img/xo6/pool-networks-dark.png" alt="Networks of a pool, with the query builder and the side panel" url="https://your-xo/v6/#/pool/…/networks" />

docs/docs/core-concepts/coreconcepts/tasks.md

@@ -0,0 +1,10 @@
+---
+sidebar_label: Tasks
+sidebar_position: 3
+---
+
+# Tasks: everything is tracked
+
+Every level has a **Tasks** tab. It records what happens on your infrastructure: user authentications, API calls, rolling pool reboots, backup runs and any other operation, with their outcome and when they ended. When you need to understand what happened and when, start there.
+
+<UiShot light="/img/xo6/tasks-light.png" dark="/img/xo6/tasks-dark.png" alt="The tasks view" url="https://your-xo/v6/#/tasks" />

docs/docs/discover-xen-orchestra/_category_.json

@@ -1,8 +0,0 @@
-{
-    "label": "Discover Xen Orchestra",
-    "position": 3,
-    "link": {
-      "type": "generated-index",
-      "description": "General information on Xen Orchestra"
-    }
-  }

docs/docs/discover-xen-orchestra/coreconcepts.md

@@ -1,62 +0,0 @@
----
-sidebar_label: Core concepts
-sidebar_position: 4
----
-
-# How XO 6 is organized
-
-XO 6 organizes everything around a simple idea: **every level of your infrastructure gets the same treatment**. Your whole Xen Orchestra, a pool, a host or a single VM each have their own page, with a dashboard and a consistent set of tabs. Once you know how one page works, you know them all.
-
-## The object hierarchy
-
-Xen Orchestra manages any number of pools, wherever they are:
-
-- **Xen Orchestra** (the top level): everything connected to this XO, across all pools and sites.
-- **Pool**: a group of XCP-ng hosts sharing storage and networks, managed as one unit.
-- **Host**: an XCP-ng server inside a pool.
-- **VM**: a virtual machine running on a host.
-
-The tree view on the left mirrors this hierarchy, and every page shows its object's place in it (a VM page links to its host and pool, and so on).
-
-## Dashboards at every level
-
-Each level opens on a **dashboard** that answers "is everything fine here?" at its own scale.
-
-At the top level, the dashboard aggregates the whole infrastructure: pool, host and VM status, total memory, CPUs and storage, alarms, missing patches per pool and host, backup job health and how many VMs are protected by a backup job:
-
-<UiShot light="/img/xo6/dashboard-light.png" dark="/img/xo6/dashboard-dark.png" alt="The Xen Orchestra dashboard" url="https://your-xo/v6/#/dashboard" />
-
-At the pool level, the same layout narrows to the pool: host and VM status, alarms, the exact list of missing patches, storage and RAM usage per host, and CPU provisioning:
-
-<UiShot light="/img/xo6/pool-dashboard-light.png" dark="/img/xo6/pool-dashboard-dark.png" alt="A pool dashboard" url="https://your-xo/v6/#/pool/…/dashboard" />
-
-Host and VM dashboards follow the same principle, down to the quick info of a single VM (state, IP address reported by the guest tools, OS, vCPUs, RAM, virtualization mode) and its individual backup protection status.
-
-## Tabs, tables and the side panel
-
-Object pages are organized in tabs. The exact set depends on the object:
-
-| Level         | Tabs                                                                        |
-| ------------- | --------------------------------------------------------------------------- |
-| Xen Orchestra | Dashboard, Backups, Tasks, Pools, Hosts, VMs                                |
-| Pool          | Dashboard, Stats, System, Network, Traffic rules, Storage, Tasks, Hosts, VMs     |
-| Host          | Dashboard, Console, Stats, System, Network, Storage, Tasks, VMs             |
-| VM            | Dashboard, Console, Backups, Stats, System, Network, VDIs, Snapshots, Tasks |
-
-Tables (networks, tasks, backup jobs, snapshots and so on) share the same tooling everywhere:
-
-- a **Search Engine** field with a query builder, to filter large tables precisely,
-- pagination controls,
-- an eye icon per row that opens the **side panel** with the details of that row, so you never lose the context of the list.
-
-<UiShot light="/img/xo6/pool-networks-light.png" dark="/img/xo6/pool-networks-dark.png" alt="Networks of a pool, with the query builder and the side panel" url="https://your-xo/v6/#/pool/…/networks" />
-
-## Tasks: everything is tracked
-
-Every level has a **Tasks** tab. It records what happens on your infrastructure: user authentications, API calls, rolling pool reboots, backup runs and any other operation, with their outcome and when they ended. When you need to understand what happened and when, start there.
-
-<UiShot light="/img/xo6/tasks-light.png" dark="/img/xo6/tasks-dark.png" alt="The tasks view" url="https://your-xo/v6/#/tasks" />
-
-## Where XO 5 fits
-
-XO 6 is an official release under active development. A few operations still live in XO 5, and XO 6 tells you explicitly: buttons and links marked with an external-link icon (for example **Manage VM lifecycle in XO 5**, or the **Stats** tab) open the right XO 5 page for that same object. Both interfaces work on the same data at the same time, so there is no synchronization to think about. The current split is documented in [XO 6 and XO 5](xo6vsxo5.md).

docs/docs/discover-xen-orchestra/whatsnew.md

@@ -1,27 +0,0 @@
----
-sidebar_label: What's new
-sidebar_position: 1
----
-
-# What's new in XO 6
-
-XO 6 is a complete redesign of the Xen Orchestra interface, built as a modern web application on a dedicated design system. It is not a reskin of XO 5: the navigation, the information architecture and the visual language were rebuilt from scratch around how infrastructures are actually operated.
-
-<UiShot dark="/img/xo6/lab-dashboard.webp" alt="XO 6: one dashboard for every pool, host and VM you manage" url="https://myxoa.domain.tld/v6/#/dashboard" />
-
-## Highlights
-
-- **A tree view of your whole infrastructure**: every pool, host and VM in one always-visible, searchable tree. No more jumping between list pages to find an object.
-- **Dashboards at every level**: Xen Orchestra, pool, host and VM each open on a dashboard that summarizes status, alarms, patches, resources and backup health at that scale.
-- **Consistent pages**: every object follows the same tab pattern, every table has the same query builder and details side panel. Learn one page, know them all.
-- **First-class consoles**: VM and host consoles in the browser, with fullscreen, a chrome-less dedicated tab mode and Ctrl+Alt+Del.
-- **Make it yours**: light and dark color modes, five interface themes, and 21 languages.
-- **Task visibility**: a Tasks tab at every level records operations, API calls and authentications with their outcomes.
-- **Backup awareness everywhere**: protection status is visible from the global dashboard down to each VM, including the VMs that no job protects.
-- **Side-by-side with XO 5**: both interfaces run on the same Xen Orchestra and the same data. Anything not yet in XO 6 is one clearly marked click away.
-
-## An interface that grows release by release
-
-XO 6 reached its first official release with a deliberately focused scope, and new capabilities are added continuously: more actions on objects, user management, backup features and more. The [XO 6 and XO 5](xo6vsxo5.md) page tracks what lives where today, and the best way to see what is new is simply to keep your Xen Orchestra up to date.
-
-To explore the interface, start with [XO 6 at a glance](gettingstarted.md).

docs/docs/getting-started/_category_.json

@@ -1,8 +1,9 @@
 {
-    "label": "Getting started",
-    "position": 2,
-    "link": {
-      "type": "generated-index",
-      "description": "How to get XO up and running as fast as possible"
-    }
-  }
+  "label": "Getting started",
+  "position": 3,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/getting-started",
+    "description": "Check the requirements, install and configure Xen Orchestra, and keep it up to date"
+  }
+}

docs/docs/getting-started/configuration.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 5
+sidebar_position: 3
 ---
 
 # Configuration
@@ -12,34 +12,7 @@ The configuration file is located at `/etc/xo-server/config.toml`.
 
 If you need to do any configuration on the system itself (firewall, NTP, service restart…), see [the XOA appliance settings](#xoa-appliance) at the end of this page.
 
-## Using XO 5 as the Default Interface
-
-Starting with **Xen Orchestra 6**, the XO 6 UI becomes the default interface. That said, you can still switch back to XO 5, temporarily or by default.
-
-### Temporary Switch to XO 5
-
-To quickly access the old UI without changing any configuration, `/v5` to your URL (e.g., `https://xo.example.com/v5`).
-
-### Making XO 5 the default UI
-
-To permanently use XO 5 as the default interface, create a new config file (you can call it `config.mounts.toml`). This configuration file can be placed either in `~/.config/xo-server/` of the process running xo-server or if you are using a xoa in `/etc/xo-server/`. This file will contain :
-
-```toml
-[http.mounts]
-'/' = '/usr/local/lib/node_modules/xo-web/dist/'
-'/v5' = '/usr/local/lib/node_modules/xo-web/dist/'
-'/v6' = '/usr/local/lib/node_modules/@xen-orchestra/web/dist/'
-```
-
-If you are not using a xoa, replace the path `/usr/local/lib/node_modules/` with the real path of the modules.
-
-This configuration ensures:
-
-- Accessing `/` loads **XO 5**.
-- Accessing `/v5` loads **XO 5**.
-- Accessing `/v6` loads **XO 6**.
-
-### Where to Place the Configuration File
+## Where to place the configuration file
 
 :::tip
 If changing a user-specific configuration, make sure the file belongs to the user that runs the XO server process.
@@ -76,16 +49,6 @@ a basic cli can be used to explore the configuration by installing the package `
 The update feature of XOA can reset any `local` config. Use `/etc/xo-server/config.*` as the preferred config place for XOA.
 :::
 
-### Apply the changes
-
-After updating the configuration, restart the XO server process:
-
-<Terminal shell title="xoa — apply the configuration">{`
-sudo systemctl restart xo-server
-`}</Terminal>
-
-XO 5 will now be served as the default UI.
-
 ## User to run XO-server as
 
 By default, XO-server runs as 'root'. You can change that by uncommenting these lines and choose whatever user/group you want:
@@ -95,7 +58,7 @@ user = 'nobody'
 group = 'nogroup'
 ```
 
-**Warning!** A non-privileged user requires the use of `sudo` to mount NFS shares. See [installation from the sources](install-from-sources.md).
+**Warning!** A non-privileged user requires the use of `sudo` to mount NFS shares. See [installation from the sources](installation/install-from-sources.md).
 
 ## HTTP listen address and port
 
@@ -157,7 +120,7 @@ useDirectChannel = false
 
 Changing the mode is only supported forward : from direct OpenFlow Protocol channel to XAPI Plugin communication.
 A migration script is provided to automatically convert the traffic rules.
-See [SDN Controller: OpenFlow rules](../manage-your-infrastructure/sdn_controller.md#migration-path) for details.
+See [SDN Controller: OpenFlow rules](../manage-your-infrastructure/networking/sdn_controller.md#migration-path) for details.
 
 ## Custom certificate authority
 
@@ -299,7 +262,7 @@ For advanced usage, you can customize the way XO connect to Redis:
 #encryptCredentialDatabase = true
 ```
 
-For more information about the encryption feature, see [credential database encryption](../users-and-access/credential-encryption.md)
+For more information about the encryption feature, see [credential database encryption](../security/credential-encryption.md)
 
 ## Proxy for updates and patches
 

docs/docs/getting-started/gettingstarted.md

@@ -1,6 +1,7 @@
 ---
 sidebar_label: First steps
-sidebar_position: 3
+draft: true
+sidebar_position: 4
 ---
 
 # XO 6 at a glance
@@ -8,7 +9,7 @@ sidebar_position: 3
 XO 6 is the new generation of the Xen Orchestra web interface. Since its first official release, it is the default interface of your Xen Orchestra: log in as usual and you land in XO 6.
 
 :::info
-XO 6 currently requires an administrator account: other users are redirected to XO 5 for now. XO 6 and XO 5 run side by side on the same Xen Orchestra and manage the same infrastructure. You can switch to XO 5 at any time with the **XO 5** link in the top-right corner, and some advanced operations open directly in XO 5 (they are clearly marked with an external-link icon). See [XO 6 and XO 5](xo6vsxo5.md) for the current split.
+XO 6 currently requires an administrator account: other users are redirected to XO 5 for now. XO 6 and XO 5 run side by side on the same Xen Orchestra and manage the same infrastructure. You can switch to XO 5 at any time with the **XO 5** link in the top-right corner, and some advanced operations open directly in XO 5 (they are clearly marked with an external-link icon). See [XO 6 and XO 5](../whats-new/xo6vsxo5.md) for the current split.
 :::
 
 ## Accessing XO 6
@@ -47,7 +48,7 @@ Next to the tree view, the **Administration** tab of the sidebar gives access to
 
 A good way to discover XO 6 in a few minutes:
 
-1. Start on the **dashboard**: it aggregates the health of everything Xen Orchestra manages, including pool, host and VM status, resource totals, missing patches, alarms and backup health. See [How XO 6 is organized](coreconcepts.md).
+1. Start on the **dashboard**: it aggregates the health of everything Xen Orchestra manages, including pool, host and VM status, resource totals, missing patches, alarms and backup health. See [How XO is organized](../core-concepts/coreconcepts/coreconcepts.md).
 2. Click a **pool** in the tree view: same idea, scoped to the pool, with its networks, storage and hosts one tab away.
 3. Click a **VM**: quick info, live console, snapshots, backup protection status, all in tabs.
 4. Open the **Tasks** tab at any level: every operation, API call and authentication is tracked there.

docs/docs/getting-started/installation/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Installation",
+  "position": 2,
+  "link": {
+    "type": "doc",
+    "id": "getting-started/installation/install"
+  }
+}

docs/docs/getting-started/installation/install-from-sources.md

@@ -1,6 +1,7 @@
 ---
-sidebar_label: From source
-sidebar_position: 4
+slug: /getting-started/install-from-sources
+sidebar_label: XO from source
+sidebar_position: 2
 ---
 
 # Installing XO from source
@@ -8,7 +9,7 @@ sidebar_position: 4
 Xen Orchestra is fully open source: you can build and run it yourself, for free, from its Git repository. This is the method of choice for home labs and evaluation on your own terms.
 
 :::warning
-There is no professional support for this installation method, and no QA beyond what the community reports. For production, use [XOA](installation.md). Use the sources at your own risk!
+There is no professional support for this installation method, and no QA beyond what the community reports. For production, use [XOA](xoa.md). Use the sources at your own risk!
 :::
 
 What you are about to build: a single `xen-orchestra` checkout containing the server (`xo-server`) and the web interfaces, running as one Node.js process, with Redis as its database. Total time on a fresh VM: about fifteen minutes.
@@ -205,7 +206,7 @@ username ALL=(root)NOPASSWD: /bin/mount, /bin/umount, /bin/findmnt
 
 ## About the banner
 
-Running from the sources shows a banner reminding you that this version comes without support or QA. As a home user, simply ignore it: it is aimed at companies, for which the supported [XOA](installation.md) is the right vehicle, and whose subscriptions are what funds the development of XO and [XCP-ng](https://xcp-ng.org) (every euro earned goes directly back into these open source projects). Removing the banner in redistributed scripts hurts that loop, and keeping it is one simple way to support the project.
+Running from the sources shows a banner reminding you that this version comes without support or QA. As a home user, simply ignore it: it is aimed at companies, for which the supported [XOA](xoa.md) is the right vehicle, and whose subscriptions are what funds the development of XO and [XCP-ng](https://xcp-ng.org) (every euro earned goes directly back into these open source projects). Removing the banner in redistributed scripts hurts that loop, and keeping it is one simple way to support the project.
 
 You can also support XO by spreading the word, reporting bugs, and contributing code.
 
@@ -216,7 +217,7 @@ Exceptional individual contributors are awarded a free XOA Premium subscription.
 ## FreeBSD and OpenBSD
 
 :::note Community territory
-We do not test Xen Orchestra on FreeBSD or OpenBSD at all: everything below comes purely from community feedback, and may lag behind reality. If you run XO on these systems and want to help maintain these instructions, [contact us](../support-and-licencing/community.md): we would be happy to have more testers and maintainers for these targets.
+We do not test Xen Orchestra on FreeBSD or OpenBSD at all: everything below comes purely from community feedback, and may lag behind reality. If you run XO on these systems and want to help maintain these instructions, [contact us](../../support-and-reference/community.md): we would be happy to have more testers and maintainers for these targets.
 :::
 
 ### FreeBSD

docs/docs/getting-started/installation/install.md

@@ -0,0 +1,36 @@
+---
+slug: /getting-started/install
+sidebar_label: Installation
+---
+
+# Installing Xen Orchestra
+
+You can install Xen Orchestra in two ways: deploy **XOA**, the Xen Orchestra Appliance, or build Xen Orchestra yourself **from source**. Both give you Xen Orchestra and its web interfaces; they differ in how XO is packaged, kept up to date and supported.
+
+Whichever method you choose, first check the [requirements](../requirements.md).
+
+## Which method should I choose?
+
+|                    | XOA                                                                          | From source                                                        |
+| ------------------ | ---------------------------------------------------------------------------- | ------------------------------------------------------------------ |
+| **What you get**   | A pre-built VM, deployed on one of your hosts in a few minutes               | A build of the Git repository, on a machine you prepare yourself   |
+| **Updates**        | [Built-in updater](../updater.md), from the web interface | `git pull` and rebuild, by hand                                    |
+| **Quality**        | Every release is tested, as part of a controlled environment                 | No QA beyond what the community reports                            |
+| **Support**        | Professional support with a Vates VMS bundle, best-effort tickets with XOA Free | [Community support](../../support-and-reference/community.md) only |
+| **Best for**       | Production, and anyone who wants Xen Orchestra to just work                   | Home labs, evaluation, contributing to Xen Orchestra               |
+
+### XOA, the recommended method
+
+XOA is the way Vates recommends to run Xen Orchestra, and the only one with professional support. Deploying it takes a few minutes and installs nothing on your hosts: XOA is just another VM. Once it is registered, you can start a free 30-day trial of the complete feature set; afterwards, it keeps working with the Free feature set if you do not subscribe.
+
+[Install XOA](xoa.md)
+
+### From source, for labs and evaluation
+
+Xen Orchestra is fully open source: you can build and run it yourself, for free, on a machine you control (the procedure is validated on Debian). You are then in charge of its dependencies, its updates and its troubleshooting, with the help of the community.
+
+[Install Xen Orchestra from source](install-from-sources.md)
+
+## Not sure?
+
+Start with XOA. If you plan to use Xen Orchestra in production, it is the method we recommend, and the trial lets you evaluate every feature before deciding. For more on support options, see [Support](../../support-and-reference/intro_support.md).

docs/docs/getting-started/installation/xoa.md

@@ -1,13 +1,18 @@
 ---
-sidebar_label: Installation
-sidebar_position: 3
+slug: /getting-started/installation
+sidebar_label: XO Appliance (XOA)
+sidebar_position: 1
 ---
 
 # Installing XOA
 
 Deploying Xen Orchestra takes a few minutes: you deploy the **Xen Orchestra Appliance (XOA)**, a pre-built VM with everything configured, directly on one of your hosts. Nothing is installed on the hosts themselves, and nothing changes in your infrastructure: XOA is just another VM.
 
-This page walks the whole journey: deploy, first login, registration, and the first console and network settings. If you prefer building from the sources instead, the community method has [its own page](install-from-sources.md).
+This page walks the whole journey: deploy, first login, registration, and the first console and network settings. Not sure XOA is the right choice for you? See [how to choose your installation method](install.md).
+
+Before you start, check the [requirements](../requirements.md): supported hosts and the resources to give to the appliance.
+
+If you are installing XOA to leave VMware, deploy it as described below, then follow the [VMware migration (V2V)](../../migrate-from-vmware/v2v-migration-guide.md) guide: it explains how to prepare both environments and move your VMs to XCP-ng with Xen Orchestra.
 
 ## Deploy XOA {#xoa}
 
@@ -23,29 +28,6 @@ The wizard walks four steps: **Connect** (your host address and credentials), **
 
 <UiDetail src="/img/xoa/deploy-wizard.png" alt="The four deploy steps: connect to your primary host, configure, secure, deploy" width={620} />
 
-## XOA specifications and sizing {#xoa-vm-specifications}
-
-The deploy form on [vates.tech/deploy](https://vates.tech/deploy/) lets you size the VM at deployment, with three presets:
-
-| Preset | vCPUs | RAM | Typical usage |
-| --- | --- | --- | --- |
-| Small | 2 | 4 GiB | A few pools, no backup jobs, no V2V |
-| Medium | 4 | 8 GiB | Enterprise usage: backup jobs, V2V, more pools |
-| **Large** (default) | 8 | 16 GiB | Large infrastructures with backup jobs |
-
-The VM also needs 20 GiB of free SR space (2 GiB on a thin-provisioned SR).
-
-### Sizing your XOA {#sizing}
-
-The default preset targets large infrastructures running backup jobs, which is what most production deployments look like. A few rules of thumb:
-
-- **4 GiB and 2 vCPUs** is enough for a few pools without backups or V2V. 2 GiB is the strict minimum, for labs only.
-- As soon as you run backup jobs or V2V, use at least **8 GiB and 4 vCPUs**.
-- **16 GiB and 8 vCPUs** for large infrastructures or a heavy backup load: transfers and compression are parallel workloads, so they benefit from more vCPUs.
-- You can always give more, but **measure** afterwards to check the improvement is real before going further.
-
-You can resize the VM at any time: shut it down, change its vCPUs and RAM, and start it again. Since Xen Orchestra 6.8, `xo-server` sets its own memory limit to 70% of the VM's RAM at each start, so there is nothing else to change. If you deployed with another method, the VM starts with 2 vCPUs and 2 GiB: resize it right after deployment.
-
 ## First login
 
 Once the VM is running, open its IP address in your browser. If you did not set a fixed IP or are unsure which one it got:
@@ -54,7 +36,7 @@ Once the VM is running, open its IP address in your browser. If you did not set
 
 or check your router's DHCP leases for an `xoa` entry.
 
-- Default web UI credentials: `admin@admin.net` / `admin`. Change them right after the first login: create a new admin account and remove this one. If you ever lose your password, you can [reset the configuration](troubleshooting.md#reset-the-configuration) to get the default credentials back.
+- Default web UI credentials: `admin@admin.net` / `admin`. Change them right after the first login: create a new admin account and remove this one. If you ever lose your password, you can [reset the configuration](../../support-and-reference/troubleshooting.md#reset-the-configuration) to get the default credentials back.
 - Console and SSH have **no default password**: you set one during deployment, or later [from the host](#first-console-connection).
 
 ## Register and start your trial {#registration}
@@ -71,7 +53,46 @@ To try everything XO can do, start the trial from the same view ("Start Trial",
 
 <UiDetail src="/img/xoa/start-trial.png" alt="Starting the 30-day Premium trial" width={520} />
 
-When the trial ends, the appliance keeps working and simply returns to the Free feature set: you lose no data and no configuration. For system-level settings of the appliance (firewall, NTP, service restart), see [the XOA appliance settings](configuration.md#xoa-appliance).
+When the trial ends, the appliance keeps working and simply returns to the Free feature set: you lose no data and no configuration. For system-level settings of the appliance (firewall, NTP, service restart), see [the XOA appliance settings](../configuration.md#xoa-appliance).
+
+## Change the default interface
+
+Starting with **Xen Orchestra 6**, the XO 6 UI becomes the default interface. That said, you can still switch back to XO 5, temporarily or by default.
+
+### Temporary Switch to XO 5
+
+To quickly access the old UI without changing any configuration, `/v5` to your URL (e.g., `https://xo.example.com/v5`).
+
+### Making XO 5 the default UI
+
+To permanently use XO 5 as the default interface, create a new config file (you can call it `config.mounts.toml`). This configuration file can be placed either in `~/.config/xo-server/` of the process running xo-server or if you are using a xoa in `/etc/xo-server/`. This file will contain :
+
+```toml
+[http.mounts]
+'/' = '/usr/local/lib/node_modules/xo-web/dist/'
+'/v5' = '/usr/local/lib/node_modules/xo-web/dist/'
+'/v6' = '/usr/local/lib/node_modules/@xen-orchestra/web/dist/'
+```
+
+If you are not using a xoa, replace the path `/usr/local/lib/node_modules/` with the real path of the modules.
+
+This configuration ensures:
+
+- Accessing `/` loads **XO 5**.
+- Accessing `/v5` loads **XO 5**.
+- Accessing `/v6` loads **XO 6**.
+
+For the possible locations of configuration files and the order in which they are loaded, see [Where to place the configuration file](../configuration.md#where-to-place-the-configuration-file).
+
+### Apply the changes
+
+After updating the configuration, restart the XO server process:
+
+<Terminal shell title="xoa — apply the configuration">{`
+sudo systemctl restart xo-server
+`}</Terminal>
+
+XO 5 will now be served as the default UI.
 
 ## Alternative deployment methods {#alternative-install}
 
@@ -140,7 +161,3 @@ To configure another interface than the default one, pass its name as an argumen
 
 <Terminal title="xoa — add a secondary IP address">{`xoa network static --add
 ? Static IP for this machine 192.168.200.120/24`}</Terminal>
-
-## From the sources {#from-the-sources}
-
-Xen Orchestra is fully open source and can also be built from its sources, without professional support. This community installation method has [its own dedicated page](install-from-sources.md).

docs/docs/getting-started/migrate_to_new_xoa.md

@@ -1,40 +0,0 @@
----
-sidebar_position: 7
----
-# Replace your XOA
-
-Replacing your appliance with a fresh one takes three steps: deploy the new XOA, export the configuration of the old one, and import it into the new one. Everything follows: users, ACLs, connected pools, backup jobs, remotes and settings.
-
-## Why replace it?
-
-- **To get a fresh appliance, not just fresh XO code.** The [updater](updater.md) keeps Xen Orchestra itself current, but the appliance around it (Debian system, kernel, Node.js runtime) ages like any VM. Redeploying gives you the latest base system in one move.
-- **Because you lost it.** XOA failure is not an emergency: your hosts and VMs keep running without it, and a fresh appliance plus a configuration import puts you back exactly where you were, in minutes. Many people do not realize how disposable the appliance is: treat it as cattle, not as a pet.
-- **To move it**: new pool, new storage, new site. Deploy where you want it, import, delete the old one.
-
-:::tip
-Export your configuration regularly (and after any significant change): it is a small file, and it turns any XOA loss into a ten-minute non-event.
-:::
-
-## Deploy the new appliance
-
-Deploy a new XOA next to the old one, as described in [Installing XOA](installation.md).
-
-## Export the configuration
-
-On the old appliance, go to **Settings → Config** and click **Download current config**:
-
-<UiDetail src="/img/xoa/config-export.png" alt="Exporting the configuration, optionally encrypted with a passphrase" width={520} />
-
-You can set a passphrase to encrypt the exported file.
-
-## Import the configuration
-
-On the new appliance, go to **Settings → Config** and drag and drop the exported file into the **Import** section:
-
-<UiDetail src="/img/xoa/config-import.png" alt="Importing the configuration on the new appliance" width={520} />
-
-Click to import: a modal asks for the passphrase (leave it empty if you did not set one). Once the import finishes, the new appliance takes over with your complete configuration.
-
-:::note Advanced users
-Manual edits made to `/etc/xo-server/config.toml` on the old appliance are not part of the exported configuration: re-apply them on the new one (see [Configuration](configuration.md)).
-:::

docs/docs/getting-started/releases.md

@@ -1,10 +1,10 @@
 ---
-sidebar_position: 1
+sidebar_position: 6
 ---
 
 # Releases
 
-Xen Orchestra is distributed in two ways: as a turnkey virtual appliance (**XOA**) and **from the sources** on GitHub. Both contain the same Xen Orchestra, including its two web interfaces ([XO 6 and XO 5](../discover-xen-orchestra/xo6vsxo5.md)), the REST API and the backup engine.
+Xen Orchestra is distributed in two ways: as a turnkey virtual appliance (**XOA**) and **from the sources** on GitHub. Both contain the same Xen Orchestra, including its two web interfaces ([XO 6 and XO 5](../whats-new/xo6vsxo5.md)), the REST API and the backup engine.
 
 ## XOA, the appliance
 
@@ -17,7 +17,7 @@ XOA (**X**en **O**rchestra virtual **A**ppliance) is the pre-installed VM, and t
 - extra services (XO Hub, recipes, advanced metrics)
 - a secured system (sudo, firewall)
 
-Deploying one is trivial: see the [XOA install section](installation.md#xoa).
+Deploying one is trivial: see the [XOA install section](installation/xoa.md#xoa).
 
 :::tip
 Whatever your future usage, try XOA first: it is the easiest way to test everything, and the only way to get professional support.
@@ -36,7 +36,7 @@ Switching channels is done from the Updates view, without redeploying anything.
 
 ## From the sources
 
-Xen Orchestra is fully open source, and you can [install it from the sources](install-from-sources.md). In that case there are no releases to speak of: **stay on `master`**, and update before reporting anything:
+Xen Orchestra is fully open source, and you can [install it from the sources](installation/install-from-sources.md). In that case there are no releases to speak of: **stay on `master`**, and update before reporting anything:
 
 <Terminal shell title="xo — updating an installation from the sources">{`
 cd xen-orchestra

docs/docs/getting-started/requirements.md

@@ -1,10 +1,37 @@
 ---
-sidebar_position: 2
+sidebar_position: 1
 ---
 
-# Host compatibility list
+# Requirements
 
-Xen Orchestra connects to hosts running [XCP-ng](https://xcp-ng.org/) or [XenServer](https://www.xenserver.com/) (formerly Citrix Hypervisor), and only those: XO is **agent-less** and talks to the XAPI toolstack directly, so a Xen hypervisor installed from a regular Linux distribution will not work (see the [architecture section](architecture.md)).
+Before [deploying XOA](installation/xoa.md), check that your hosts are supported and plan the resources you give to the appliance.
+
+## XOA specifications {#xoa-vm-specifications}
+
+The deploy form on [vates.tech/deploy](https://vates.tech/deploy/) lets you size the VM at deployment, with three presets:
+
+| Preset | vCPUs | RAM | Typical usage |
+| --- | --- | --- | --- |
+| Small | 2 | 4 GiB | A few pools, no backup jobs, no V2V |
+| Medium | 4 | 8 GiB | Enterprise usage: backup jobs, V2V, more pools |
+| **Large** (default) | 8 | 16 GiB | Large infrastructures with backup jobs |
+
+The VM also needs 20 GiB of free SR space (2 GiB on a thin-provisioned SR).
+
+### Sizing your XOA {#sizing}
+
+The default preset targets large infrastructures running backup jobs, which is what most production deployments look like. A few rules of thumb:
+
+- **4 GiB and 2 vCPUs** is enough for a few pools without backups or V2V. 2 GiB is the strict minimum, for labs only.
+- As soon as you run backup jobs or V2V, use at least **8 GiB and 4 vCPUs**.
+- **16 GiB and 8 vCPUs** for large infrastructures or a heavy backup load: transfers and compression are parallel workloads, so they benefit from more vCPUs.
+- You can always give more, but **measure** afterwards to check the improvement is real before going further.
+
+You can resize the VM at any time: shut it down, change its vCPUs and RAM, and start it again. Since Xen Orchestra 6.8, `xo-server` sets its own memory limit to 70% of the VM's RAM at each start, so there is nothing else to change. If you deployed with another method, the VM starts with 2 vCPUs and 2 GiB: resize it right after deployment.
+
+## Host compatibility list
+
+Xen Orchestra connects to hosts running [XCP-ng](https://xcp-ng.org/) or [XenServer](https://www.xenserver.com/) (formerly Citrix Hypervisor), and only those: XO is **agent-less** and talks to the XAPI toolstack directly, so a Xen hypervisor installed from a regular Linux distribution will not work (see the [architecture section](../core-concepts/architecture.md)).
 
 Xen Orchestra should be functional with any version of these two platforms. For the best support quality, use the versions marked with full support below.
 
@@ -15,7 +42,7 @@ Xen Orchestra should be functional with any version of these two platforms. For
 | ☠️ | Platform without security updates anymore: upgrade your hosts! |
 | ❎ | Not all XO features supported |
 
-## XCP-ng
+### XCP-ng
 
 Xen Orchestra and XCP-ng are built by the same company ([Vates](https://vates.tech)) and ship together as [Vates VMS](https://docs.vates.tech/): one subscription covers the XCP-ng licenses for all your hosts and your Xen Orchestra Appliance, and each monthly release is tested as a stack. If you run the bundle and keep it updated, XO and XCP-ng compatibility is a given.
 
@@ -35,7 +62,7 @@ The table below matters if you run XO from the sources, manage a mixed estate, o
 The next major branch, XCP-ng 9.x, is in development for both x86 and ARM; its releases will appear here as they ship. Follow the [XCP-ng blog](https://xcp-ng.org/blog/) for announcements.
 :::
 
-## XenServer (formerly Citrix Hypervisor)
+### XenServer (formerly Citrix Hypervisor)
 
 :::note
 XenServer versioning changed over the years: the product was renamed Citrix Hypervisor for the 8.0 to 8.2 era, then back to XenServer. Since XenServer 8 there are no public point releases: versions are plain "XenServer 8" and "XenServer 9", each updated continuously through Early Access and Normal update channels.
@@ -58,4 +85,3 @@ XenServer versioning changed over the years: the product was renamed Citrix Hype
   {version: 'XenServer 6.1 and 6.2', status: '❎ ☠️', eol: true, notes: 'No official support (XML-RPC only, too CPU intensive); no incremental backup, no incremental replication'},
   {version: 'XenServer 5.x', status: '❎ ☠️', eol: true, notes: 'Basic administration only, no official support'},
 ]} />
-

docs/docs/getting-started/updater.md

@@ -1,6 +1,6 @@
 ---
 sidebar_label: Updates
-sidebar_position: 6
+sidebar_position: 5
 ---
 
 # Updating XOA
@@ -10,7 +10,7 @@ All updates are pushed through the updater, which is the central piece that keep
 It also allows you to change your current version into another (Free, Starter, Enterprise or Premium) **without downloading a new XOA**.
 
 :::tip
-By design, the updater is only available in XOA. If you are using XO from the sources, [update with `git` and rebuild](install-from-sources.md#updating).
+By design, the updater is only available in XOA. If you are using XO from the sources, [update with `git` and rebuild](installation/install-from-sources.md#updating).
 :::
 
 :::info Updating from XO 6

docs/docs/guides/_category_.json

@@ -1,8 +0,0 @@
-{
-    "label": "Guides",
-    "position": 7,
-    "link": {
-      "type": "generated-index",
-      "description": "Detailed guides on specific operations in XO"
-    }
-  }

docs/docs/intro.md

@@ -15,7 +15,7 @@ Everything goes through XO, and everything that talks to your infrastructure tal
 <Schema label="Xen Orchestra at the center of your infrastructure" legend={[["#6aabf0", "XO"], ["#8e83fe", "XCP-ng"], ["#56c288", "VMs"], ["#e0a94a", "backup"], ["#5ac8c8", "V2V"]]} maxWidth="760px">
 <svg viewBox="0 0 680 380" role="img" aria-label="Users and automation tools drive Xen Orchestra, which manages any number of XCP-ng pools, streams backups to a repository, keeps disaster recovery copies and imports VMware VMs with V2V">
 {/* Who talks to XO: humans and automation. */}
-<a href="/discover-xen-orchestra/gettingstarted" aria-label="The XO 6 web interface">
+<a href="/core-concepts/coreconcepts" aria-label="The XO 6 web interface">
 <rect x="20" y="12" width="170" height="62" rx="8" fill="rgba(255,255,255,0.04)" stroke="rgba(255,255,255,0.28)"/>
 <text x="105" y="37" fontSize="13.5" fill="#c6d2e1" textAnchor="middle">Your team</text>
 <text x="105" y="56" fontSize="11.5" fill="#7a8699" textAnchor="middle">Web UI · any browser</text>
@@ -46,7 +46,7 @@ grows a connection wire to it, the VM is converted (the teal copy
 rides through XO and lands green in Pool 1 while the original
 fades), then the empty cluster and its wire disappear: XO connects
 to VMware only for the migration. */}
-<a className="schema-live" href="/guides/v2v-migration-guide" aria-label="Migrate from VMware with V2V" opacity="0">
+<a className="schema-live" href="/migrate-from-vmware/v2v-migration-guide" aria-label="Migrate from VMware with V2V" opacity="0">
 <animate attributeName="opacity" dur="36s" repeatCount="indefinite"
       values="0;0;1;1;0;0" keyTimes="0;0.111;0.125;0.41;0.45;1"/>
 <rect x="20" y="115" width="140" height="62" rx="8" fill="none" stroke="rgba(255,255,255,0.22)" strokeDasharray="6 5"/>
@@ -66,7 +66,7 @@ grows out of XO toward it, and vanishes with it. */}
 <animate attributeName="opacity" dur="36s" repeatCount="indefinite"
       values="0;0;1;1;0;0" keyTimes="0;0.139;0.15;0.41;0.45;1"/>
 </line>
-<a href="/backups-and-dr/backup-types/full_replication" aria-label="Full replication">
+<a href="/replication/full_replication" aria-label="Full replication">
 <rect x="520" y="115" width="140" height="62" rx="8" fill="none" stroke="rgba(255,255,255,0.22)" strokeDasharray="6 5"/>
 <text x="530" y="132" fontSize="12.5" fill="#7a8699">DR site</text>
 <g opacity="0.45">
@@ -160,20 +160,20 @@ the parked standby. */}
 
 <CardGrid>
 <LinkCard title="Deploy Xen Orchestra" href="/getting-started/installation">Get the turnkey appliance (XOA) running in minutes, or install from the sources.</LinkCard>
-<LinkCard title="Discover XO 6" href="/discover-xen-orchestra/gettingstarted">Tour the new interface: tree view, dashboards, consoles.</LinkCard>
+<LinkCard title="Discover XO 6" href="/core-concepts/coreconcepts">Tour the new interface: tree view, dashboards, consoles.</LinkCard>
 <LinkCard title="Set up backups" href="/backups-and-dr/backup">Rolling snapshots, incremental backups, replication and more.</LinkCard>
-<LinkCard title="Migrate from VMware" href="/guides/v2v-migration-guide">Import your ESXi VMs directly into your pools with V2V.</LinkCard>
+<LinkCard title="Migrate from VMware" href="/migrate-from-vmware/v2v-migration-guide">Import your ESXi VMs directly into your pools with V2V.</LinkCard>
 <LinkCard title="Automate everything" href="/automation/restapi">REST API, CLI, Terraform, Ansible, Pulumi and more.</LinkCard>
-<LinkCard title="Get support" href="/support-and-licencing/support">Professional support by the Vates team, or community help.</LinkCard>
+<LinkCard title="Get support" href="/support-and-reference/support">Professional support by the Vates team, or community help.</LinkCard>
 </CardGrid>
 
 ## What XO does for you
 
-- **Administration**: complete control of your pools, hosts, VMs, storage and networks, from a [modern web interface](/discover-xen-orchestra/gettingstarted.md) or from XO 5.
+- **Administration**: complete control of your pools, hosts, VMs, storage and networks, from a [modern web interface](/core-concepts/coreconcepts/coreconcepts.md) or from XO 5.
 - **Backup and disaster recovery**: rolling snapshots, full and incremental backups, replication, mirroring and immutability, toward S3, NFS, SMB or Azure targets. See [Backups](/backups-and-dr/backups-in-xo6.md).
-- **Migration from VMware**: [V2V](/guides/v2v-migration-guide.md) imports your ESXi VMs directly into your pools.
+- **Migration from VMware**: [V2V](/migrate-from-vmware/v2v-migration-guide.md) imports your ESXi VMs directly into your pools.
 - **Automation**: a [REST API](automation/restapi.md), a CLI, and first-class providers for [Terraform](automation/terraform-provider.md), [Ansible](automation/ansible.md), [Pulumi](automation/pulumi-provider.md), [Packer](automation/packer-provider.md) and [PowerShell](automation/powershell-module.md), plus [Kubernetes cluster recipes](automation/kubernetes.md).
-- **Delegation**: users, groups and [RBAC](/users-and-access/rbac.md) to give each team exactly the access it needs.
+- **Delegation**: users, groups and [RBAC](/security/user-management/rbac.md) to give each team exactly the access it needs.
 - **Scale**: one XO manages any number of pools on any number of sites, over LAN or WAN.
 
 ## XO in the Vates VMS stack
@@ -192,4 +192,4 @@ The search bar at the top covers docs.xen-orchestra.com, docs.xcp-ng.org and doc
 
 ## Two interfaces, one product
 
-Xen Orchestra currently ships two web interfaces on the same server and the same data: **XO 6**, the new default interface, and **XO 5**, which remains available for the operations XO 6 does not cover yet. Read [XO 6 and XO 5](/discover-xen-orchestra/xo6vsxo5.md) to see what lives where.
+Xen Orchestra currently ships two web interfaces on the same server and the same data: **XO 6**, the new default interface, and **XO 5**, which remains available for the operations XO 6 does not cover yet. Read [XO 6 and XO 5](/whats-new/xo6vsxo5.md) to see what lives where.

docs/docs/manage-your-infrastructure/_category_.json

@@ -1,8 +1,9 @@
 {
-    "label": "Manage your infrastructure",
-    "position": 4,
-    "link": {
-      "type": "generated-index",
-      "description": "All the information to manage your infrastructure on a day-to-day basis"
-    }
-  }
+  "label": "Management",
+  "position": 6,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/manage-your-infrastructure",
+    "description": "All the information to manage your infrastructure on a day-to-day basis"
+  }
+}

docs/docs/manage-your-infrastructure/advanced.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 4
+sidebar_position: 6
 ---
 
 # Advanced features

docs/docs/manage-your-infrastructure/infrastructure/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Infrastructure",
+  "position": 3,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/infrastructure",
+    "description": "Pools, hosts, VMs and templates"
+  }
+}

docs/docs/manage-your-infrastructure/infrastructure/vm-templates.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 2
 ---
 
 # VM templates
@@ -42,7 +42,7 @@ Duplicate one of the built-in templates and customize it to match your needs.
 
 Set up a new VM (without installing an OS), adjust its hardware settings, and turn it into a template. This is useful if you just want a predefined hardware setup without an OS baked in.
 
-To learn more about VM creation, read the [VM creation](./manage_infrastructure#vm-creation) section.
+To learn more about VM creation, read the [VM creation](../manage_infrastructure.md#vm-creation) section.
 
 ## Viewing Template Properties
 
@@ -60,7 +60,7 @@ To check a template’s settings in Xen Orchestra:
 
 If you need more technical details than what the UI shows, the Xen Orchestra API has everything.
 
-To learn more, read the [REST API documentation](../automation/restapi.md).
+To learn more, read the [REST API documentation](../../automation/restapi.md).
 
 All collections are listed when you run `GET /rest/v0`, including the `vm-templates` collection:
 
@@ -148,7 +148,7 @@ This means that you can easily customize your VM when you create it from a compa
 
 As of release 5.101, Xen Orchestra also supports Cloudbase-init. This tool provides equivalent functionality to Cloud-init but is specifically designed for Windows virtual machines.
 
-To build such a template, follow the dedicated [Windows templates with Cloudbase-init](../guides/windows-templates.md) guide.
+To build such a template, follow the dedicated [Windows templates with Cloudbase-init](windows-templates.md) guide.
 
 ### Requirements
 
@@ -161,7 +161,7 @@ In XOA 5.31, we changed the Cloud-init config drive type from [OpenStack](https:
 
 ### Example: How to create a Cloudbase-init template with Windows Server?
 
-Refer to the [Windows templates with Cloudbase-init](../guides/windows-templates.md) guide for complete instructions.
+Refer to the [Windows templates with Cloudbase-init](windows-templates.md) guide for complete instructions.
 
 ### Example: How to create a Cloud-init template with Ubuntu 22.04 LTS?
 

docs/docs/manage-your-infrastructure/infrastructure/windows-templates.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 3
+---
+
 # Windows templates with Cloudbase-init
 
 This guide provides step-by-step instructions for creating Windows templates that support cloud-init, using [Cloudbase-init](https://cloudbase.it/cloudbase-init/).

docs/docs/manage-your-infrastructure/manage_infrastructure.md

@@ -291,7 +291,7 @@ These templates will use PV configuration in order to boot: either from the righ
 
 Because there is already disks installed, you shouldn't have "Install settings" _per se_. But you can use our `config drive` setup if your template already has CloudInit installed!
 
-Please refer to the [XCP-ng CloudInit section](vm-templates.md#cloud-init) for more.
+Please refer to the [XCP-ng CloudInit section](infrastructure/vm-templates.md#cloud-init) for more.
 
 #### Interfaces
 
@@ -393,7 +393,7 @@ If Xen Orchestra knows the VM’s IP address (either through the guest agent or
 
 #### How do I automate VIF locking mode?
 
-If you’re automating things or working with scripts, you can also control VIF locking mode through the XO [command-line interface](../getting-started/architecture.md#xo-cli).
+If you’re automating things or working with scripts, you can also control VIF locking mode through the XO [command-line interface](../core-concepts/architecture.md#xo-cli).
 
 ### VM high availability (HA)
 
@@ -521,7 +521,7 @@ VM migration with storage motion allows you to migrate a VM from one host to ano
 
 ### Warm migration
 
-Warm migration moves a running VM to another SR, including on another pool, with minimal downtime. Unlike the migrations above, the data doesn't go directly from host to host: Xen Orchestra reads the VM from the source and writes it to the destination, using the same mechanism as [incremental replication](../backups-and-dr/backup-types/incremental_replication.md).
+Warm migration moves a running VM to another SR, including on another pool, with minimal downtime. Unlike the migrations above, the data doesn't go directly from host to host: Xen Orchestra reads the VM from the source and writes it to the destination, using the same mechanism as [incremental replication](../replication/incremental_replication.md).
 
 #### How it works
 
@@ -885,7 +885,7 @@ Visualizations can help you to understand your XCP-ng/XenServer infrastructure,
 The dashboard view gathers information on all your connected pools/hosts.
 
 :::note
-Since XO 6 became the default interface, `https://your-xo/#/dashboard` opens the [new XO 6 dashboard](../manage-your-infrastructure/management.md). The XO 5 dashboard described here now lives under `/v5/`.
+Since XO 6 became the default interface, `https://your-xo/#/dashboard` opens the [new XO 6 dashboard](management.md). The XO 5 dashboard described here now lives under `/v5/`.
 :::
 
 <UiShot light="/img/xo5/dashboard-overview.png" alt="The Overview aggregates pools, hosts, VMs, resource usage and alarms at a glance" url="https://your-xo/v5/#/dashboard/overview" />
@@ -950,7 +950,7 @@ List of VMs with missing or outdated guest tools. It's best practice to [install
 
 ### Alarms
 
-This sections details the alerts coming from XCP-ng/XenServer hosts. More information can be found on [this page](advanced#alerts).
+This sections details the alerts coming from XCP-ng/XenServer hosts. More information can be found on [this page](advanced.md#alerts).
 
 ### Heatmap
 

docs/docs/manage-your-infrastructure/management.md

@@ -4,7 +4,7 @@ sidebar_position: 1
 
 # Management in XO 6
 
-This page walks through day-to-day management in XO 6: pools, hosts and VMs. For the general layout and navigation, start with [XO 6 at a glance](../discover-xen-orchestra/gettingstarted.md).
+This page walks through day-to-day management in XO 6: pools, hosts and VMs. For the general layout and navigation, start with [How XO is organized](../core-concepts/coreconcepts/coreconcepts.md).
 
 ## Pools
 
@@ -87,7 +87,7 @@ A rule is simple to express: allow or block, a protocol (ARP, ICMP, IP, TCP or U
 <UiShot light="/img/xo6/traffic-rule-new-light.png" dark="/img/xo6/traffic-rule-new-dark.png" alt="The new traffic rule form: policy, protocol, direction, IP range, and the network or VIF it applies to" url="https://your-xo/v6/#/traffic-rule/new" />
 
 :::warning Prerequisites
-Traffic rules are enforced by the [SDN Controller plugin](../manage-your-infrastructure/sdn_controller.md): it must be loaded, and switched to the **XAPI plugin** mode ([`useDirectChannel = false`](../getting-started/configuration.md#sdn-controller-mode)). XO 6 shows a notification guiding you through the switch, and a [migration script](../manage-your-infrastructure/sdn_controller.md#migration-path) converts existing rules.
+Traffic rules are enforced by the [SDN Controller plugin](networking/sdn_controller.md): it must be loaded, and switched to the **XAPI plugin** mode ([`useDirectChannel = false`](../getting-started/configuration.md#sdn-controller-mode)). XO 6 shows a notification guiding you through the switch, and a [migration script](networking/sdn_controller.md#migration-path) converts existing rules.
 :::
 
 Everything is also available through the [REST API](../automation/restapi.md), where rules can additionally be updated in place, making network policies easy to automate.
@@ -98,4 +98,8 @@ The **Administration** tab of the sidebar covers who can access your Xen Orchest
 
 <UiShot light="/img/xo6/administration-light.png" dark="/img/xo6/administration-dark.png" alt="The administration panel" url="https://your-xo/v6/#/admin/user-management/users" />
 
-For the permission model itself (roles, scopes and delegation), see [RBAC](../users-and-access/rbac.md).
+For the permission model itself (roles, scopes and delegation), see [RBAC](../security/user-management/rbac.md).
+
+### Authentication providers
+
+Users can log in with a built-in account, or through an external authentication provider such as LDAP, OpenID Connect, SAML, GitHub or Google. These providers are set up from the XO 5 interface: see [Security → User management → Authentication providers](../security/user-management/authentication-providers.md).

docs/docs/manage-your-infrastructure/networking/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Networking",
+  "position": 4,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/networking",
+    "description": "Networks and software-defined networking"
+  }
+}

docs/docs/manage-your-infrastructure/networking/sdn_controller.md

@@ -1,10 +1,10 @@
 ---
-sidebar_position: 5
+sidebar_position: 1
 ---
 
 # SDN controller
 
-<InterfaceNote>Private networks are currently created and managed from XO 5. Traffic rules moved ahead in [XO 6](../manage-your-infrastructure/management.md#traffic-rules), with more capabilities than the XO 5 equivalent.</InterfaceNote>
+<InterfaceNote>Private networks are currently created and managed from XO 5. Traffic rules moved ahead in [XO 6](../management.md#traffic-rules), with more capabilities than the XO 5 equivalent.</InterfaceNote>
 
 :::tip
 Be sure to enable the plugin on only one XOA instance.
@@ -104,7 +104,7 @@ In the network creation view:
 
 ### Configuration
 
-Like all other xo-server plugins, it can be configured directly via the web interface, see [the plugin documentation](../getting-started/architecture.md#plugins).
+Like all other xo-server plugins, it can be configured directly via the web interface, see [the plugin documentation](../plugins/plugins.md).
 
 The plugin's configuration contains:
 
@@ -140,7 +140,7 @@ At this time, the two options are covered until we can fully deprecate the older
 Where the UI lives:
 
 - **XO 5**: per-VIF rules only, from the VM **Network** tab (described [below](#openflow-protocol))
-- **XO 6**: the full experience, network-wide **and** per-VIF rules, with a consolidated pool view: see [Traffic rules in XO 6](./management.md#traffic-rules). It requires the XAPI plugin backend.
+- **XO 6**: the full experience, network-wide **and** per-VIF rules, with a consolidated pool view: see [Traffic rules in XO 6](../management.md#traffic-rules). It requires the XAPI plugin backend.
 
 ### OpenFlow Protocol
 
@@ -179,11 +179,11 @@ A few caveats:
 
 - This is still in BETA and should not be used in production yet.
 - This will only work on XCP-ng, not on XenServer hosts.
-- This is not enabled by default, and requires a configuration change for `xo-server`. See [the configuration page](../getting-started/configuration.md#sdn-controller-mode) to know more.
+- This is not enabled by default, and requires a configuration change for `xo-server`. See [the configuration page](../../getting-started/configuration.md#sdn-controller-mode) to know more.
   :::
 
 :::tip
-This is the backend used by the [XO 6 traffic rules UI](./management.md#traffic-rules) (since XO 6.5): network-wide and per-VIF rules, with a consolidated view in the pool **Traffic rules** tab. The rules can also be managed through the [REST API](../automation/restapi.md), including in-place updates (since XO 6.7).
+This is the backend used by the [XO 6 traffic rules UI](../management.md#traffic-rules) (since XO 6.5): network-wide and per-VIF rules, with a consolidated view in the pool **Traffic rules** tab. The rules can also be managed through the [REST API](../../automation/restapi.md), including in-place updates (since XO 6.7).
 :::
 
 - Works on any network:
@@ -195,7 +195,7 @@ This is the backend used by the [XO 6 traffic rules UI](./management.md#traffic-
 
 To setup a per-VIF rule using the UI, follow the [openflow instructions](#openflow-protocol) above, as the UI is the same and only the backend changes.
 
-Here, we describe how to use `xo-cli` to configure rules. First, make sure to register xo-cli to your XOA instance as documented in [its documentation](../getting-started/architecture.md#xo-cli).
+Here, we describe how to use `xo-cli` to configure rules. First, make sure to register xo-cli to your XOA instance as documented in [its documentation](../../core-concepts/architecture.md#xo-cli).
 
 - Add per-VIF rules: `xo-cli sdnController.addRule vifId=<VIF_UUID> <parameters>`
 - Delete per-VIF rules: `xo-cli sdnController.deleteRule vifId=<VIF_UUID> <parameters>`
@@ -258,7 +258,7 @@ Existing rules will first be removed before restoring the saved ones.
 
 #### How to use the script
 
-The migration script is available as [sdn-migration.py (download script)](../../static/sh/sdn-migration.py).
+The migration script is available as [sdn-migration.py (download script)](../../../static/sh/sdn-migration.py).
 
 <Terminal shell title="migrate the rules (backup written to rules-channel.json)">{`
 # Export current rules to rules-channel.json and convert to XAPI format
@@ -301,7 +301,7 @@ We provide a script to run from a host that has access to your pool. To run the
 - The list of the addresses of your pool masters.
 - (optional) If your infrastructure is on the bigger side, it may be better to have ssh agents configured with keys to avoid the need to pass all the passwords.
 
-[check-sdn-features.sh (download script)](../../static/sh/check-sdn-features.sh)
+[check-sdn-features.sh (download script)](../../../static/sh/check-sdn-features.sh)
 
 Copy the file to where you want to run the script, then run this:
 
@@ -361,7 +361,7 @@ The update present in the `latest` channel will probably be available later than
 
 We provide a helper script to run on your XOA VM:
 
-[regenerate-certs.sh (download script)](../../static/sh/regenerate-certs.sh)
+[regenerate-certs.sh (download script)](../../../static/sh/regenerate-certs.sh)
 
 <Terminal shell title="regenerate the certificates, on your XOA">{`
 sudo bash -e ./regenerate-certs.sh

docs/docs/manage-your-infrastructure/plugins/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Plugins",
+  "position": 5
+}

docs/docs/manage-your-infrastructure/plugins/ipmi-plugin.md

@@ -1,5 +1,6 @@
 ---
-sidebar_position: 6
+slug: /manage-your-infrastructure/ipmi-plugin
+sidebar_position: 1
 ---
 
 # IPMI

docs/docs/manage-your-infrastructure/plugins/load_balancing.md

@@ -1,5 +1,6 @@
 ---
-sidebar_position: 5
+slug: /manage-your-infrastructure/load_balancing
+sidebar_position: 2
 ---
 
 # Load balancing
@@ -18,7 +19,7 @@ In the case of virtualization, you have multiple physical hosts, which run your
 You may have heard about VMware DRS (Distributed Resource Scheduler). That's the same principle here, but for XCP-ng.
 :::
 
-The first goal is to adapt your VM placement in real time, without service interruption, depending on the load. Since Xen Orchestra is connected to [multiple pools](../getting-started/architecture.md#xo-server) and XCP-ng supports live storage motion, we can perform load balancing on a **whole XCP-ng infrastructure**, even between remote datacenters.
+The first goal is to adapt your VM placement in real time, without service interruption, depending on the load. Since Xen Orchestra is connected to [multiple pools](../../core-concepts/architecture.md#xo-server) and XCP-ng supports live storage motion, we can perform load balancing on a **whole XCP-ng infrastructure**, even between remote datacenters.
 
 :::tip
 A load balancing policy is called a **plan**.
@@ -300,7 +301,7 @@ The global situation (resource usage) is examined **every minute**, and each run
 Every migration decided by the plugin is visible in the XO **Tasks** view, as a task named "Load balancer migrates VM …" whose description tells you the source, the destination and the *reason*: CPU over threshold for too long, CPU significantly higher than the pool average, vCPU balancing, affinity or anti-affinity satisfaction, or a density-plan host shutdown. Nothing moves silently.
 
 :::tip
-During a [Rolling Pool Update](./manage_infrastructure#rolling-pool-updates-rpu), the load balancer is automatically suspended, and re-enabled 30 minutes after the update completes, so the two features never fight over VM placement.
+During a [Rolling Pool Update](../manage_infrastructure.md#rolling-pool-updates-rpu), the load balancer is automatically suspended, and re-enabled 30 minutes after the update completes, so the two features never fight over VM placement.
 :::
 
 ### Advanced settings

docs/docs/manage-your-infrastructure/plugins/plugins.md

@@ -0,0 +1,26 @@
+---
+sidebar_position: 1
+---
+
+# Plugins
+
+Plugins extend Xen Orchestra without touching its core. They live in **Settings → Plugins** of the XO 5 interface:
+
+<UiDetail src="/img/xoa/plugins-menu.png" alt="The Plugins page in Settings" width={520} />
+
+Each plugin can be activated or deactivated, loaded at startup, and configured entirely from the web interface:
+
+<UiDetail src="/img/xoa/plugins-page.png" alt="Configuring a plugin from the web interface" width={520} />
+
+## Plugins to manage your infrastructure
+
+- [IPMI](ipmi-plugin.md): read the IPMI hardware sensors of your hosts, and categorize the ones Xen Orchestra does not recognize.
+- [Load balancing](load_balancing.md): place and move your VMs automatically across hosts, depending on their load and on affinity rules.
+
+## Other plugins
+
+Other plugins are documented with the feature they serve:
+
+- [SDN controller](../networking/sdn_controller.md), for private networks and traffic rules,
+- [Backup reports](../../backups-and-dr/backup_reports.md), to get notified about your backup jobs,
+- [Authentication providers](../../security/user-management/authentication-providers.md), to log in with LDAP, OpenID Connect, SAML, GitHub or Google.

docs/docs/migrate-from-vmware/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Migrate from VMware",
+  "position": 11,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/migrate-from-vmware",
+    "description": "Move your VMs from VMware to XCP-ng"
+  }
+}

docs/docs/migrate-from-vmware/v2v-migration-guide.md

@@ -1,5 +1,6 @@
 ---
 sidebar_label: VMware migration (V2V)
+sidebar_position: 1
 ---
 
 # VMware migration (V2V)

docs/docs/project/_category_.json

@@ -1,8 +1,9 @@
 {
-    "label": "Project",
-    "position": 9,
-    "link": {
-      "type": "generated-index",
-      "description": "Project overview, governance, development, and community"
-    }
-  }
+  "label": "Project",
+  "position": 13,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/project",
+    "description": "Project overview, governance, development, and community"
+  }
+}

docs/docs/project/contributing.md

@@ -45,7 +45,7 @@ The best way to propose a change to the documentation or code is
 to create a [GitHub pull request](https://help.github.com/articles/using-pull-requests/).
 
 1. Fork the [Xen Orchestra repository](https://github.com/vatesfr/xen-orchestra) using the Fork button
-2. Follow [the documentation](../getting-started/install-from-sources.md) to install and run Xen Orchestra from the sources
+2. Follow [the documentation](../getting-started/installation/install-from-sources.md) to install and run Xen Orchestra from the sources
 3. Create a branch for your work
 4. Edit the source files
 5. Add a summary of your changes to `CHANGELOG.unreleased.md`, if your changes do not relate to an existing changelog item and update the list of packages that must be released to take your changes into account

docs/docs/project/intro_project.md

@@ -14,12 +14,12 @@ Xen Orchestra is an Open Source project with more than 15 years of history. Orig
 - **December 2012**: the project is rebooted on top of XAPI for XenServer, with the first commit of the current codebase.
 - **February 2014**: XO 3.0, the first release of the rebooted project.
 - **May 2015**: XO 4.0, with a fully redesigned web interface.
-- **June 2016**: XO 5.0, the first release of the generation still known today as [XO 5](../discover-xen-orchestra/xo6vsxo5.md).
+- **June 2016**: XO 5.0, the first release of the generation still known today as [XO 5](../whats-new/xo6vsxo5.md).
 - **2018**: after Citrix closed a lot of XenServer features, Olivier Lambert launched [XCP-ng](https://xcp-ng.org), a fully open source fork of XenServer: successful Kickstarter campaign in early 2018, first release (XCP-ng 7.4) on March 31, 2018.
 - **2022**: work starts on [XO Lite](https://docs.vates.tech/products/add-ons/xo-lite), the lightweight web UI embedded in every XCP-ng host.
-- **January 2023**: first preview of [V2V](../guides/v2v-migration-guide.md), the built-in tool to migrate VMs directly from VMware to XCP-ng.
+- **January 2023**: first preview of [V2V](../migrate-from-vmware/v2v-migration-guide.md), the built-in tool to migrate VMs directly from VMware to XCP-ng.
 - **November 2025**: XO 5.113, the last feature release of the 5.x series.
-- **December 2025**: XO 6.0, the first official release of the new [XO 6](../discover-xen-orchestra/gettingstarted.md) interface, becomes the default UI.
+- **December 2025**: XO 6.0, the first official release of the new [XO 6](../core-concepts/coreconcepts/coreconcepts.md) interface, becomes the default UI.
 - **February 2026**: XO 6.2 introduces [distributed backups](../backups-and-dr/scale-and-security/distributed_backups.md), spreading backup data across multiple backup repositories (BR).
 - **March 2026**: XO 6.3 brings symmetrical replication and a rewritten immutable backup engine.
 - **May 2026**: XO 6.5 delivers QCOW2 general availability (disks beyond the 2 TiB VHD limit), bidirectional replication and traffic rules on networks and VIFs.

docs/docs/project/project-resources.md

@@ -1,7 +0,0 @@
-# Project resources
-
-The following resources provide information about the Xen Orchestra project:
-
-* [Xen Orchestra blog](https://xen-orchestra.com/blog/): News, announcements, and articles about Xen Orchestra.
-* [Changelog](https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.md#changelog): A list of changes and updates for Xen Orchestra releases.
-* [Product roadmap](https://docs.vates.tech/product-roadmap/): An overview of planned and upcoming features and improvements.

docs/docs/replication/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Replication",
+  "position": 8,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/replication",
+    "description": "Replicate your VMs to another storage or pool"
+  }
+}

docs/docs/replication/full_replication.md

@@ -1,5 +1,6 @@
 ---
 sidebar_label: Full replication (DR)
+sidebar_position: 1
 ---
 
 # Full replication
@@ -97,4 +98,4 @@ When you actually need to run a replica, you have two options, and both take it
 
 The day the production side is gone, the procedure is short: go to the DR pool, take the most recent replica of each VM, clone it or unblock it, fix the network settings if needed, and start it. Your services are back without waiting for any restore.
 
-Because full replication re-sends the entire VM at each run, its practical RPO is limited by how long a full export takes. If you need more frequent runs and a lower RPO, look at [incremental replication](./incremental_replication.md), which only transfers the changed blocks. To decide how replication fits with your other backup jobs, see the [backup strategy guide](../backup_howto.md).
+Because full replication re-sends the entire VM at each run, its practical RPO is limited by how long a full export takes. If you need more frequent runs and a lower RPO, look at [incremental replication](./incremental_replication.md), which only transfers the changed blocks. To decide how replication fits with your other backup jobs, see the [backup strategy guide](../backups-and-dr/backup_howto.md).

docs/docs/replication/incremental_replication.md

@@ -1,5 +1,6 @@
 ---
 sidebar_label: Incremental replication (CR)
+sidebar_position: 2
 ---
 
 # Incremental replication

docs/docs/security/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Security",
+  "position": 9,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/security",
+    "description": "Users, access rights and the security of your Xen Orchestra"
+  }
+}

docs/docs/security/credential-encryption.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 2
+---
+
 # Credential database encryption
 
 Xen Orchestra stores its records (server connections, backup jobs and remotes, schedules, users, groups, authentication tokens, ACLs, tags, cloud configs, proxy registrations and plugin configurations) in Redis. When credential encryption is enabled, every record is encrypted at rest with AES-256-GCM (encrypted values carry an `enc:` prefix), and index keys are replaced with HMAC-SHA256 blind indexes so indexed field values (emails, hostnames, etc.) are never stored as plaintext. The performance impact is negligible for typical deployments.

docs/docs/security/user-management/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "User management",
+  "position": 1,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/user-management",
+    "description": "Authentication, users, groups and access rights"
+  }
+}

docs/docs/security/user-management/authentication-providers.md

@@ -1,23 +1,10 @@
-# Users
+---
+sidebar_position: 1
+---
 
-<InterfaceNote>This page describes user management in the XO 5 interface. XO 6 currently lists users (with their groups and tokens); creating and editing them still happens here.</InterfaceNote>
+# Authentication providers
 
-Xen Orchestra involves three distinct notions of "user account". Make sure you are looking at the right one:
-
-- **XOA system accounts**: the Linux accounts (`xoa`, `root`) of the appliance itself, used for SSH and console access. See [First login](../getting-started//installation.md#first-login).
-- **XO application users**: the accounts inside the Xen Orchestra web application. This is what this page is about.
-- **XO 6 / REST API roles**: XO 6 introduces a new RBAC model with roles and fine-grained privileges. See the [RBAC page](./rbac.md).
-
-There are 2 types of XO users:
-
-- **admins**, with all rights on all connected resources
-- **users**, with no rights by default
-
-:::note
-Local user accounts should be avoided in production environments. LDAP authentication is strongly recommended for centralized credential management.
-:::
-
-## Authentication
+<InterfaceNote>This page describes the XO 5 interface, where authentication providers are configured.</InterfaceNote>
 
 Xen Orchestra supports various types of user authentication, internal or even external thanks to the usage of the [Passport library](http://passportjs.org/).
 
@@ -26,7 +13,7 @@ Any account created by an external authentication process (LDAP, SSO...) will be
 Also, you don't have to create an external user by yourself: it will be created automatically in Xen Orchestra after its first connection.
 :::
 
-### Built-in
+## Built-in
 
 This is the default method. Creating a user is very simple:
 
@@ -37,7 +24,7 @@ This is the default method. Creating a user is very simple:
 
 By default, a _user_ won't have any permissions. At the opposite, an _admin_ will have all rights.
 
-#### OTP Authentication (2FA)
+### OTP Authentication (2FA)
 
 Xen Orchestra supports **Time-based One-Time Password (TOTP)** to provide an additional layer of security for your user account. When enabled, you will be required to provide a temporary code from an authentication app in addition to your standard credentials during login.
 
@@ -45,7 +32,7 @@ Xen Orchestra supports **Time-based One-Time Password (TOTP)** to provide an add
 Enabling OTP authentication is **strongly recommended** for every account, especially admins. A password alone can be guessed through brute force attacks: with OTP enabled, a valid password isn't enough to log in without the temporary code generated by the user's authentication app.
 :::
 
-##### Enabling TOTP
+#### Enabling TOTP
 
 To activate two-factor authentication on your account:
 
@@ -67,11 +54,11 @@ To activate two-factor authentication on your account:
 Once activated, any future login attempts will prompt you for a new code generated by your application.
 :::
 
-##### Disabling TOTP
+#### Disabling TOTP
 
 To disable this feature, return to your profile settings and toggle the **OTP authentication** switch to **Off**. You will be asked to provide a final OTP code to confirm the deactivation.
 
-### LDAP
+## LDAP
 
 XO currently supports connections to LDAP directories, like _Open LDAP_ or _Active Directory_, through the `auth-ldap` plugin.
 
@@ -90,7 +77,7 @@ XO currently supports connections to LDAP directories, like _Open LDAP_ or _Acti
    2. To check if the plugin is activated, activate the toggle switch next to the **auth-ldap** plugin name.\
       The switch should now appear green.
 
-#### Common LDAP Filters
+### Common LDAP Filters
 
 LDAP Filters allow you to properly match your user. Finding the right filter is no easy task, and it entirely depends on your LDAP configuration.
 
@@ -102,7 +89,7 @@ Still, here is a list of common filters:
 
 Once configured, users can authenticate using their LDAP credentials. Upon a successful initial login, the user's account will appear in the XO user list.
 
-#### Group Synchronization
+### Group Synchronization
 
 The LDAP plugin allows for the synchronization of user groups.
 
@@ -168,7 +155,7 @@ Importing the groups won't import their members. Users will still be imported on
 To find the LDAP users, enter this filter in the users table: `authProviders:ldap?`.
 :::
 
-#### Troubleshooting
+### Troubleshooting
 
 If users can authenticate but group memberships are not reflected:
 
@@ -194,9 +181,9 @@ If users can authenticate but group memberships are not reflected:
 3. Ensure that the **ID Attribute** for both users and groups is unique and correctly specified.
 4. Check XO logs for any synchronization errors and adjust configurations accordingly.
 
-### OpenID Connect
+## OpenID Connect
 
-#### Overview
+### Overview
 
 The OpenID Connect (OIDC) plugin (`auth-oidc`) allows Xen Orchestra to integrate with identity providers that support the OIDC protocol.
 
@@ -205,13 +192,13 @@ In this section, you'll learn:
 - how users can log in with OpenID Connect
 - how administrators can configure the plugin to suit their needs
 
-#### Prerequisites
+### Prerequisites
 
 - Make sure your identity provider supports OpenID Connect.
 
-#### User Workflow
+### User Workflow
 
-##### Log In with OpenID Connect
+#### Log In with OpenID Connect
 
 On the Xen Orchestra login page, click **Sign in with OpenID Connect**
 
@@ -219,9 +206,9 @@ On the Xen Orchestra login page, click **Sign in with OpenID Connect**
 
 You'll be redirected to the login page of your internal portal. Once authenticated on it, you will be redirected to the Xen Orchestra home page.
 
-#### Administrator Guide
+### Administrator Guide
 
-##### Set Up the OpenID Connect Plugin
+#### Set Up the OpenID Connect Plugin
 
 You can set up the `auth-oidc` plugin directly in Xen Orchestra:
 
@@ -231,14 +218,14 @@ You can set up the `auth-oidc` plugin directly in Xen Orchestra:
 
 <UiDetail src="/img/xo5/oidc-plugin-config.png" alt="The auth-oidc plugin configuration: auto-discovery URL, client identifier and client secret" width={620} />
 
-##### Required Configuration
+#### Required Configuration
 
 Fill in the mandatory fields: the **Client identifier (key)** and **Client secret** from your identity provider. You also need to tell the plugin where to find your provider's endpoints, either way:
 
 - **Auto-discovery URL**: the OIDC discovery URL provided by your identity provider (the simplest option), or
 - the **Advanced** section, by filling the **Authorization URL**, **Issuer**, **Token URL** and **User info URL** manually.
 
-##### Advanced Configuration (Optional)
+#### Advanced Configuration (Optional)
 
 To access advanced options:
 
@@ -248,16 +235,16 @@ To access advanced options:
    - **Username field**: the field to use as the XO username, e.g. `displayName`, `username` or `email` (defaults to `username`).
    - **Scopes**: the scopes from which to request profile information, separated by whitespace (defaults to `profile`; the `openid` scope is implicitly included).
 
-##### Save and Activate the Plugin
+#### Save and Activate the Plugin
 
 1. Once everything is configured, click **Save configuration**.
 2. Toggle the switch next to the `auth-oidc` plugin name to enable it. This will:
    - Activate the plugin immediately.
    - Ensure it loads automatically when the Xen Orchestra server restarts.
 
-##### Enabling Passkeys in XOA with Keycloak
+#### Enabling Passkeys in XOA with Keycloak
 
-###### Generating certificates
+##### Generating certificates
 
 To support passkeys in XOA, the Keycloak server must expose its OIDC endpoints over HTTPS.
 The TLS certificates used by Keycloak must satisfy the following conditions:
@@ -290,7 +277,7 @@ Fingerprints
 
 With this configuration, Keycloak can participate in passkey authentication flows that XOA expects, and the `auth-oidc` plugin will correctly validate the TLS connection.
 
-###### Trust the Keycloak cert in XOA
+##### Trust the Keycloak cert in XOA
 
 1. Place the CA certificate used to sign Keycloak's cert on the xo-server host (e.g., `/etc/ssl/poc.crt`).
 2. Edit the xo-server systemd service at `/etc/systemd/system/xo-server.service` to add the environment variable `NODE_EXTRA_CA_CERTS`:
@@ -311,7 +298,7 @@ Environment="NODE_EXTRA_CA_CERTS=/etc/ssl/poc.crt"
 WantedBy=multi-user.target
 `}</Terminal>
 
-###### Configuring Keycloak
+##### Configuring Keycloak
 
 1. Select your realm.
 
@@ -335,7 +322,7 @@ WantedBy=multi-user.target
 
 These settings allow users to register and log in with FIDO2 (passkeys) while keeping a password + Yubikey MFA option.
 
-###### Sample
+##### Sample
 
 1. Initiate the OIDC authentication request from the XOA client to Keycloak.
 
@@ -349,13 +336,13 @@ These settings allow users to register and log in with FIDO2 (passkeys) while ke
 
    <UiDetail src="/img/xo5/keycloak-passkey-flow-3.png" alt="The Keycloak second-factor challenge waiting for the security key" width={700} />
 
-### SAML
+## SAML
 
 The `auth-saml` plugin allows SAML users to authenticate to Xen Orchestra.
 
 The first time a user signs in, XO will create a new XO user with the same identifier.
 
-#### Configuration
+### Configuration
 
 :::warning
 When registering your Xen Orchestra instance to your identity provider, you must configure its callback URL to `https://<xo.company.net>/signin/saml/callback`!
@@ -382,9 +369,9 @@ Since XO 5.111.1, you need to configure signature for Document **and** Assertion
 - **Google Workspace:** In the Service Provider details, check the **Signed response** box.
   :::
 
-#### Vendor specific
+### Vendor specific
 
-##### Google Workspace {#google-workspace---saml-supportgooglecom}
+#### Google Workspace {#google-workspace---saml-supportgooglecom}
 
 Google documents its SAML setup on [support.google.com](https://support.google.com/a/answer/6087519?hl=en#zippy=). Use the screenshots below as a reference as how to set up SAML with Google Workspace.
 
@@ -410,7 +397,7 @@ Also make sure to adjust the SAML attribute mapping in the Google Workspace conf
 
 <UiDetail src="/img/xo5/saml-google-workspace-attribute-mapping.png" alt="The Google Workspace SAML attribute mapping, with Primary email mapped to email" width={620} />
 
-### GitHub
+## GitHub
 
 The `auth-github` plugin allows any GitHub user to authenticate to Xen Orchestra.
 
@@ -432,13 +419,13 @@ Be sure to activate the plugin after you save the configuration (button on top).
 
 <UiDetail src="/img/xo5/github-signin-link.png" alt="The XO login page with the GitHub sign in link below the credentials form" width={620} />
 
-### Google
+## Google
 
 The `auth-google` plugin allows Google users to authenticate to Xen Orchestra.
 
 The first time a user signs in, XO will create a new XO user with the same identifier, without any permissions.
 
-#### Creating the Google project
+### Creating the Google project
 
 Go to Google's [Credentials page](https://console.developers.google.com/apis/credentials) and create a new project:
 
@@ -454,7 +441,7 @@ Get your client ID and client secret:
 
 <UiDetail src="/img/xo5/google-client-id-secret.png" alt="The modal displaying the generated OAuth client ID and client secret" width={480} />
 
-#### Configure the XO plugin
+### Configure the XO plugin
 
 In Settings, then Plugins, expand the Google plugin details and configure it with the information from the Google Console:
 
@@ -470,204 +457,3 @@ The optional **scope** setting selects which profile information is used to buil
 Be sure to activate the plugin after you save the configuration (button on top).
 
 You can now connect with your Google account in the login page.
-
-## ACLs
-
-### Definition
-
-ACLs are permissions that apply to preexisting objects, like users and groups.
-
-:::note
-This section describes the original ACLs, used by the XO 5 interface. The REST API and XO 6 use a broader model: see [RBAC](./rbac.md).
-:::
-
-### Who can manage ACLs?
-
-Only a super admin (XO administrator) can manage ACLs.
-
-### How can I view and edit ACLs?
-
-The ACLs view can be accessed in the **Settings** panel.
-
-1. Select the user or group you want to apply permissions on
-2. Select the object on which the permission will apply
-3. Choose the role for this ACL
-4. Click the **Create** button.
-
-<UiDetail src="/img/xo5/acl-creation.png" alt="The ACL creation form: subject, object and role selectors followed by the Create button" width={700} />
-
-:::tip
-You can click to add multiple objects at the same time!
-:::
-
-Your ACL is now available in the right list:
-
-<UiDetail src="/img/xo5/acl-list.png" alt="The list of existing ACLs, each row showing the user, the object and the assigned role" width={620} />
-
-You can edit or remove existing ACLs here.
-
-### Roles
-
-There are 3 different roles for your users:
-
-- Admin
-- Operator
-- Viewer
-
-#### Admin
-
-An object admin can do everything on it, even destroy it. E.g with its admin VM:
-
-- remove it
-- migrate it (to a host with admin permission on it)
-- modify the VM resources, name and description
-- clone it
-- copy it
-- convert it into a template
-- snapshot it (even revert from a snapshot)
-- export it
-- attach/add visible disks
-- same for network cards
-
-#### Operator
-
-An operator can make everyday operations on assigned objects. For example, on a VM:
-
-- eject a CD
-- insert a CD (if he can view the ISO storage repository)
-- start, restart, shutdown, suspend/resume it
-
-All other operations are forbidden.
-
-#### Viewer
-
-A viewer can only see the VM state and its metrics. That's all!
-
-### Inheritance
-
-Objects have a hierarchy: a Pool contains all its hosts, containing itself all its VMs.
-
-If you give a _view_ permission to a user (or a group) on a pool, he will automatically see all the objects inside this pool (SRs, hosts, VMs).
-
-### Examples
-
-#### Allow a user to install an OS
-
-If the OS install needs an ISO, you need to give this user 2 permissions:
-
-- _Operate_ on the VM (e.g to start it)
-- _View_ on the ISO Storage containing the needed ISO.
-
-## Self-service portal
-
-The self-service feature allows users to create new VMs. This is different from delegating existing resources (VMs) to them, and it leads to a lot of possibilities.
-
-### Set of resources
-
-To create a new set of resources to delegate, go to the "Self Service" section in the main menu:
-
-<UiDetail src="/img/xo5/self-service-menu.png" alt="The Self Service entry in the XO main menu" width={180} />
-
-#### Create a set
-
-:::tip
-Only an admin can create a set of resources
-:::
-
-To allow people to create VMs as they want, we need to give them a _part_ of your XCP-ng/XenServer resources (disk space, CPUs, RAM). You can call this "general quotas" if you like. But you first need to decide which resources will be used.
-
-In this example below, we'll create a set called **"sandbox"** with:
-
-- "devs" is the group that can use this set (all users in the group)
-- "Lab Pool" is the pool where they can play
-- "Debian 8 Cloud Ready" is the only template they can use
-- "SSD NFS" is the only SR where they can create VMs
-- "Pool-wide network with eth0" is the only available network for them
-
-<UiDetail src="/img/xo5/self-service-set-creation.png" alt="The resource set creation form: name, subjects, pools, templates, SRs, networks and limits, with the eligible hosts below" width={700} />
-
-As you can see, only compatible hosts are shown and can be used for this resource set (hosts in another pool aren't shown). This way, you can be sure to have resources free for tasks other than self-service.
-
-:::tip
-Don't forget to add an ISO SR to allow your users to install VMs with CD if necessary
-:::
-
-##### Quotas
-
-Then, you can define quotas on this set:
-
-- max vCPUs
-- max RAM
-- max disk usage
-
-:::tip
-Replicated VMs and snapshots created by a backup job don't use quotas.
-:::
-
-:::tip
-A snapshot of a Self Service VM will use as much resources as a VM would. You can disable this by setting `ignoreVmSnapshotResources` to `true` in the `selfService` section of `xo-server`'s config.
-:::
-
-When you click on create, you can see the resource set and remove or edit it:
-
-<UiDetail src="/img/xo5/self-service-set-quotas.png" alt="The saved resource set recap, with its quota gauges for CPUs, RAM and disk usage" width={700} />
-
-### Usage (user side)
-
-As soon as a user is granted a resource set, it displays a new button in their main view: "new".
-
-<UiDetail src="/img/xo5/self-service-new-vm-button.png" alt="The New button displayed in the user's main menu" width={160} />
-
-Now, the user can create a VM with only the resources granted in the set:
-
-<UiShot light="/img/xo5/self-service-vm-creation.png" alt="The VM creation page restricted to the sandbox resource set: only the delegated template, SR and network are selectable" url="https://your-xo/v5/#/vms/new" />
-
-And the recap before creation:
-
-<UiDetail src="/img/xo5/self-service-quota-summary.png" alt="The summary gauges showing how much of the set's quota the new VM will consume" width={700} />
-
-If the "Create" button is disabled, it means the user requested more resources than available.
-
-Finally, if a user has been granted access to multiple resource sets, they can be switched in the top right of the screen.
-
-### Toward the Cloud
-
-Self-service is a major step in the Cloud. Combine it with our [Cloudinit compatible VM creation](../manage-your-infrastructure/vm-templates.md#cloud-init) for a full experience:
-
-- create a Cloud ready template
-- create a set and put Cloud templates inside
-- delegate this set to a group of users
-
-Now, your authorized users can create VMs with their SSH keys, grow template disks if needed, etc. Everything is inside a "sandbox" (the resource set) you defined earlier!
-
-## Audit log
-
-XO Audit Log is a plugin that records all important actions performed by users and provides the administrators an overview of each action. This gives them an idea of the users behavior regarding their infrastructure in order to track suspicious activities.
-
-### How does it work?
-
-XO Audit Log listens to important actions performed by users and stores them in the XOA database using the [hash chain structure](https://en.wikipedia.org/wiki/Hash_chain).
-
-### Trustability of the records
-
-Stored records are secured by:
-
-- structure: records are chained using the hash chain structure which means that each record is linked to its parent in a cryptographically secure way. This structure prevents the alteration of old records.
-
-- hash upload: the hash chain structure has limits, it does not protect from the rewrite of recent/all records. To reduce this risk, the Audit log plugin regularly uploads the last record hash to our database after checking the integrity of the whole record chain. This functionality keeps the records safe by notifying users in case of alteration of the records.
-
-### Configuration
-
-The recording of the users' actions is disabled by default. To enable it:
-
-1. go into `settings/plugins`
-2. expand the `audit` configuration
-3. toggle active and save the configuration
-
-<UiDetail src="/img/xo5/audit-log-plugin-config.png" alt="The audit plugin configuration, with the active toggle enabled" width={620} />
-
-Now, the audit plugin will record users' actions and upload the last record in the chain every day at **06:00 AM (UTC)**.
-
-## Debugging
-
-If you can't log in, please [check the logs of `xo-server`](../getting-started/troubleshooting.md#logs).

docs/docs/security/user-management/rbac.md

@@ -1,13 +1,14 @@
 ---
-sidebar_label: RBAC
+sidebar_label: RBAC (XO 6 only)
+sidebar_position: 3
 ---
 
 # RBAC: Role-Based Access Control
 
-RBAC is the access control system for the Xen Orchestra [REST API](automation/restapi.md) and the XO 6 interface. It lets you define exactly what each user or group can see and do, down to individual objects, without granting them full administrator access.
+RBAC is the access control system for the Xen Orchestra [REST API](../../automation/restapi.md) and the XO 6 interface. It lets you define exactly what each user or group can see and do, down to individual objects, without granting them full administrator access.
 
 :::note Where RBAC applies, and why it was once called "ACL v2"
-RBAC covers the **[REST API](automation/restapi.md)** and **XO 6**. The JSON-RPC API behind the XO 5 interface keeps the original [ACL system](./users.md#acls), and those ACLs are not available on the REST API.
+RBAC covers the **[REST API](../../automation/restapi.md)** and **XO 6**. The JSON-RPC API behind the XO 5 interface keeps the original [ACL system](./users.md#acls), and those ACLs are not available on the REST API.
 
 You may still come across this feature under the name **ACL v2**. That was only a working name while it was being built. It is a full rewrite of the original ACLs into a much broader model, so it is now called by what it actually is: RBAC. Same feature, current name.
 :::
@@ -54,7 +55,7 @@ A privilege defines:
 - **resource**: the type of object (e.g. `vm`, `backup-job`, `sr`)
 - **action**: what operation is allowed or denied (e.g. `read`, `start`, `delete`)
 - **effect**: whether the privilege grants (`allow`) or blocks (`deny`) the action
-- **selector** _(optional)_: a filter expression to restrict the privilege to a subset of objects ([complex-matcher format](../manage-your-infrastructure/manage_infrastructure.md#filter-syntax))
+- **selector** _(optional)_: a filter expression to restrict the privilege to a subset of objects ([complex-matcher format](../../manage-your-infrastructure/manage_infrastructure.md#filter-syntax))
 
 ### Action hierarchy
 
@@ -135,7 +136,7 @@ Some endpoints are always accessible to a logged-in user **without any ACL privi
 
 `me` is a convenience alias: it is automatically redirected to `/rest/v0/users/{your-id}`.
 
-This is how delegation works end to end: any user, whatever their privileges, can create their own [authentication token](automation/restapi.md#authentication) and use it to call the REST API within the limits of their roles.
+This is how delegation works end to end: any user, whatever their privileges, can create their own [authentication token](../../automation/restapi.md#authentication) and use it to call the REST API within the limits of their roles.
 
 :::tip
 The Swagger UI available at `/rest/v0/swagger` documents every endpoint with its required privileges. Endpoints with no declared privilege are admin-only.
@@ -305,7 +306,7 @@ Everything shown in the walkthrough (and more) is available as plain REST calls,
 | `GET` / `POST /acl-privileges`                 | List privileges / create a privilege inside a role             |
 | `GET` / `PATCH` / `DELETE /acl-privileges/:id` | Read, update or delete a privilege                             |
 
-In the XO 6 interface, the **Administration** section of the sidebar covers users and groups; role and privilege management itself currently happens through the REST API, as shown above. See [Users and administration](../manage-your-infrastructure/management.md#users-and-administration).
+In the XO 6 interface, the **Administration** section of the sidebar covers users and groups; role and privilege management itself currently happens through the REST API, as shown above. See [Users and administration](../../manage-your-infrastructure/management.md#users-and-administration).
 
 <UiShot light="/img/xo6/administration-light.png" dark="/img/xo6/administration-dark.png" alt="The Administration section in XO 6, where users and groups are managed" url="https://your-xo/v6/#/admin/user-management/users" />
 
@@ -313,7 +314,7 @@ In the XO 6 interface, the **Administration** section of the sidebar covers user
 
 ## Selectors
 
-By default, a privilege applies to **all** objects of the given resource type. The optional `selector` field narrows it down using the [complex-matcher](../manage-your-infrastructure/manage_infrastructure.md#filter-syntax) syntax, the same filter syntax used in the XO UI.
+By default, a privilege applies to **all** objects of the given resource type. The optional `selector` field narrows it down using the [complex-matcher](../../manage-your-infrastructure/manage_infrastructure.md#filter-syntax) syntax, the same filter syntax used in the XO UI.
 
 A selector is evaluated against each object's properties. If it matches, the privilege applies; otherwise it does not.
 

docs/docs/security/user-management/users.md

@@ -0,0 +1,227 @@
+---
+sidebar_position: 2
+---
+
+# Users
+
+<InterfaceNote>This page describes user management in the XO 5 interface. XO 6 currently lists users (with their groups and tokens); creating and editing them still happens here.</InterfaceNote>
+
+Xen Orchestra involves three distinct notions of "user account". Make sure you are looking at the right one:
+
+- **XOA system accounts**: the Linux accounts (`xoa`, `root`) of the appliance itself, used for SSH and console access. See [First login](../../getting-started/installation/xoa.md#first-login).
+- **XO application users**: the accounts inside the Xen Orchestra web application. This is what this page is about.
+- **XO 6 / REST API roles**: XO 6 introduces a new RBAC model with roles and fine-grained privileges. See the [RBAC page](./rbac.md).
+
+There are 2 types of XO users:
+
+- **admins**, with all rights on all connected resources
+- **users**, with no rights by default
+
+:::note
+Local user accounts should be avoided in production environments. LDAP authentication is strongly recommended for centralized credential management.
+:::
+
+## Authentication
+
+Users can log in with a built-in account, or through an external authentication provider: LDAP, OpenID Connect, SAML, GitHub or Google. See [Authentication providers](authentication-providers.md) to set them up, including two-factor authentication for built-in accounts.
+
+## ACLs (XO 5 only) {#acls}
+
+### Definition
+
+ACLs are permissions that apply to preexisting objects, like users and groups.
+
+:::note
+This section describes the original ACLs, used by the XO 5 interface. The REST API and XO 6 use a broader model: see [RBAC](./rbac.md).
+:::
+
+### Who can manage ACLs?
+
+Only a super admin (XO administrator) can manage ACLs.
+
+### How can I view and edit ACLs?
+
+The ACLs view can be accessed in the **Settings** panel.
+
+1. Select the user or group you want to apply permissions on
+2. Select the object on which the permission will apply
+3. Choose the role for this ACL
+4. Click the **Create** button.
+
+<UiDetail src="/img/xo5/acl-creation.png" alt="The ACL creation form: subject, object and role selectors followed by the Create button" width={700} />
+
+:::tip
+You can click to add multiple objects at the same time!
+:::
+
+Your ACL is now available in the right list:
+
+<UiDetail src="/img/xo5/acl-list.png" alt="The list of existing ACLs, each row showing the user, the object and the assigned role" width={620} />
+
+You can edit or remove existing ACLs here.
+
+### Roles
+
+There are 3 different roles for your users:
+
+- Admin
+- Operator
+- Viewer
+
+#### Admin
+
+An object admin can do everything on it, even destroy it. E.g with its admin VM:
+
+- remove it
+- migrate it (to a host with admin permission on it)
+- modify the VM resources, name and description
+- clone it
+- copy it
+- convert it into a template
+- snapshot it (even revert from a snapshot)
+- export it
+- attach/add visible disks
+- same for network cards
+
+#### Operator
+
+An operator can make everyday operations on assigned objects. For example, on a VM:
+
+- eject a CD
+- insert a CD (if he can view the ISO storage repository)
+- start, restart, shutdown, suspend/resume it
+
+All other operations are forbidden.
+
+#### Viewer
+
+A viewer can only see the VM state and its metrics. That's all!
+
+### Inheritance
+
+Objects have a hierarchy: a Pool contains all its hosts, containing itself all its VMs.
+
+If you give a _view_ permission to a user (or a group) on a pool, he will automatically see all the objects inside this pool (SRs, hosts, VMs).
+
+### Examples
+
+#### Allow a user to install an OS
+
+If the OS install needs an ISO, you need to give this user 2 permissions:
+
+- _Operate_ on the VM (e.g to start it)
+- _View_ on the ISO Storage containing the needed ISO.
+
+## Self-service portal
+
+The self-service feature allows users to create new VMs. This is different from delegating existing resources (VMs) to them, and it leads to a lot of possibilities.
+
+### Set of resources
+
+To create a new set of resources to delegate, go to the "Self Service" section in the main menu:
+
+<UiDetail src="/img/xo5/self-service-menu.png" alt="The Self Service entry in the XO main menu" width={180} />
+
+#### Create a set
+
+:::tip
+Only an admin can create a set of resources
+:::
+
+To allow people to create VMs as they want, we need to give them a _part_ of your XCP-ng/XenServer resources (disk space, CPUs, RAM). You can call this "general quotas" if you like. But you first need to decide which resources will be used.
+
+In this example below, we'll create a set called **"sandbox"** with:
+
+- "devs" is the group that can use this set (all users in the group)
+- "Lab Pool" is the pool where they can play
+- "Debian 8 Cloud Ready" is the only template they can use
+- "SSD NFS" is the only SR where they can create VMs
+- "Pool-wide network with eth0" is the only available network for them
+
+<UiDetail src="/img/xo5/self-service-set-creation.png" alt="The resource set creation form: name, subjects, pools, templates, SRs, networks and limits, with the eligible hosts below" width={700} />
+
+As you can see, only compatible hosts are shown and can be used for this resource set (hosts in another pool aren't shown). This way, you can be sure to have resources free for tasks other than self-service.
+
+:::tip
+Don't forget to add an ISO SR to allow your users to install VMs with CD if necessary
+:::
+
+##### Quotas
+
+Then, you can define quotas on this set:
+
+- max vCPUs
+- max RAM
+- max disk usage
+
+:::tip
+Replicated VMs and snapshots created by a backup job don't use quotas.
+:::
+
+:::tip
+A snapshot of a Self Service VM will use as much resources as a VM would. You can disable this by setting `ignoreVmSnapshotResources` to `true` in the `selfService` section of `xo-server`'s config.
+:::
+
+When you click on create, you can see the resource set and remove or edit it:
+
+<UiDetail src="/img/xo5/self-service-set-quotas.png" alt="The saved resource set recap, with its quota gauges for CPUs, RAM and disk usage" width={700} />
+
+### Usage (user side)
+
+As soon as a user is granted a resource set, it displays a new button in their main view: "new".
+
+<UiDetail src="/img/xo5/self-service-new-vm-button.png" alt="The New button displayed in the user's main menu" width={160} />
+
+Now, the user can create a VM with only the resources granted in the set:
+
+<UiShot light="/img/xo5/self-service-vm-creation.png" alt="The VM creation page restricted to the sandbox resource set: only the delegated template, SR and network are selectable" url="https://your-xo/v5/#/vms/new" />
+
+And the recap before creation:
+
+<UiDetail src="/img/xo5/self-service-quota-summary.png" alt="The summary gauges showing how much of the set's quota the new VM will consume" width={700} />
+
+If the "Create" button is disabled, it means the user requested more resources than available.
+
+Finally, if a user has been granted access to multiple resource sets, they can be switched in the top right of the screen.
+
+### Toward the Cloud
+
+Self-service is a major step in the Cloud. Combine it with our [Cloudinit compatible VM creation](../../manage-your-infrastructure/infrastructure/vm-templates.md#cloud-init) for a full experience:
+
+- create a Cloud ready template
+- create a set and put Cloud templates inside
+- delegate this set to a group of users
+
+Now, your authorized users can create VMs with their SSH keys, grow template disks if needed, etc. Everything is inside a "sandbox" (the resource set) you defined earlier!
+
+## Audit log
+
+XO Audit Log is a plugin that records all important actions performed by users and provides the administrators an overview of each action. This gives them an idea of the users behavior regarding their infrastructure in order to track suspicious activities.
+
+### How does it work?
+
+XO Audit Log listens to important actions performed by users and stores them in the XOA database using the [hash chain structure](https://en.wikipedia.org/wiki/Hash_chain).
+
+### Trustability of the records
+
+Stored records are secured by:
+
+- structure: records are chained using the hash chain structure which means that each record is linked to its parent in a cryptographically secure way. This structure prevents the alteration of old records.
+
+- hash upload: the hash chain structure has limits, it does not protect from the rewrite of recent/all records. To reduce this risk, the Audit log plugin regularly uploads the last record hash to our database after checking the integrity of the whole record chain. This functionality keeps the records safe by notifying users in case of alteration of the records.
+
+### Configuration {#configuration-1}
+
+The recording of the users' actions is disabled by default. To enable it:
+
+1. go into `settings/plugins`
+2. expand the `audit` configuration
+3. toggle active and save the configuration
+
+<UiDetail src="/img/xo5/audit-log-plugin-config.png" alt="The audit plugin configuration, with the active toggle enabled" width={620} />
+
+Now, the audit plugin will record users' actions and upload the last record in the chain every day at **06:00 AM (UTC)**.
+
+## Debugging
+
+If you can't log in, please [check the logs of `xo-server`](../../support-and-reference/troubleshooting.md#logs).

docs/docs/support-and-licencing/_category_.json

@@ -1,8 +0,0 @@
-{
-    "label": "Support and licencing",
-    "position": 8,
-    "link": {
-      "type": "generated-index",
-      "description": "Support plans, licensing options, and subscription details"
-    }
-  }

docs/docs/support-and-reference/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Support & reference",
+  "position": 12,
+  "link": {
+    "type": "generated-index",
+    "slug": "/category/support-and-reference",
+    "description": "Support, troubleshooting, community and reference material"
+  }
+}

docs/docs/support-and-reference/community.md

@@ -1,9 +1,13 @@
+---
+sidebar_position: 3
+---
+
 # Community support
 
 We do our best to assist users running Xen Orchestra from the sources on [our community forum](https://xcp-ng.org/forum/category/12/xen-orchestra) (you can also chat with the community on [Discord](https://discord.gg/Hr98F6wRvx)). However there's no guarantee you will receive a solution (from us or the community), nor any guarantee on a timeframe. Usually we are responsive, but keep in mind that if you need production level support, you should consider subscribing to our [XOA offers](https://vates.tech/pricing-and-support/).
 
 :::warning
-If you installed your XO from a 3rd party script (any method outside [our official documentation](../getting-started/install-from-sources.md)), please report your issue **first** on the 3rd party script repository. We can't waste time debugging 3rd party installers that very often lag behind our own deployment methods and fall out of date.
+If you installed your XO from a 3rd party script (any method outside [our official documentation](../getting-started/installation/install-from-sources.md)), please report your issue **first** on the 3rd party script repository. We can't waste time debugging 3rd party installers that very often lag behind our own deployment methods and fall out of date.
 :::
 
 ## Current version
@@ -24,14 +28,14 @@ Before reporting a bug, please check that your **current version is up-to-date w
 
 If you have issues with XO installed from the sources (via GitHub), please **always** first:
 
-1. update your XO to the latest `master` commit (see how-to in the [dedicated section](../getting-started/install-from-sources.md#updating)) and retest again
-2. if the issue persists, double check you have all the requirements checked from the [installation section](../getting-started/install-from-sources.md) and test again
-3. then, if you still experience problems, [remove and rebuild from scratch](../getting-started/install-from-sources.md#troubleshooting)
+1. update your XO to the latest `master` commit (see how-to in the [dedicated section](../getting-started/installation/install-from-sources.md#updating)) and retest again
+2. if the issue persists, double check you have all the requirements checked from the [installation section](../getting-started/installation/install-from-sources.md) and test again
+3. then, if you still experience problems, [remove and rebuild from scratch](../getting-started/installation/install-from-sources.md#troubleshooting)
 
 Only after that, you can go to the [dedicated forum](https://xcp-ng.org/forum/category/12/xen-orchestra) to ask about your problem.
 
 :::tip
-If you want a consistent and tested solution for using Xen Orchestra, we strongly advise using our preconfigured and validated [Xen Orchestra Virtual Appliance](../getting-started/installation.md#xoa).
+If you want a consistent and tested solution for using Xen Orchestra, we strongly advise using our preconfigured and validated [Xen Orchestra Virtual Appliance](../getting-started/installation/xoa.md#xoa).
 :::
 
 ## Feature requests

docs/docs/support-and-reference/glossary.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 5
+---
+
 # Glossary
 
 ## General
@@ -47,7 +51,7 @@
 | **NFS**           | Network File System                      | File-based **SR** backed by an NFS export.                                                                                       |
 | **QCOW2**         | QEMU Copy On Write v2                    | Disk format lifting the 2 TiB **VHD** limit (up to 16 TiB per disk), generally available since XO 6.5 and recent XCP-ng releases. |
 | **SR-IOV**        | Single Root I/O Virtualization           | Passing a virtual function of a physical NIC to a **VM** for near-native I/O.                                                    |
-| **Traffic rules** |                                          | Firewall-like rules applied to networks and **VIFs** through the [SDN controller](../manage-your-infrastructure/sdn_controller.md).                        |
+| **Traffic rules** |                                          | Firewall-like rules applied to networks and **VIFs** through the [SDN controller](../manage-your-infrastructure/networking/sdn_controller.md).                        |
 | **VHD**           | Virtual Hard Disk                        | Historical disk and backup format of the platform, limited to 2 TiB per disk (see **QCOW2**).                                    |
 | **VLAN**          | Virtual LAN                              | Logical LAN segment; often tied to **PIF** tagging in XAPI.                                                                      |
 | **XVA**           | XenServer Virtual Appliance              | Archive format for a complete VM export, used by [full backups](../backups-and-dr/backup-types/full_backups.md).                                            |
@@ -66,8 +70,8 @@
 | **BR**                     | Backup Repository              | Storage where XO writes backups (NFS, SMB, S3, local...), formerly called a "remote". See [backup repositories](../backups-and-dr/backup-features-and-settings.md#remotes).            |
 | **CBT**                    | Changed Block Tracking         | XCP-ng/XenServer feature letting XO [purge snapshot data](../backups-and-dr/backup-types/incremental_backups.md#purge-snapshot-data-cbt): the reference snapshot keeps only small metadata on the **SR**. |
 | **Coalesce**               |                                | The storage process merging a VDI chain after a snapshot is deleted. Backups create and delete snapshots, so [coalesce health](../backups-and-dr/backup_troubleshooting.md) directly affects them. |
-| **CR**                     | Incremental replication        | Regularly replays deltas of a VM to an **SR** on another pool or host, formerly "continuous replication". See [incremental replication](../backups-and-dr/backup-types/incremental_replication.md). |
-| **DR**                     | Full replication               | Regularly streams a full copy of a VM to an **SR** on another pool or host, formerly "disaster recovery". See [full replication](../backups-and-dr/backup-types/full_replication.md). |
+| **CR**                     | Incremental replication        | Regularly replays deltas of a VM to an **SR** on another pool or host, formerly "continuous replication". See [incremental replication](../replication/incremental_replication.md). |
+| **DR**                     | Full replication               | Regularly streams a full copy of a VM to an **SR** on another pool or host, formerly "disaster recovery". See [full replication](../replication/full_replication.md). |
 | **Full backup interval**   |                                | Also called [key backup interval](../backups-and-dr/backup-types/incremental_backups.md#key-backup-interval): forces a periodic new full (key) backup in an incremental backup job. |
 | **GFS**                    | Grandfather-Father-Son         | [Long-term retention strategy](../backups-and-dr/backup-features-and-settings.md#long-term-backup-retention-with-gfs-strategy) keeping daily, weekly, monthly and yearly backups.       |
 | **Health check**           |                                | Automatic [restore test](../backups-and-dr/backup-features-and-settings.md#backup-health-check) after a backup: XO boots the restored VM to verify the backup is actually usable.       |
@@ -83,11 +87,11 @@
 | Term                | Meaning                 | Definition                                                                                                                                        |
 | ------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **Guest tools**     |                         | Drivers and agent [installed inside a VM](https://xcp-ng.org/docs/guests.html): they report the IP address and metrics, and enable clean shutdown and migration. |
-| **V2V**             | Virtual to Virtual      | Built-in [migration tool](../guides/v2v-migration-guide.md) importing VMs directly from VMware/ESXi to XCP-ng.                                          |
+| **V2V**             | Virtual to Virtual      | Built-in [migration tool](../migrate-from-vmware/v2v-migration-guide.md) importing VMs directly from VMware/ESXi to XCP-ng.                                          |
 | **XAPI** / **xapi** | Xen API                 | The management API and service on each **host** that **XO** talks to.                                                                             |
-| **XCP-ng**          |                         | The open source, Xen-based hypervisor [managed by XO](../getting-started/supported_hosts.md), developed by Vates alongside Xen Orchestra.                            |
+| **XCP-ng**          |                         | The open source, Xen-based hypervisor [managed by XO](../getting-started/requirements.md#host-compatibility-list), developed by Vates alongside Xen Orchestra.                            |
 | **XO**              | Xen Orchestra           | The management UI/API stack (`xo-server`, `xo-web`, etc.).                                                                                        |
-| **XO 5** / **XO 6** |                         | The two web interfaces served by the same XO backend: XO 6 is the current default, XO 5 the previous generation. See [XO 6 vs XO 5](../discover-xen-orchestra/xo6vsxo5.md). |
+| **XO 5** / **XO 6** |                         | The two web interfaces served by the same XO backend: XO 6 is the current default, XO 5 the previous generation. See [XO 6 vs XO 5](../whats-new/xo6vsxo5.md). |
 | **XO Lite**         |                         | [Lightweight web UI](https://docs.vates.tech/products/add-ons/xo-lite) embedded in every XCP-ng host (8.3+): basic management and XOA deployment, no installation needed. |
 | **XO Proxy**        |                         | [Component deployed close to remote infrastructure](../backups-and-dr/scale-and-security/proxy.md) to run backups locally, without streaming all data through the main XOA.        |
 | **XOA**             | Xen Orchestra Appliance | Prebuilt VM image that runs **XO** as a packaged appliance.                                                                                       |

docs/docs/support-and-reference/intro_support.md

@@ -1,11 +1,12 @@
 ---
 slug: support
+sidebar_position: 1
 ---
 
 # Support
 
 :::tip
-To run a self-diagnosis or open a secure support tunnel from your XOA, see [Troubleshooting](../getting-started/troubleshooting.md#still-stuck).
+To run a self-diagnosis or open a secure support tunnel from your XOA, see [Troubleshooting](troubleshooting.md#still-stuck).
 :::
 
 Xen Orchestra runs in a controlled and tested environment thanks to XOA (the [Xen Orchestra virtual Appliance](https://vates.tech/deploy/)). **This is the only way to get pro support**. Any account with a registered XOA can open tickets from its personal space on [account.vates.tech](https://account.vates.tech).

docs/docs/support-and-reference/troubleshooting.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 8
+sidebar_position: 2
 ---
 
 # Troubleshooting
@@ -7,7 +7,7 @@ sidebar_position: 8
 This page covers the problems you may encounter with your XOA, and how to get out of them.
 
 :::warning
-If you have issues with an XO installed [from the sources](install-from-sources.md), please go through the [community support checklist](../support-and-licencing/community.md) first.
+If you have issues with an XO installed [from the sources](../getting-started/installation/install-from-sources.md), please go through the [community support checklist](community.md) first.
 :::
 
 ## First reflex: `xoa check`
@@ -61,7 +61,7 @@ Restart the VM, then log in over SSH with the `xoa` user and that password.
 
 ### Recover the web login password
 
-From the XOA CLI (see [first console connection](installation.md#first-console-connection)):
+From the XOA CLI (see [first console connection](../getting-started/installation/xoa.md#first-console-connection)):
 
 <Terminal shell title="xoa — reset a web account password">{`
 sudo xo-server-recover-account youremail@here.com
@@ -71,7 +71,7 @@ It prompts for a new password. If the email does not exist in XO yet, an admin a
 
 ### Empty page after login
 
-Your antivirus or firewall is blocking WebSockets, the protocol XO clients use to talk to `xo-server` (see [architecture](architecture.md)). Switch to **HTTPS**: WebSockets are then encapsulated in TLS, out of reach of the interception.
+Your antivirus or firewall is blocking WebSockets, the protocol XO clients use to talk to `xo-server` (see [architecture](../core-concepts/architecture.md)). Switch to **HTTPS**: WebSockets are then encapsulated in TLS, out of reach of the interception.
 
 ### User login failures
 
@@ -107,7 +107,7 @@ Reduce the static max memory of the XOA VM to a lower value and migrate again.
 
 ### xo-server out of memory
 
-If `xo-server` crashes with `FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory` in its logs, give the XOA VM more memory (see [Sizing your XOA](installation.md#sizing)) and restart it.
+If `xo-server` crashes with `FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory` in its logs, give the XOA VM more memory (see [Sizing your XOA](../getting-started/requirements.md#sizing)) and restart it.
 
 Since Xen Orchestra 6.8, `xo-server` sets its Node.js memory limit to 70% of the VM's RAM (1 GiB minimum), recalculated at each start: no manual setting is needed. If you previously added `--max-old-space-size` to `/etc/systemd/system/xo-server.service` by hand, you can remove it: the automatic limit makes it unnecessary.
 
@@ -126,7 +126,7 @@ If ghost tasks accumulate, try in order:
 
 ## Network issues
 
-Check the current configuration with `ip addr` (the default interface is `enX0` or `eth0`), and make sure any external firewall allows the XOA IP. Reconfigure with `xoa network static` or `xoa network dhcp`, as described in [Network configuration](installation.md#network-configuration).
+Check the current configuration with `ip addr` (the default interface is `enX0` or `eth0`), and make sure any external firewall allows the XOA IP. Reconfigure with `xoa network static` or `xoa network dhcp`, as described in [Network configuration](../getting-started/installation/xoa.md#network-configuration).
 
 ## Updater issues
 

docs/docs/support-and-reference/useful-links.md

@@ -1,3 +1,7 @@
+---
+sidebar_position: 4
+---
+
 # Bundles and licences
 
 The following resources are available in the Vates VMS documentation:

docs/docs/users-and-access/_category_.json

@@ -1,8 +0,0 @@
-{
-    "label": "Users and access",
-    "position": 6,
-    "link": {
-      "type": "generated-index",
-      "description": "Detailed information on how to manage users, groups and access rights"
-    }
-  }

docs/docs/whats-new/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "What's new",
+  "position": 2,
+  "link": {
+    "type": "doc",
+    "id": "whats-new/whatsnew"
+  }
+}

docs/docs/whats-new/whatsnew.md

@@ -0,0 +1,24 @@
+---
+sidebar_label: What's new
+sidebar_position: 1
+---
+
+# What's new in XO 6
+
+XO 6 is a complete redesign of the Xen Orchestra interface, built as a modern web application on a dedicated design system. It is not a reskin of XO 5: the navigation, the information architecture and the visual language were rebuilt from scratch around how infrastructures are actually operated.
+
+<UiShot dark="/img/xo6/lab-dashboard.webp" alt="XO 6: one dashboard for every pool, host and VM you manage" url="https://myxoa.domain.tld/v6/#/dashboard" />
+
+## An interface that grows release by release
+
+XO 6 reached its first official release with a deliberately focused scope, and new capabilities are added continuously: more actions on objects, user management, backup features and more. The [XO 6 and XO 5](xo6vsxo5.md) page presents the highlights of XO 6 and tracks what lives where today, and the best way to see what is new is simply to keep your Xen Orchestra up to date.
+
+To explore the interface, start with [How XO is organized](../core-concepts/coreconcepts/coreconcepts.md).
+
+## Follow the evolution of XO
+
+Xen Orchestra evolves with every release. Three resources tell you where it comes from, where it stands and where it is going:
+
+- **The present and the past**: the [Xen Orchestra blog](https://xen-orchestra.com/blog/) presents the latest release and its main features, along with the presentations of the previous releases.
+- **Every change in detail**: the [changelog](https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.md) complements the blog by listing every change, release by release.
+- **The future**: the [product roadmap](https://docs.vates.tech/product-roadmap/) shows what is planned for the upcoming releases.

docs/docs/whats-new/xo6vsxo5.md

@@ -9,6 +9,19 @@ XO 6 and XO 5 are two interfaces to the same Xen Orchestra. They run side by sid
 - **XO 6** is the default interface and the future of Xen Orchestra.
 - **XO 5** remains fully available for everything XO 6 does not cover yet: use the **XO 5** link in the top-right corner, or the marked links that XO 6 shows contextually (they open the right XO 5 page for the object you are on).
 
+## XO 6 highlights
+
+Compared to XO 5, XO 6 brings:
+
+- **A tree view of your whole infrastructure**: every pool, host and VM in one always-visible, searchable tree. No more jumping between list pages to find an object.
+- **Dashboards at every level**: Xen Orchestra, pool, host and VM each open on a dashboard that summarizes status, alarms, patches, resources and backup health at that scale.
+- **Consistent pages**: every object follows the same tab pattern, every table has the same query builder and details side panel. Learn one page, know them all.
+- **First-class consoles**: VM and host consoles in the browser, with fullscreen, a chrome-less dedicated tab mode and Ctrl+Alt+Del.
+- **Make it yours**: light and dark color modes, five interface themes, and 21 languages.
+- **Task visibility**: a Tasks tab at every level records operations, API calls and authentications with their outcomes.
+- **Backup awareness everywhere**: protection status is visible from the global dashboard down to each VM, including the VMs that no job protects.
+- **Side-by-side with XO 5**: both interfaces run on the same Xen Orchestra and the same data. Anything not yet in XO 6 is one clearly marked click away.
+
 ## What lives where today
 
 XO 6 is under active development, so this table evolves with every release. As a rule of thumb: observing and operating your infrastructure day to day happens in XO 6; deep configuration still happens in XO 5.
@@ -36,4 +49,4 @@ One more current limitation to know: XO 6 requires an administrator account. Non
 
 Start every session in XO 6: navigation, monitoring, consoles, task forensics and backup oversight are simply better there. When you hit an operation XO 6 does not do yet, it will either show you the action marked with an external-link icon, or you switch to XO 5 manually and come right back.
 
-If you prefer to keep XO 5 as your default interface for now, the welcome message of XO 6 links to the procedure to do so.
+If you prefer to keep XO 5 as your default interface for now, the welcome message of XO 6 links to [the procedure to do so](../getting-started/installation/xoa.md#change-the-default-interface).

docs/docusaurus.config.ts

@@ -43,8 +43,8 @@ export default {
             from: '/administration',
           },
           {
-            to: '/users-and-access/rbac',
-            from: ['/xo6/acl-v2', '/rbac'],
+            to: '/security/user-management/rbac',
+            from: ['/xo6/acl-v2', '/rbac', '/users-and-access/rbac'],
           },
           {
             to: '/manage-your-infrastructure/advanced',
@@ -55,15 +55,15 @@ export default {
             from: '/alerts',
           },
           {
-            to: '/users-and-access/users#acls',
+            to: '/security/user-management/users#acls',
             from: '/acls',
           },
           {
-            to: '/getting-started/architecture',
-            from: ['/xo5/architecture', '/architecture'],
+            to: '/core-concepts/architecture',
+            from: ['/xo5/architecture', '/architecture', '/getting-started/architecture'],
           },
           {
-            to: '/getting-started/architecture#plugins',
+            to: '/manage-your-infrastructure/plugins',
             from: '/plugins',
           },
           {
@@ -91,24 +91,24 @@ export default {
             from: '/xo6/backups',
           },
           {
-            to: '/support-and-licencing/community',
-            from: ['/xo6/community', '/community'],
+            to: '/support-and-reference/community',
+            from: ['/xo6/community', '/community', '/support-and-licencing/community'],
           },
           {
             to: '/getting-started/configuration',
             from: ['/xo5/configuration', '/configuration'],
           },
           {
-            to: '/users-and-access/credential-encryption',
-            from: ['/xo5/credential-encryption', '/credential-encryption'],
+            to: '/security/credential-encryption',
+            from: ['/xo5/credential-encryption', '/credential-encryption', '/users-and-access/credential-encryption'],
           },
           {
             to: '/backups-and-dr/backup-types/full_backups',
             from: ['/xo5/full_backups', '/full_backups'],
           },
           {
-            to: '/backups-and-dr/backup-types/full_replication',
-            from: ['/xo5/full_replication', '/full_replication'],
+            to: '/replication/full_replication',
+            from: ['/xo5/full_replication', '/full_replication', '/backups-and-dr/backup-types/full_replication'],
           },
           {
             to: '/backups-and-dr/scale-and-security/immutability',
@@ -119,8 +119,8 @@ export default {
             from: ['/incremental_backups', '/xo5/incremental_backups'],
           },
           {
-            to: '/backups-and-dr/backup-types/incremental_replication',
-            from: ['/incremental_replication', '/xo5/incremental_replication'],
+            to: '/replication/incremental_replication',
+            from: ['/incremental_replication', '/xo5/incremental_replication', '/backups-and-dr/backup-types/incremental_replication'],
           },
           {
             to: '/getting-started/installation',
@@ -135,8 +135,8 @@ export default {
             from: '/xo5/backup',
           },
           {
-            to: '/support-and-licencing/support',
-            from: ['/license_management', '/xo5/license_management', '/xo6/support', '/support'],
+            to: '/support-and-reference/support',
+            from: ['/license_management', '/xo5/license_management', '/xo6/support', '/support', '/support-and-licencing/support'],
           },
           {
             to: '/manage-your-infrastructure/load_balancing',
@@ -155,8 +155,9 @@ export default {
             from: ['/metadata_backup', '/xo5/metadata_backup'],
           },
           {
-            to: '/getting-started/migrate_to_new_xoa',
-            from: '/migrate_to_new_xoa',
+            // The procedure now lives in the Vates knowledge base.
+            to: 'https://docs.vates.tech/kb/vkb-1031/',
+            from: ['/migrate_to_new_xoa', '/getting-started/migrate_to_new_xoa'],
           },
           {
             to: '/backups-and-dr/backup-types/mirror_backup',
@@ -171,7 +172,7 @@ export default {
             from: ['/proxy', '/xo5/proxy'],
           },
           {
-            to: '/support-and-licencing/support#licensing',
+            to: '/support-and-reference/support#licensing',
             from: ['/purchase', '/xo6/purchase'],
           },
           {
@@ -211,52 +212,55 @@ export default {
             from: ['/xo5/rolling_snapshots', '/rolling_snapshots'],
           },
           {
-            to: '/manage-your-infrastructure/sdn_controller',
-            from: ['/sdn_controller', '/xo5/sdn_controller'],
+            to: '/manage-your-infrastructure/networking/sdn_controller',
+            from: ['/sdn_controller', '/xo5/sdn_controller', '/manage-your-infrastructure/sdn_controller'],
           },
           {
-            to: '/getting-started/supported_hosts',
-            from: '/supported_hosts',
+            to: '/getting-started/requirements#host-compatibility-list',
+            from: ['/supported_hosts', '/getting-started/supported_hosts'],
           },
           {
-            to: '/getting-started/troubleshooting',
-            from: ['/general-troubleshooting', '/xo5/troubleshooting', '/troubleshooting'],
+            to: '/support-and-reference/troubleshooting',
+            from: ['/general-troubleshooting', '/xo5/troubleshooting', '/troubleshooting', '/getting-started/troubleshooting'],
           },
           {
             to: '/getting-started/updater',
             from: '/updater',
           },
           {
-            to: '/users-and-access/users',
-            from: ['/users', '/xo5/users'],
+            to: '/security/user-management/users',
+            from: ['/users', '/xo5/users', '/users-and-access/users'],
           },
           {
-            to: '/guides/v2v-migration-guide',
-            from: ['/v2v-migration-guide', '/xo5/v2v-migration-guide'],
+            to: '/migrate-from-vmware/v2v-migration-guide',
+            from: ['/v2v-migration-guide', '/xo5/v2v-migration-guide', '/guides/v2v-migration-guide'],
           },
           {
-            to: '/guides/windows-templates',
-            from: '/windows-templates',
+            to: '/manage-your-infrastructure/infrastructure/windows-templates',
+            from: ['/windows-templates', '/guides/windows-templates'],
           },
           {
-            to: '/manage-your-infrastructure/vm-templates',
-            from: ['/vm-templates', '/xo5/vm-templates'],
+            to: '/manage-your-infrastructure/infrastructure/vm-templates',
+            from: ['/vm-templates', '/xo5/vm-templates', '/manage-your-infrastructure/vm-templates'],
           },
           {
-            to: '/discover-xen-orchestra/whatsnew',
-            from: '/xo6/whatsnew',
+            to: '/whats-new/whatsnew',
+            from: ['/xo6/whatsnew', '/discover-xen-orchestra/whatsnew'],
           },
           {
-            to: '/discover-xen-orchestra/xo6vsxo5',
-            from: '/xo6/xo6vsxo5',
+            to: '/whats-new/xo6vsxo5',
+            from: ['/xo6/xo6vsxo5', '/discover-xen-orchestra/xo6vsxo5'],
           },
           {
-            to: '/discover-xen-orchestra/gettingstarted',
-            from: '/xo6/gettingstarted',
+            // "First steps" (/getting-started/gettingstarted) is a draft, hidden
+            // in production: send its URLs to the closest published page until
+            // it is published again, then point them back to it.
+            to: '/core-concepts/coreconcepts',
+            from: ['/xo6/gettingstarted', '/discover-xen-orchestra/gettingstarted', '/getting-started/gettingstarted'],
           },
           {
-            to: '/discover-xen-orchestra/coreconcepts',
-            from: '/xo6/coreconcepts',
+            to: '/core-concepts/coreconcepts',
+            from: ['/xo6/coreconcepts', '/discover-xen-orchestra/coreconcepts'],
           },
           {
             to: '/manage-your-infrastructure/management',
@@ -286,13 +290,38 @@ export default {
             to: '/project/contributing',
             from: '/contributing',
           },
+          {
+            // Its links (blog, changelog, roadmap) now live on the What's new page.
+            to: '/whats-new/whatsnew',
+            from: '/project/project-resources',
+          },
           {
             to: '/project/licenses',
             from: '/licenses',
           },
           {
-            to: '/project/glossary',
-            from: '/glossary',
+            to: '/support-and-reference/glossary',
+            from: ['/glossary', '/project/glossary'],
+          },
+          {
+            to: '/support-and-reference/useful-links',
+            from: '/support-and-licencing/useful-links',
+          },
+          {
+            to: '/whats-new/whatsnew',
+            from: '/category/discover-xen-orchestra',
+          },
+          {
+            to: '/category/migrate-from-vmware',
+            from: '/category/guides',
+          },
+          {
+            to: '/category/security',
+            from: '/category/users-and-access',
+          },
+          {
+            to: '/category/support-and-reference',
+            from: '/category/support-and-licencing',
           },
         ],
       },
@@ -393,7 +422,7 @@ export default {
             },
             {
               label: 'Installation',
-              href: '/getting-started/installation',
+              href: '/getting-started/install',
             },
           ],
         },

docs/src/clientModules/movedAnchors.ts

@@ -27,14 +27,77 @@ const MOVED_TO_SOURCES = new Set([
  */
 const MOVED_FROM_XOA: Record<string, string> = {
   firewall: '/getting-started/configuration#firewall',
-  timezone: '/configuration#timezone',
-  'setting-a-custom-ntp-server': '/configuration#setting-a-custom-ntp-server',
-  'restart-the-service': '/configuration#restart-the-service',
-  'technical-support': '/getting-started/troubleshooting#still-stuck',
-  'xoa-check': '/troubleshooting#first-reflex-xoa-check',
-  'support-tunnel': '/troubleshooting#support-tunnel',
-  'ssh-pro-support': '/troubleshooting#support-tunnel',
-  'migrate-from-an-older-xoa': '/getting-started/migrate_to_new_xoa',
+  timezone: '/getting-started/configuration#timezone',
+  'setting-a-custom-ntp-server': '/getting-started/configuration#setting-a-custom-ntp-server',
+  'restart-the-service': '/getting-started/configuration#restart-the-service',
+  'technical-support': '/support-and-reference/troubleshooting#still-stuck',
+  'xoa-check': '/support-and-reference/troubleshooting#first-reflex-xoa-check',
+  'support-tunnel': '/support-and-reference/troubleshooting#support-tunnel',
+  'ssh-pro-support': '/support-and-reference/troubleshooting#support-tunnel',
+  'migrate-from-an-older-xoa': 'https://docs.vates.tech/kb/vkb-1031/',
+}
+
+/**
+ * Sections that moved to another page, keyed by the page they left.
+ * Redirects from older URLs of these pages keep the hash, so this also
+ * covers them.
+ */
+const MOVED_SECTIONS: Record<string, Record<string, string>> = {
+  '/getting-started/installation': {
+    'xoa-vm-specifications': '/getting-started/requirements#xoa-vm-specifications',
+    sizing: '/getting-started/requirements#sizing',
+    'from-the-sources': '/getting-started/install-from-sources',
+  },
+  '/getting-started/configuration': {
+    'using-xo-5-as-the-default-interface': '/getting-started/installation#change-the-default-interface',
+    'temporary-switch-to-xo-5': '/getting-started/installation#temporary-switch-to-xo-5',
+    'making-xo-5-the-default-ui': '/getting-started/installation#making-xo-5-the-default-ui',
+    'apply-the-changes': '/getting-started/installation#apply-the-changes',
+  },
+  '/whats-new/whatsnew': {
+    highlights: '/whats-new/xo6vsxo5#xo-6-highlights',
+  },
+  // The authentication section moved to its own page, with the same anchors.
+  '/security/user-management/users': Object.fromEntries(
+    [
+      'built-in',
+      'otp-authentication-2fa',
+      'enabling-totp',
+      'disabling-totp',
+      'ldap',
+      'common-ldap-filters',
+      'group-synchronization',
+      'troubleshooting',
+      'openid-connect',
+      'overview',
+      'prerequisites',
+      'user-workflow',
+      'log-in-with-openid-connect',
+      'administrator-guide',
+      'set-up-the-openid-connect-plugin',
+      'required-configuration',
+      'advanced-configuration-optional',
+      'save-and-activate-the-plugin',
+      'enabling-passkeys-in-xoa-with-keycloak',
+      'generating-certificates',
+      'trust-the-keycloak-cert-in-xoa',
+      'configuring-keycloak',
+      'sample',
+      'saml',
+      'configuration',
+      'vendor-specific',
+      'google-workspace---saml-supportgooglecom',
+      'github',
+      'google',
+      'creating-the-google-project',
+      'configure-the-xo-plugin',
+    ].map(anchor => [anchor, `/security/user-management/authentication-providers#${anchor}`])
+  ),
+  '/core-concepts/coreconcepts': {
+    'dashboards-at-every-level': '/core-concepts/coreconcepts/dashboards',
+    'tabs-tables-and-the-side-panel': '/core-concepts/coreconcepts/tabs-tables-side-panel',
+    'tasks-everything-is-tracked': '/core-concepts/coreconcepts/tasks',
+  },
 }
 
 /**
@@ -60,12 +123,16 @@ export function onRouteDidUpdate({ location }: { location: { pathname: string; h
   const path = location.pathname.replace(/\/+$/, '')
   const anchor = location.hash.replace(/^#/, '')
   if (path === '/getting-started/installation' && MOVED_TO_SOURCES.has(anchor)) {
-    window.location.replace(`/install-from-sources#${anchor}`)
+    window.location.replace(`/getting-started/install-from-sources#${anchor}`)
   }
   if (path === '/getting-started/installation' && MOVED_FROM_XOA[anchor] !== undefined) {
     window.location.replace(MOVED_FROM_XOA[anchor])
   }
-  if (path === '/support-and-licencing/support' && MOVED_TO_VATES_DOCS[anchor] !== undefined) {
+  if (path === '/support-and-reference/support' && MOVED_TO_VATES_DOCS[anchor] !== undefined) {
     window.location.replace(MOVED_TO_VATES_DOCS[anchor])
   }
+  const movedSection = MOVED_SECTIONS[path]?.[anchor]
+  if (movedSection !== undefined) {
+    window.location.replace(movedSection)
+  }
 }

docs/src/components/InterfaceNote/index.tsx

@@ -19,7 +19,7 @@ export default function InterfaceNote({ children }: { children?: React.ReactNode
             <strong>XO 5</strong> link in the top-right corner of XO 6.
           </>
         )}{' '}
-        <Link to='/discover-xen-orchestra/xo6vsxo5'>See what lives where</Link>.
+        <Link to='/whats-new/xo6vsxo5'>See what lives where</Link>.
       </div>
     </div>
   )

packages/xo-server-audit/.USAGE.md

@@ -1,2 +1,2 @@
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/getting-started/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).

packages/xo-server-audit/README.md

@@ -7,7 +7,7 @@
 ## Usage
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 ## Contributions
 

packages/xo-server-auth-github/.USAGE.md

@@ -8,6 +8,6 @@ same identifier.
 > for more information about the configuration.
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/getting-started/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 ![Registering XO instance in GitHub](github.png)

packages/xo-server-auth-github/README.md

@@ -16,7 +16,7 @@ same identifier.
 > for more information about the configuration.
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 ![Registering XO instance in GitHub](github.png)
 

packages/xo-server-auth-google/.USAGE.md

@@ -26,4 +26,4 @@ Add OAuth 2.0 credentials:
 ### Add the plugin to XO-Server config
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/getting-started/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).

packages/xo-server-auth-google/README.md

@@ -34,7 +34,7 @@ Add OAuth 2.0 credentials:
 ### Add the plugin to XO-Server config
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 ## Contributions
 

packages/xo-server-auth-ldap/.USAGE.md

@@ -4,7 +4,7 @@ The first time a user signs in, XO will create a new XO user with the
 same identifier.
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/getting-started/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 ## User email uniqueness
 

packages/xo-server-auth-ldap/README.md

@@ -12,7 +12,7 @@ The first time a user signs in, XO will create a new XO user with the
 same identifier.
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 ## User email uniqueness
 

packages/xo-server-auth-oidc/.USAGE.md

@@ -4,7 +4,7 @@ The first time a user signs in, XO will create a new XO user with the
 same identifier.
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/getting-started/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 > Important: When registering your instance to your identity provider,
 > you must configure its callback URL to

packages/xo-server-auth-oidc/README.md

@@ -12,7 +12,7 @@ The first time a user signs in, XO will create a new XO user with the
 same identifier.
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 > Important: When registering your instance to your identity provider,
 > you must configure its callback URL to

packages/xo-server-auth-saml/.USAGE.md

@@ -8,7 +8,7 @@ same identifier.
 > for more information about the configuration.
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/getting-started/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 > Important: When registering your instance to your identity provider,
 > you must configure its callback URL to

packages/xo-server-auth-saml/README.md

@@ -16,7 +16,7 @@ same identifier.
 > for more information about the configuration.
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 > Important: When registering your instance to your identity provider,
 > you must configure its callback URL to

packages/xo-server-transport-email/.USAGE.md

@@ -1,2 +1,2 @@
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/getting-started/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).

packages/xo-server-transport-email/README.md

@@ -7,7 +7,7 @@
 ## Usage
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 ## Contributions
 

packages/xo-server-transport-icinga2/.USAGE.md

@@ -1,5 +1,5 @@
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/getting-started/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 ### `Xo#sendIcinga2Status({ status, message })`
 

packages/xo-server-transport-icinga2/README.md

@@ -7,7 +7,7 @@
 ## Usage
 
 Like all other xo-server plugins, it can be configured directly via
-the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/architecture#plugins).
+the web interface, see [the plugin documentation](https://docs.xen-orchestra.com/manage-your-infrastructure/plugins).
 
 ### `Xo#sendIcinga2Status({ status, message })`