Administrator/Xen-Orchestra-xen-orchestra-MIRROR
1
0
Fork 1
mirror of https://github.com/vatesfr/xen-orchestra.git synced 2026-09-10 22:14:48 -05:00
Code Issues Packages Projects Releases Wiki Activity

doc(xo): sidebar refactor (#10354)

Browse Source 
We now generate the sidebar automatically (based on the documentation folder structure and _category.json files), instead of declaring the doc structure manually in sidebars.ts.
Simpler management

This makes the sidebar easier to understand and maintain. It is now managed the exact same way as the sidebars for the Vates VMS and XCP-ng documentations.
Clickable breadcrumbs

The autogenerated sidebar also creates category index pages, which makes breadcrumb categories clickable, as they already are in the Vates VMS and XCP-ng documentations.
Preview
Capture d'écran 2026-09-08 094848
Unlisted pages

Pages that should remain accessible but be hidden from the sidebar are now hidden using the unlisted: true metadata, instead of simply being omitted from sidebars.ts.
Internal links and redirection

Finally, the PR updates internal links and redirects to reflect the new folder structure and URLs.
This commit is contained in:
Thomas Moraine
2026-09-08 11:40:01 +02:00
committed by GitHub
parent e58587aa1d
commit f99d7ab761
69 changed files with 325 additions and 400 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/docs/airgap.md
View File

@@ -1,3 +1,7 @@
---
unlisted: true
---
# Airgap support and deployment
:::tip
@@ -15,11 +19,11 @@ In this scenario, you will need a QA/pre-production XCP-ng pool with Internet ac
### Deployment
[Follow the standard procedure](./installation.md) to deploy the XOA on your pool with Internet access.
[Follow the standard procedure](./getting-started/installation.md) to deploy the XOA on your pool with Internet access.
Make sure that your appliance is [properly registered](./installation.md#registration) and [up-to-date](./updater.md).
Make sure that your appliance is [properly registered](./getting-started/installation.md#registration) and [up-to-date](./getting-started/updater.md).
It's also good to take a quick look at [the XOA check](./troubleshooting.md#first-reflex-xoa-check) to detect issues early.
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.
When everything is good, you can shutdown your XOA and export it:
@@ -50,7 +54,7 @@ To upgrade your XOA, you need to:
1. shutdown the XOA on your airgapped pool
2. export it to an XVA file
3. move it to your connected pool and import it
4. start it, run the [upgrade process](./updater.md)
4. start it, run the [upgrade process](./getting-started/updater.md)
5. shutdown this XOA
6. export it to an XVA file
7. move it to your airgapped pool and import it

8
docs/docs/automation/_category_.json Normal file
View File

@@ -0,0 +1,8 @@
{
"label": "Automation",
"position": 8,
"link": {
"type": "generated-index",
"description": "Various tools to automate your workflow in XO"
}
}

2
docs/docs/automation/kubernetes.md
View File

@@ -2,7 +2,7 @@
## Introduction
Xen Orchestra includes a Kubernetes cluster [recipe](../xo5/advanced.md#recipes) that provides a simple way to deploy an official Kubernetes distribution called **MicroK8s** (maintained by Canonical).
Xen Orchestra includes a Kubernetes cluster [recipe](../manage-your-infrastructure/advanced.md#recipes) that provides a simple way to deploy an official Kubernetes distribution called **MicroK8s** (maintained by Canonical).
:::tip
One of the key benefits of MicroK8s is its automatic security updates. For example, patch releases (like 1.30.x to 1.30.x+1) are applied automatically. This saves Kubernetes admins a lot of time and effort.

2
docs/docs/automation/mcp.md
View File

@@ -222,7 +222,7 @@ Because the tool surface is generated from the live OpenAPI spec, it always refl
The server exposes:
- **Three utility tools**, always present: `check_connection` (validate your setup), `get_infrastructure_summary` (aggregate pools, hosts and VMs into a single overview), and `search_documentation` (look up the XO documentation by topic).
- **One `{domain}_query` tool per REST resource domain**, generated from the live spec: pools, hosts, VMs, storage (SRs, VDIs), network, backup jobs and logs, users, tasks, alarms, and more. All query tools share the same arguments: `operation` (the OpenAPI `operationId` to invoke), `id`, an optional [`filter` expression](../xo5/manage_infrastructure.md#live-filter-search), `fields`, and `limit`.
- **One `{domain}_query` tool per REST resource domain**, generated from the live spec: pools, hosts, VMs, storage (SRs, VDIs), network, backup jobs and logs, users, tasks, alarms, and more. All query tools share the same arguments: `operation` (the OpenAPI `operationId` to invoke), `id`, an optional [`filter` expression](../manage-your-infrastructure/manage_infrastructure.md#live-filter-search), `fields`, and `limit`.
- **A built-in prompt**, `infrastructure-overview`, which turns the infrastructure summary into a readable report.
Stats endpoints and binary downloads (`.xva`, `.vhd`, ...) are deliberately not exposed: their payloads are unsuitable for LLM context. Use the REST API directly when you need them.

6
docs/docs/automation/restapi.md
View File

@@ -1,6 +1,6 @@
# 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](../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](../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.
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.
@@ -18,7 +18,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](../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](../users-and-access/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.
@@ -64,7 +64,7 @@ If you don't know your user ID, use the `me` alias, as above. Tokens expire (see
Every object type lives in a collection at `/rest/v0/<name>` (e.g. `/rest/v0/vms`, `/rest/v0/hosts`, `/rest/v0/srs`). A plain `GET` returns the objects' URLs, and the following query parameters shape the result:
- `fields`: return objects containing the requested fields, instead of plain URLs
- `filter`: select only matching objects, using [the live filter search syntax](../xo5/manage_infrastructure.md#live-filter-search)
- `filter`: select only matching objects, using [the live filter search syntax](../manage-your-infrastructure/manage_infrastructure.md#live-filter-search)
- `limit`: maximum number of objects returned
- `ndjson`: if `true`, the result is streamed in [NDJSON format](https://github.com/ndjson/ndjson-spec), one object per line

8
docs/docs/backups-and-dr/_category_.json Normal file
View File

@@ -0,0 +1,8 @@
{
"label": "Backups and DR",
"position": 5,
"link": {
"type": "generated-index",
"description": "Detailed information on backups and disaster recovery"
}
}

10
docs/docs/xo5/backups.md → docs/docs/backups-and-dr/backup-features-and-settings.md
View File

@@ -13,8 +13,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](../full_replication.md) | Disaster Recovery (DR) |
| [Incremental replication](incremental_replication.md) | Continuous Replication (CR) |
| [Full replication](./backup-types/full_replication.md) | Disaster Recovery (DR) |
| [Incremental replication](./backup-types/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.
:::
@@ -321,7 +321,7 @@ Supported backup repository types:
- The initial "/" or "\\" is automatically added.
- For disks larger than **2 TiB**, store backups on **block-based backup repositories**. Since QCOW2 reached general availability in XCP-ng, a single disk can grow up to **16 TiB**, so this matters more than ever.
- For **qcow2** disks, enable [NBD](./incremental_backups.md#nbd-enabled-backups) for incremental backups: without it, each run falls back to a full backup.
- For **qcow2** disks, enable [NBD](./backup-types/incremental_backups.md#nbd-enabled-backups) for incremental backups: without it, each run falls back to a full backup.
:::
@@ -370,7 +370,7 @@ Xen Orchestra supports Amazon S3 storage and other S3-compatible providers, so y
:::warning
- Not all S3-compatible providers adhere perfectly to Amazon S3 standards. Check the [supported object storage providers](../object-storage-support.md) list and its support tiers, and test your setup before trusting it with critical backups.
- Not all S3-compatible providers adhere perfectly to Amazon S3 standards. Check the [supported object storage providers](./scale-and-security/object-storage-support.md) list and its support tiers, and test your setup before trusting it with critical backups.
- Losing your encryption key means your backups will be permanently inaccessible. If you enable encryption, make sure your key is stored securely, and outside of the backed up infrastructure, as there's no way to recover your data without it.
:::
@@ -468,7 +468,7 @@ You can also restore specific files and directories inside a VM. It works with a
:::warning
- File level restore **is only possible on incremental backups**. Also, due to some technical limitations, you won't be able to do file level restore if you have a chain longer than 99 (ie retention longer than 99 records without any full between). Take a look at the [key backup interval section](./incremental_backups.md#key-backup-interval) to set this correctly.
- File level restore **is only possible on incremental backups**. Also, due to some technical limitations, you won't be able to do file level restore if you have a chain longer than 99 (ie retention longer than 99 records without any full between). Take a look at the [key backup interval section](./backup-types/incremental_backups.md#key-backup-interval) to set this correctly.
- File level restore **is only possible on a single VDI**, it does not support LVM Volume Groups that span multiple VDIs.
- The following Microsoft solutions are **not supported**:
- [Data Deduplication](https://learn.microsoft.com/en-us/windows-server/storage/data-deduplication/overview)

8
docs/docs/backups-and-dr/backup-types/_category_.json Normal file
View File

@@ -0,0 +1,8 @@
{
"label": "Backup types",
"position": 1,
"link": {
"type": "generated-index",
"description": "All the different backup types"
}
}

2
docs/docs/full_backups.md → docs/docs/backups-and-dr/backup-types/full_backups.md
View File

@@ -73,5 +73,5 @@ With offline backup enabled, the VM is shut down for the whole duration of the e
:::
:::tip
Full backups are storage and bandwidth hungry: each run transfers and stores a complete copy of the VM, with no deduplication between runs. In exchange, you get the simplest possible restore. To use less space and transfer less data, look at [incremental backups](xo5/incremental_backups.md), and see the [backup strategy guide](./backup_howto.md) to choose the right approach for your infrastructure.
Full backups are storage and bandwidth hungry: each run transfers and stores a complete copy of the VM, with no deduplication between runs. In exchange, you get the simplest possible restore. To use less space and transfer less data, look at [incremental backups](./incremental_backups.md), and see the [backup strategy guide](../backup_howto.md) to choose the right approach for your infrastructure.
:::

2
docs/docs/full_replication.md → docs/docs/backups-and-dr/backup-types/full_replication.md
View File

@@ -97,4 +97,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](xo5/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](../backup_howto.md).

4
docs/docs/xo5/incremental_backups.md → docs/docs/backups-and-dr/backup-types/incremental_backups.md
View File

@@ -51,7 +51,7 @@ You can, for example, run the initial key backup during a weekend, then only del
- they are small and quick to create
- restores are simple: XO reads the whole chain and rebuilds the VM automatically
If you want to roll back a VM to a previous state, the cost is only one snapshot on your SR (far less than the [rolling snapshot](../rolling_snapshots.md) mechanism). And even if you lose your whole SR or VM, XOA will restore the VM entirely and automatically, at any backup date.
If you want to roll back a VM to a previous state, the cost is only one snapshot on your SR (far less than the [rolling snapshot](./rolling_snapshots.md) mechanism). And even if you lose your whole SR or VM, XOA will restore the VM entirely and automatically, at any backup date.
You can even use this to back up more often: deltas stay small, and they will **always be deltas**.
@@ -201,6 +201,6 @@ Sometimes, you might notice that incremental backups are surprisingly large, alm
- Look out for cron jobs, log rotations, or background tasks that might be active during backup times.
- Ensure your VM has enough memory to prevent excessive paging.
- Create a separated disk with `[NOBAK]` in its name to handle temporary files. This disk won't be transferred.
To know more on excluding disks from backup jobs, check out the [Exclude disks](./backups.md#exclude-disks) section.
To know more on excluding disks from backup jobs, check out the [Exclude disks](../backup-features-and-settings.md#exclude-disks) section.
- For disks larger than **2 TB**, store backups on a backup repository in **block mode**.
- For **qcow2** disks, [enable NBD](#nbd-enabled-backups): without it, each incremental run falls back to a full backup.

0
docs/docs/xo5/incremental_replication.md → docs/docs/backups-and-dr/backup-types/incremental_replication.md
View File

0
docs/docs/xo5/metadata_backup.md → docs/docs/backups-and-dr/backup-types/metadata_backup.md
View File

2
docs/docs/mirror_backup.md → docs/docs/backups-and-dr/backup-types/mirror_backup.md
View File

@@ -173,7 +173,7 @@ I, J and K are transferred in order, and B, C and D are deleted from the destina
## Synchronizing algorithm for incremental backups
This job only transfers new backups, then runs the same merge algorithm as [Incremental Backups](xo5/incremental_backups.md) on the destination. Since each side applies its own retention, the merges happen independently: the source merges sooner (retention 3), the destination later (retention 4).
This job only transfers new backups, then runs the same merge algorithm as [Incremental Backups](./incremental_backups.md) on the destination. Since each side applies its own retention, the merges happen independently: the source merges sooner (retention 3), the destination later (retention 4).
<Schema label="Three runs of an incremental mirror: only the new deltas cross the wire, and each BR merges its own chain when its own retention is exceeded, the source after run 1, the destination one run later" legend={[["#e0a94a", "key (full) backup"], ["#6aabf0", "delta"], ["#5ac8c8", "transfer"]]} maxWidth="640px">
<svg viewBox="0 0 640 266" role="img" aria-label="Three rows show successive mirror runs of an incremental chain. Run 1: the source holds key A plus deltas b and c, all three are transferred, the destination holds A, b and c. Run 2: the source has merged A and b into key B and holds B, c and d, only the delta d is transferred, the destination holds A, b, c and d with no merge yet. Run 3: the source holds C, d and e, only the delta e is transferred, and the destination now merges A and b into B, holding B, c, d and e">

4
docs/docs/rolling_snapshots.md → docs/docs/backups-and-dr/backup-types/rolling_snapshots.md
View File

@@ -80,11 +80,11 @@ To roll back, open the VM's **Snapshots** tab and revert to the restore point yo
On thick-provisioned storage (LVM-based SRs: iSCSI, HBA, local LVM), every snapshot reserves the full virtual size of the disk on the SR. Seven rolling snapshots of a 200 GiB disk can claim more than 1.4 TiB. Avoid rolling snapshots for large VMs on these SRs, or keep the retention very low. Thin-provisioned storage (local ext, NFS, XOSTOR) only consumes space for the actual changes.
:::
- **Coalesce load**: deleting a snapshot triggers coalesce work on the SR to merge the disk chain back together. If snapshots rotate faster than the SR can coalesce (very frequent schedules on slow storage), chains pile up and Xen Orchestra will skip the VM to protect it. See [VDI chain protection](xo5/backup_troubleshooting.md#vdi-chain-protection) for details.
- **Coalesce load**: deleting a snapshot triggers coalesce work on the SR to merge the disk chain back together. If snapshots rotate faster than the SR can coalesce (very frequent schedules on slow storage), chains pile up and Xen Orchestra will skip the VM to protect it. See [VDI chain protection](..//backup_troubleshooting.md#vdi-chain-protection) for details.
- **Reverting is destructive**: rolling a VM back to a snapshot discards everything that happened after that snapshot was taken. If you are not sure you want to lose the current state, snapshot it first, then revert.
## When to use it
Rolling snapshots shine as a cheap, fast undo button: before risky changes, on dev and test VMs, or as a short-term rollback layer on top of a proper backup policy. They cost nothing to set up, need no backup repository, and restore in seconds.
They are not a protection layer: they will not survive the loss of the SR, a corrupted storage, or a host disaster. Once your rolling snapshots are in place, head over to the [Backup strategy guide](backup_howto.md) to design real protection, with [incremental backups](xo5/incremental_backups.md) as the natural next step: they reuse the same snapshot mechanism, but export the data to a separate backup repository where a storage failure can't reach it.
They are not a protection layer: they will not survive the loss of the SR, a corrupted storage, or a host disaster. Once your rolling snapshots are in place, head over to the [Backup strategy guide](../backup_howto.md) to design real protection, with [incremental backups](./incremental_backups.md) as the natural next step: they reuse the same snapshot mechanism, but export the data to a separate backup repository where a storage failure can't reach it.

42
docs/docs/backup_howto.md → docs/docs/backups-and-dr/backup_howto.md
View File

@@ -9,22 +9,22 @@ Instead of a simple list of questions and answers, it walks you through **key de
This part explains the terminology of backup types and features.
- [**Backup sequence**](xo5/backups.md#sequences): A feature that allows you to chain multiple backup jobs to run one after the other, automatically.
- [**Backup repository (BR)**](xo5/backups.md#remotes): Formerly called _Remote_. A storage location for backups. For instance:
- [**Backup sequence**](./backup-features-and-settings.md#sequences): A feature that allows you to chain multiple backup jobs to run one after the other, automatically.
- [**Backup repository (BR)**](./backup-features-and-settings.md#remotes): Formerly called _Remote_. A storage location for backups. For instance:
- Local storage (not recommended)
- NFS
- SMB
- Amazon S3 and compatible
- Microsoft Azure
- Azurite
- [**File restore**](xo5/backups.md#restore-a-file): A feature that allows you to restore individual files from a VM backup without restoring the full VM.
- [**Full backup**](full_backups.md): Copies the entire VM to backup repositories each time, regardless of previous backups.
- [**Full 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**](xo5/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**](xo5/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**](xo5/backups.md#long-term-backup-retention-with-gfs-strategy): Keeps backups over extended periods (weeks, months, or years) for compliance or archival purposes.
- [**Mirror backup**](mirror_backup.md): Mirror a backup repository to another. Retention and encryption of source and destination can be different.
- [**Distributed backup and replication**](distributed_backups.md): Distribute the backups and replications across multiple targets.
- [**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.
- [**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.
- [**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.
## What should I do before setting up my backup?
@@ -66,13 +66,13 @@ Here is the whole toolbox at a glance. Most infrastructures combine several of t
| Type | What you get | Storage & network cost | Restore | Typical use |
| ---------------------------------------------------------- | ------------------------------------------- | --------------------------- | -------------------------------- | -------------------------------------- |
| [Rolling snapshots](rolling_snapshots.md) | Instant restore points, on the same storage | SR space only | Instant revert | Oops protection, before risky changes |
| [Full backup](full_backups.md) | Complete standalone archive on a BR | High, every run | Simple, anywhere | Small fleets, simplicity first |
| [Incremental backup](xo5/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)](full_replication.md) | Boot-ready copy on another host/SR | High, every run | Start the copy | DR with a modest RPO |
| [Incremental replication (CR)](xo5/incremental_replication.md) | Boot-ready copy, updated by deltas | Low per run | Clone and start | Low-RPO DR for critical VMs |
| [Mirror backup](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](xo5/metadata_backup.md) | XO config and pool metadata | Tiny | Rebuild your orchestration | Always: it protects the tool itself |
| [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 |
| [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 |
:::note The two replication modes have been renamed
**Full replication** used to be called **Disaster Recovery (DR)**, and **incremental replication** used to be called **Continuous Replication (CR)**. Only the names changed. The old ones are kept in parentheses here because you will still meet them: the XO 5 interface labels the two buttons **Disaster Recovery** and **Continuous Replication**, and XO tags replicas accordingly. XO 6 uses the current names.
@@ -98,8 +98,8 @@ A complete export of each VM to a backup repository, on every run.
After an initial full, only the changed blocks are exported.
- **Pros**: fast runs, small transfers, restore to any date, [file-level restore](xo5/backups.md#file-level-restore), works well at high frequency.
- **Watch out**: restores rely on a chain (full + deltas): set a [full backup interval](xo5/incremental_backups.md#key-backup-interval) to keep chains short, or enable health checks.
- **Pros**: fast runs, small transfers, restore to any date, [file-level restore](./backup-features-and-settings.md#file-level-restore), works well at high frequency.
- **Watch out**: restores rely on a chain (full + deltas): set a [full backup interval](./backup-types/incremental_backups.md#key-backup-interval) to keep chains short, or enable health checks.
- **First steps**: this is the right default for most VMs; start here if in doubt.
### Full replication (formerly Disaster Recovery, DR) {#full-replication-dr}
@@ -128,7 +128,7 @@ Replicates an existing backup repository to another one, possibly with different
### Sequence
Not a backup type, but the way to chain the jobs above: a [sequence](xo5/backups.md#sequences) runs several schedules one after the other, in a fixed order.
Not a backup type, but the way to chain the jobs above: a [sequence](./backup-features-and-settings.md#sequences) runs several schedules one after the other, in a fixed order.
- **Pros**: deterministic ordering (backup first, then replication), no overlapping jobs competing for resources.
- **First steps**: identify the right order, and test the sequence on non-critical VMs first.
@@ -179,7 +179,7 @@ For **advanced scenarios**, you can use the `fuse-vhd` helper script to manually
## Long-term retention strategy
For compliance or archival needs, you rarely want *every* daily backup kept for years: you want something like 7 dailies, 4 weeklies, 12 monthlies, a few yearlies. This is the **GFS (Grandfather-Father-Son)** scheme, configured directly in the retention settings of a backup job: see [Long-term backup retention with GFS](xo5/backups.md#long-term-backup-retention-with-gfs-strategy).
For compliance or archival needs, you rarely want *every* daily backup kept for years: you want something like 7 dailies, 4 weeklies, 12 monthlies, a few yearlies. This is the **GFS (Grandfather-Father-Son)** scheme, configured directly in the retention settings of a backup job: see [Long-term backup retention with GFS](./backup-features-and-settings.md#long-term-backup-retention-with-gfs-strategy).
- Define retention periods based on compliance and operational needs
- Size the required storage with the [retention calculator](calculator.md)

4
docs/docs/xo5/backup_reports.md → docs/docs/backups-and-dr/backup_reports.md
View File

@@ -127,7 +127,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](../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](../getting-started/architecture.md#plugins). 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
@@ -319,4 +319,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](./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#web-hooks) to configure it.

2
docs/docs/xo5/backup_troubleshooting.md → docs/docs/backups-and-dr/backup_troubleshooting.md
View File

@@ -16,7 +16,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_](incremental_backups#key-backup-interval) advanced setting has been reached for this VM
- the configured [_Full backup interval_](./backup-types/incremental_backups#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

4
docs/docs/xo6/backups.md → docs/docs/backups-and-dr/backups-in-xo6.md
View File

@@ -1,6 +1,6 @@
# 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](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](../discover-xen-orchestra/xo6vsxo5.md)).
## Backup health on the dashboard
@@ -32,4 +32,4 @@ The **Backups** tab of the VM lists the jobs covering that specific VM.
## Where the rest lives
Backup restore, job creation and editing, backup repositories (S3, NFS, SMB and Azure), mirror backups, sequences and health checks are managed in XO 5 for now, and are documented in the [XO 5 backup documentation](../xo5/backups.md). Everything you configure there is immediately reflected in the XO 6 views above.
Backup restore, job creation and editing, backup repositories (S3, NFS, SMB and Azure), mirror backups, sequences and health checks are managed in XO 5 for now, and are documented in the [XO 5 backup documentation](./backup-features-and-settings.md). Everything you configure there is immediately reflected in the XO 6 views above.

0
docs/docs/calculator.md → docs/docs/backups-and-dr/calculator.md
View File

47
docs/docs/backups-and-dr/intro_backup.md Normal file
View File

@@ -0,0 +1,47 @@
---
slug: backup
---
# Backup overview
Xen Orchestra ships a complete, **agentless** backup engine for your whole infrastructure: nothing to install inside your VMs, everything managed from one place, from quick rolling snapshots to cross-site disaster recovery.
New to backups in XO? Start with these two:
<CardGrid>
<LinkCard title="Backup strategy guide" href="/backups-and-dr/backup_howto">Which backup type for which need: design your protection plan before clicking anything.</LinkCard>
<LinkCard title="Backups in XO 6" href="/backups-and-dr/backups-in-xo6">Follow backup health from the new dashboards: job status, per-VM protection, restore points.</LinkCard>
</CardGrid>
## Pick your backup type
- **[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.
- **[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.
:::tip
You don't have to pick VMs one by one: **[smart backup](./backup-features-and-settings.md#smart-backup)** selects them dynamically by pool, tag or power state, so new VMs are protected automatically.
:::
## Going further
<CardGrid>
<LinkCard title="Features and settings" href="/backups-and-dr/backup-features-and-settings">Encryption, schedules, smart backup, backup repositories, restore (including file-level), retention, health checks: the full reference.</LinkCard>
<LinkCard title="Backup proxies" href="/backups-and-dr/scale-and-security/proxy">Offload backup traffic to proxies, closer to your pools and repositories.</LinkCard>
<LinkCard title="Distributed backups" href="/backups-and-dr/scale-and-security/distributed_backups">Combine proxies and mirrors for multi-site, resilient backup architectures.</LinkCard>
<LinkCard title="Immutability" href="/backups-and-dr/scale-and-security/immutability">Make your backup repositories tamper-proof against ransomware.</LinkCard>
<LinkCard title="Backup reports" href="/backups-and-dr/backup_reports">Get notified after each run: email, XMPP and more.</LinkCard>
<LinkCard title="Troubleshooting" href="/backups-and-dr/backup_troubleshooting">Interrupted runs, full SRs, slow transfers: the usual suspects and their fixes.</LinkCard>
</CardGrid>
:::tip
Sizing question? The [retention calculator](calculator.md) estimates how much storage a given schedule and retention will consume.
:::
## See it in action
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/FfUqIwT8KzI?si=kTvxIFhPjv-8Iwri" title="Administer and backup your VM infrastructure the easiest way" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

8
docs/docs/backups-and-dr/scale-and-security/_category_.json Normal file
View File

@@ -0,0 +1,8 @@
{
"label": "Scale and security",
"position": 2,
"link": {
"type": "generated-index",
"description": "Scalability, performance, and security for large-scale deployments"
}
}

2
docs/docs/distributed_backups.md → docs/docs/backups-and-dr/scale-and-security/distributed_backups.md
View File

@@ -103,6 +103,6 @@ When a health check is scheduled, it runs only against the target that holds the
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Cannot mix storage classes | A pool cannot combine limited-capacity targets (NFS, Local, SMB) with unlimited targets (S3, Azure Blob). Xen Orchestra will throw an error at the start of the backup run. |
| Minimum 2 targets required | The option is greyed out in the UI unless at least 2 BRs or SRs are selected. |
| Not usable as mirror source | A job with distributed backup enabled cannot be used as the source for a [Mirror Backup](./mirror_backup.md) job. |
| Not usable as mirror source | A job with distributed backup enabled cannot be used as the source for a [Mirror Backup](../backup-types/mirror_backup.md) job. |
| No duplication | Distributed mode and per-target duplication are mutually exclusive in the same job. Each VM backup lands on exactly one target. |
| No cross-target restore dependency | Each VM backup is self-contained on its target. Restoring from one target does not require any other target to be available. |

0
docs/docs/immutability.md → docs/docs/backups-and-dr/scale-and-security/immutability.md
View File

4
docs/docs/object-storage-support.md → docs/docs/backups-and-dr/scale-and-security/object-storage-support.md
View File

@@ -4,7 +4,7 @@
Xen Orchestra is compatible with a wide range of S3-compatible object storage solutions. Based on our testing and validation, we categorize storage providers into three tiers to help you understand their expected reliability and performance.
To configure an S3-compatible backup repository, see [Backup repositories](xo5/backups.md#remotes).
To configure an S3-compatible backup repository, see [Backup repositories](../backup-features-and-settings.md#amazon-s3).
## Storage tiers explained
@@ -29,7 +29,7 @@ To configure an S3-compatible backup repository, see [Backup repositories](xo5/b
## What this means for your backups
The most demanding part of the backup process (cleaning and merging old data) is where tier differences matter most. Once a backup is complete, restoration is fully supported by Vates regardless of the storage tier. You can inspect the health of a backup repository (BR) at any time with the [`xo-backups` CLI](xo5/backups.md#backups-cli).
The most demanding part of the backup process (cleaning and merging old data) is where tier differences matter most. Once a backup is complete, restoration is fully supported by Vates regardless of the storage tier. You can inspect the health of a backup repository (BR) at any time with the `xo-backups` [CLI](../backup-features-and-settings.md#backups-cli).
Currently, we don’t have a formal validation program for every provider. This list reflects our hands-on experience working with users to ensure their backups remain secure.

0
docs/docs/xo5/proxy.md → docs/docs/backups-and-dr/scale-and-security/proxy.md
View File

8
docs/docs/discover-xen-orchestra/_category_.json Normal file
View File

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

0
docs/docs/xo6/coreconcepts.md → docs/docs/discover-xen-orchestra/coreconcepts.md
View File

2
docs/docs/xo6/gettingstarted.md → docs/docs/discover-xen-orchestra/gettingstarted.md
View File

@@ -40,7 +40,7 @@ The **search field** filters the whole tree as you type, which is the fastest wa
<UiShot light="/img/xo6/treeview-search-light.png" dark="/img/xo6/treeview-search-dark.png" alt="Filtering the tree view" url="https://your-xo/v6/#/dashboard" />
Next to the tree view, the **Administration** tab of the sidebar gives access to user management (see [Users and administration](management.md#users-and-administration)).
Next to the tree view, the **Administration** tab of the sidebar gives access to user management (see [Users and administration](../manage-your-infrastructure/management.md#users-and-administration)).
## Your first tour

0
docs/docs/xo6/whatsnew.md → docs/docs/discover-xen-orchestra/whatsnew.md
View File

0
docs/docs/xo6/xo6vsxo5.md → docs/docs/discover-xen-orchestra/xo6vsxo5.md
View File

8
docs/docs/getting-started/_category_.json Normal file
View File

@@ -0,0 +1,8 @@
{
"label": "Getting started",
"position": 2,
"link": {
"type": "generated-index",
"description": "How to get XO up and running as fast as possible"
}
}

10
docs/docs/architecture.md → docs/docs/getting-started/architecture.md
View File

@@ -1,6 +1,6 @@
# Architecture
Xen Orchestra (XO) is built as **one server and several clients**: the two web interfaces ([XO 6](xo6/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](../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.
:::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.
@@ -95,7 +95,7 @@ The _Xen Orchestra Appliance_ (XOA) is a VM with the whole stack pre-installed,
- **Always on**: as a daemon, it listens to and records every event of your infrastructure, around the clock, whether a client is watching or not. That is what makes always-up-to-date views, scheduled backup jobs and task history possible.
- **Event driven**: `xo-server` subscribes to XAPI events instead of polling. Changes on a host or VM appear in your browser the moment they happen, and the server-side cache answers clients instantly, at any infrastructure size.
- **A single connection point**: clients connect to `xo-server`, never to your hosts. Legacy thick clients opened connections from every admin workstation to every server; here one daemon holds one connection per pool, and any number of clients share it.
- **A proxy for your hosts**: because everything flows through it, `xo-server` can expose VM consoles to clients that have no network access to the hosts, or stream a VM export from one pool straight into another (that is [warm migration](xo5/manage_infrastructure.md) territory) without a file stop in between.
- **A proxy for your hosts**: because everything flows through it, `xo-server` can expose VM consoles to clients that have no network access to the hosts, or stream a VM export from one pool straight into another (that is [warm migration](../manage-your-infrastructure/manage_infrastructure.md territory) without a file stop in between.
- **Pluggable**: features like LDAP authentication, load balancing, netbox synchronization or backup reports are [plugins](#plugins), not core patches.
### Events, not polling
@@ -168,12 +168,12 @@ 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](xo6/gettingstarted.md).
- **XO 5** (`xo-web`), the complete historical interface, built with React. See [the infrastructure management section](xo5/manage_infrastructure.md) for what you can do with it.
- **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 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](xo6/xo6vsxo5.md).
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).
## xo-cli

4
docs/docs/configuration.md → docs/docs/getting-started/configuration.md
View File

@@ -153,7 +153,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](xo5/sdn_controller.md#migration-path) for details.
See [SDN Controller: OpenFlow rules](../manage-your-infrastructure/sdn_controller.md#migration-path) for details.
## Custom certificate authority
@@ -295,7 +295,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](credential-encryption.md)
For more information about the encryption feature, see [credential database encryption](../users-and-access/credential-encryption.md)
## Proxy for updates and patches

2
docs/docs/install-from-sources.md → docs/docs/getting-started/install-from-sources.md
View File

@@ -215,7 +215,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](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-licencing/community.md): we would be happy to have more testers and maintainers for these targets.
:::
### FreeBSD

0
docs/docs/installation.md → docs/docs/getting-started/installation.md
View File

0
docs/docs/migrate_to_new_xoa.md → docs/docs/getting-started/migrate_to_new_xoa.md
View File

2
docs/docs/releases.md → docs/docs/getting-started/releases.md
View File

@@ -1,6 +1,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](xo6/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](../discover-xen-orchestra/xo6vsxo5.md)), the REST API and the backup engine.
## XOA, the appliance

0
docs/docs/supported_hosts.md → docs/docs/getting-started/supported_hosts.md
View File

4
docs/docs/troubleshooting.md → docs/docs/getting-started/troubleshooting.md
View File

@@ -3,7 +3,7 @@
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](community.md) first.
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.
:::
## First reflex: `xoa check`
@@ -204,7 +204,7 @@ You can then log in again with `admin@admin.net` / `admin`.
## Backup issues
Backups have their own page: [Backup troubleshooting](xo5/backup_troubleshooting.md).
Backups have their own page: [Backup troubleshooting](../backups-and-dr/backup_troubleshooting.md).
## Still stuck?

0
docs/docs/updater.md → docs/docs/getting-started/updater.md
View File

8
docs/docs/guides/_category_.json Normal file
View File

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

0
docs/docs/xo5/v2v-migration-guide.md → docs/docs/guides/v2v-migration-guide.md
View File

0
docs/docs/windows-templates.md → docs/docs/guides/windows-templates.md
View File

21
docs/docs/intro.md
View File

@@ -1,5 +1,6 @@
---
slug: /
sidebar_position: 1
---
# Xen Orchestra in a nutshell
@@ -157,21 +158,21 @@ the parked standby. */}
## Start here
<CardGrid>
<LinkCard title="Deploy Xen Orchestra" href="/installation">Get the turnkey appliance (XOA) running in minutes, or install from the sources.</LinkCard>
<LinkCard title="Discover XO 6" href="/xo6/gettingstarted">Tour the new interface: tree view, dashboards, consoles.</LinkCard>
<LinkCard title="Set up backups" href="/backup">Rolling snapshots, incremental backups, replication and more.</LinkCard>
<LinkCard title="Migrate from VMware" href="/xo5/v2v-migration-guide">Import your ESXi VMs directly into your pools with V2V.</LinkCard>
<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="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="Automate everything" href="/automation/restapi">REST API, CLI, Terraform, Ansible, Pulumi and more.</LinkCard>
<LinkCard title="Get support" href="/support">Professional support by the Vates team, or community help.</LinkCard>
<LinkCard title="Get support" href="/support-and-licencing/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](xo6/gettingstarted.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](xo6/backups.md).
- **Migration from VMware**: [V2V](xo5/v2v-migration-guide.md) imports your ESXi VMs directly into your pools.
- **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.
- **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.
- **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](rbac.md) to give each team exactly the access it needs.
- **Delegation**: users, groups and [RBAC](/users-and-access/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
@@ -190,4 +191,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](xo6/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](/discover-xen-orchestra/xo6vsxo5.md) to see what lives where.

47
docs/docs/intro_backup.md
View File

@@ -1,47 +0,0 @@
---
slug: backup
---
# Backup overview
Xen Orchestra ships a complete, **agentless** backup engine for your whole infrastructure: nothing to install inside your VMs, everything managed from one place, from quick rolling snapshots to cross-site disaster recovery.
New to backups in XO? Start with these two:
<CardGrid>
<LinkCard title="Backup strategy guide" href="/backup_howto">Which backup type for which need: design your protection plan before clicking anything.</LinkCard>
<LinkCard title="Backups in XO 6" href="/xo6/backups">Follow backup health from the new dashboards: job status, per-VM protection, restore points.</LinkCard>
</CardGrid>
## Pick your backup type
- **[Rolling snapshots](rolling_snapshots.md)**: scheduled snapshots kept on a rotation. No repository needed, instant restore points.
- **[Full backups](full_backups.md)**: a complete export of the VM to a backup repository (BR), every time. Simple and self-contained.
- **[Incremental backups](xo5/incremental_backups.md)**: after an initial full, only the changed blocks are sent. Fast, compact, deduplicable.
- **[Full 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](xo5/incremental_replication.md)** (formerly Continuous Replication, CR): the same standby copy, sending only the deltas.
- **[Mirror backups](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](xo5/metadata_backup.md)**: the XO configuration and pool metadata themselves, so the orchestrator is never your single point of failure.
:::tip
You don't have to pick VMs one by one: **[smart backup](xo5/backups.md#smart-backup)** selects them dynamically by pool, tag or power state, so new VMs are protected automatically.
:::
## Going further
<CardGrid>
<LinkCard title="Features and settings" href="/xo5/backups">Encryption, schedules, smart backup, backup repositories, restore (including file-level), retention, health checks: the full reference.</LinkCard>
<LinkCard title="Backup proxies" href="/xo5/proxy">Offload backup traffic to proxies, closer to your pools and repositories.</LinkCard>
<LinkCard title="Distributed backups" href="/distributed_backups">Combine proxies and mirrors for multi-site, resilient backup architectures.</LinkCard>
<LinkCard title="Immutability" href="/immutability">Make your backup repositories tamper-proof against ransomware.</LinkCard>
<LinkCard title="Backup reports" href="/xo5/backup_reports">Get notified after each run: email, XMPP and more.</LinkCard>
<LinkCard title="Troubleshooting" href="/xo5/backup_troubleshooting">Interrupted runs, full SRs, slow transfers: the usual suspects and their fixes.</LinkCard>
</CardGrid>
:::tip
Sizing question? The [retention calculator](calculator.md) estimates how much storage a given schedule and retention will consume.
:::
## See it in action
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/FfUqIwT8KzI?si=kTvxIFhPjv-8Iwri" title="Administer and backup your VM infrastructure the easiest way" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

8
docs/docs/manage-your-infrastructure/_category_.json Normal file
View File

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

0
docs/docs/xo5/advanced.md → docs/docs/manage-your-infrastructure/advanced.md
View File

0
docs/docs/xo5/ipmi-plugin.md → docs/docs/manage-your-infrastructure/ipmi-plugin.md
View File

2
docs/docs/xo5/load_balancing.md → docs/docs/manage-your-infrastructure/load_balancing.md
View File

@@ -14,7 +14,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](../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](../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.
:::tip
A load balancing policy is called a **plan**.

6
docs/docs/xo5/manage_infrastructure.md → docs/docs/manage-your-infrastructure/manage_infrastructure.md
View File

@@ -389,7 +389,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](../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](../getting-started/architecture.md#xo-cli).
### VM high availability (HA)
@@ -699,7 +699,7 @@ When you click on "Install all patches", XOA will do all of the following automa
You can see [more screenshots here](https://xen-orchestra.com/blog/hotfix-xs70e004-for-xenserver-7-0).
:::tip
If you are behind a proxy, please update your `xo-server` configuration to add a proxy server, as [explained in the appropriate section](../configuration.md#proxy-for-updates-and-patches).
If you are behind a proxy, please update your `xo-server` configuration to add a proxy server, as [explained in the appropriate section](../getting-started/configuration.md#proxy-for-updates-and-patches).
:::
#### Host updates
@@ -847,7 +847,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](../xo6/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](../manage-your-infrastructure/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" />

6
docs/docs/xo6/management.md → docs/docs/manage-your-infrastructure/management.md
View File

@@ -1,6 +1,6 @@
# 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](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 [XO 6 at a glance](../discover-xen-orchestra/gettingstarted.md).
## Pools
@@ -83,7 +83,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](../xo5/sdn_controller.md): it must be loaded, and switched to the **XAPI plugin** mode ([`useDirectChannel = false`](../configuration.md#sdn-controller-mode)). XO 6 shows a notification guiding you through the switch, and a [migration script](../xo5/sdn_controller.md#migration-path) converts existing rules.
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.
:::
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.
@@ -94,4 +94,4 @@ 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](../rbac.md).
For the permission model itself (roles, scopes and delegation), see [RBAC](../users-and-access/rbac.md).

12
docs/docs/xo5/sdn_controller.md → docs/docs/manage-your-infrastructure/sdn_controller.md
View File

@@ -1,6 +1,6 @@
# SDN controller
<InterfaceNote>Private networks are currently created and managed from XO 5. Traffic rules moved ahead in [XO 6](../xo6/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](../manage-your-infrastructure/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.
@@ -100,7 +100,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](../architecture.md#plugins).
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's configuration contains:
@@ -136,7 +136,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](../xo6/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
@@ -175,11 +175,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](../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](../xo6/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:
@@ -191,7 +191,7 @@ This is the backend used by the [XO 6 traffic rules UI](../xo6/management.md#tra
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](../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](../getting-started/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>`

4
docs/docs/xo5/vm-templates.md → docs/docs/manage-your-infrastructure/vm-templates.md
View File

@@ -144,7 +144,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](../windows-templates.md) guide.
To build such a template, follow the dedicated [Windows templates with Cloudbase-init](../guides/windows-templates.md) guide.
### Requirements
@@ -157,7 +157,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](../windows-templates.md) guide for complete instructions.
Refer to the [Windows templates with Cloudbase-init](../guides/windows-templates.md) guide for complete instructions.
### Example: How to create a Cloud-init template with Ubuntu 22.04 LTS?

8
docs/docs/project/_category_.json Normal file
View File

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

2
docs/docs/contributing.md → docs/docs/project/contributing.md
View File

@@ -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](./install-from-sources.md) to install and run Xen Orchestra from the sources
2. Follow [the documentation](../getting-started/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

44
docs/docs/glossary.md → docs/docs/project/glossary.md
View File

@@ -43,51 +43,51 @@
| **ISO SR** | ISO Storage | **SR** type used to store `.iso` images for VM install media. |
| **LVM** | Logical Volume Manager | Local volume-style **SR** (e.g. on host disks). |
| **MTU** | Maximum Transmission Unit | Largest Ethernet payload size on a link (e.g. jumbo frames). |
| **NBD** | Network Block Device | Protocol XO uses to read disk data directly from hosts, for faster [NBD-enabled backups](xo5/incremental_backups.md#nbd-enabled-backups). Required for incremental backups of QCOW2 disks. |
| **NBD** | Network Block Device | Protocol XO uses to read disk data directly from hosts, for faster [NBD-enabled backups](../backups-and-dr/backup-types/incremental_backups.md#nbd-enabled-backups). Required for incremental backups of QCOW2 disks. |
| **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](xo5/sdn_controller.md). |
| **Traffic rules** | | Firewall-like rules applied to networks and **VIFs** through the [SDN controller](../manage-your-infrastructure/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](full_backups.md). |
| **XVA** | XenServer Virtual Appliance | Archive format for a complete VM export, used by [full backups](../backups-and-dr/backup-types/full_backups.md). |
## High availability & operations
| Term | Meaning | Definition |
| ------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **HA** | High Availability | Pool feature to restart **VM**s elsewhere if a **host** fails (policy-driven). |
| **RPU** | Rolling Pool Update | XO-orchestrated [update of a whole pool](xo5/manage_infrastructure.md#rolling-pool-updates-rpu): hosts are patched and rebooted one by one while VMs are live migrated, with no VM downtime. |
| **RPU** | Rolling Pool Update | XO-orchestrated [update of a whole pool](../manage-your-infrastructure/manage_infrastructure.md#rolling-pool-updates-rpu): hosts are patched and rebooted one by one while VMs are live migrated, with no VM downtime. |
## Backup & replication
| Term | Meaning | Definition |
| -------------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **BR** | Backup Repository | Storage where XO writes backups (NFS, SMB, S3, local...), formerly called a "remote". See [backup repositories](xo5/backups.md#remotes). |
| **CBT** | Changed Block Tracking | XCP-ng/XenServer feature letting XO [purge snapshot data](xo5/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](xo5/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](xo5/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](full_replication.md). |
| **Full backup interval** | | Also called [key backup interval](xo5/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](xo5/backups.md#long-term-backup-retention-with-gfs-strategy) keeping daily, weekly, monthly and yearly backups. |
| **Health check** | | Automatic [restore test](xo5/backups.md#backup-health-check) after a backup: XO boots the restored VM to verify the backup is actually usable. |
| **Immutability** | | Protection making backups [unmodifiable for a configured duration](immutability.md), even by XO itself (ransomware protection). |
| **Mirror backup** | | A [backup of your backups](mirror_backup.md): copies the archives of one **BR** to another, the key to 3-2-1 strategies. |
| **[NOBAK]** | | Marker added to a **VDI** name to [exclude that disk](xo5/backups.md#exclude-disks) from all backup jobs. |
| **Rolling snapshot** | | Scheduled [automatic snapshots](rolling_snapshots.md) with retention. Snapshots live on the same **SR** as the VM: not a real backup. |
| **Sequence** | | [Chains backup schedules](xo5/backups.md#sequences) so they run one after the other instead of competing in parallel. |
| **Smart backup** | | [Selects VMs by criteria](xo5/backups.md#smart-backup) (pool, tags, power state) resolved at job runtime, instead of a fixed VM list. |
| **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). |
| **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. |
| **Immutability** | | Protection making backups [unmodifiable for a configured duration](../backups-and-dr/scale-and-security/immutability.md), even by XO itself (ransomware protection). |
| **Mirror backup** | | A [backup of your backups](../backups-and-dr/backup-types/mirror_backup.md): copies the archives of one **BR** to another, the key to 3-2-1 strategies. |
| **[NOBAK]** | | Marker added to a **VDI** name to [exclude that disk](../backups-and-dr/backup-features-and-settings.md#exclude-disks) from all backup jobs. |
| **Rolling snapshot** | | Scheduled [automatic snapshots](../backups-and-dr/backup-types/rolling_snapshots.md) with retention. Snapshots live on the same **SR** as the VM: not a real backup. |
| **Sequence** | | [Chains backup schedules](../backups-and-dr/backup-features-and-settings.md#sequences) so they run one after the other instead of competing in parallel. |
| **Smart backup** | | [Selects VMs by criteria](../backups-and-dr/backup-features-and-settings.md#smart-backup) (pool, tags, power state) resolved at job runtime, instead of a fixed VM list. |
## XCP-ng/Xen Orchestra-specific
| 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](xo5/v2v-migration-guide.md) importing VMs directly from VMware/ESXi to XCP-ng. |
| **V2V** | Virtual to Virtual | Built-in [migration tool](../guides/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](supported_hosts.md), developed by Vates alongside Xen Orchestra. |
| **XCP-ng** | | The open source, Xen-based hypervisor [managed by XO](../getting-started/supported_hosts.md), 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](xo6/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](../discover-xen-orchestra/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](xo5/proxy.md) to run backups locally, without streaming all data through the main XOA. |
| **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. |

8
docs/docs/intro_project.md → docs/docs/project/intro_project.md
View File

@@ -13,13 +13,13 @@ 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](xo6/xo6vsxo5.md).
- **June 2016**: XO 5.0, the first release of the generation still known today as [XO 5](../discover-xen-orchestra/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](xo5/v2v-migration-guide.md), the built-in tool to migrate VMs directly from VMware to XCP-ng.
- **January 2023**: first preview of [V2V](../guides/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](xo6/gettingstarted.md) interface, becomes the default UI.
- **February 2026**: XO 6.2 introduces [distributed backups](distributed_backups.md), spreading backup data across multiple backup repositories (BR).
- **December 2025**: XO 6.0, the first official release of the new [XO 6](../discover-xen-orchestra/gettingstarted.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.
- **July 2026**: XO 6.7 focuses on Rolling Pool Update reliability and keeps expanding the XO 6 workflows.

0
docs/docs/licenses.md → docs/docs/project/licenses.md
View File

8
docs/docs/support-and-licencing/_category_.json Normal file
View File

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

10
docs/docs/community.md → docs/docs/support-and-licencing/community.md
View File

@@ -3,7 +3,7 @@
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](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/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 +24,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](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](install-from-sources.md) and test again
3. then, if you still experience problems, [remove and rebuild from scratch](install-from-sources.md#troubleshooting)
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)
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](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.md#xoa).
:::
## Feature requests

2
docs/docs/intro_support.md → docs/docs/support-and-licencing/intro_support.md
View File

@@ -5,7 +5,7 @@ slug: support
# Support
:::tip
To run a self-diagnosis or open a secure support tunnel from your XOA, see [Troubleshooting](troubleshooting.md#still-stuck).
To run a self-diagnosis or open a secure support tunnel from your XOA, see [Troubleshooting](../getting-started/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).

8
docs/docs/users-and-access/_category_.json Normal file
View File

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

4
docs/docs/credential-encryption.md → docs/docs/users-and-access/credential-encryption.md
View File

@@ -9,7 +9,7 @@ Xen Orchestra stores its records (server connections, backup jobs and remotes, s
## Enabling Encryption
Add the following to your [configuration file](configuration.md):
Add the following to your [configuration file](../getting-started/configuration.md):
```toml
[redis]
@@ -55,7 +55,7 @@ The export contains the decrypted credential data (hence the mandatory passphras
xo-cli xo.importConfig passphrase=<your-passphrase> @=/path/to/xo-config.bin
`}</Terminal>
See also [Back up XO metadata](./backup_howto.md#specific-steps-for-the-xoa-vm).
See also [Back up XO metadata](../backups-and-dr/backup_howto.md#specific-steps-for-the-xoa-vm).
:::tip
Always export a fresh config backup after enabling encryption and store it securely.

10
docs/docs/rbac.md → docs/docs/users-and-access/rbac.md
View File

@@ -7,14 +7,14 @@ sidebar_label: RBAC
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](xo5/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.
:::
## What changed from the original ACLs
The original [ACL system](xo5/users.md#acls) allowed granting access to individual objects (a VM, an SR…). Simple, but limited: there was no way to say _"this user can shutdown only VMs tagged `qa`"_. It also only covered **XAPI objects**: VMs, hosts, SRs, networks. Users, groups, backups, schedules, and jobs were out of scope.
The original [ACL system](./users.md#acls) allowed granting access to individual objects (a VM, an SR…). Simple, but limited: there was no way to say _"this user can shutdown only VMs tagged `qa`"_. It also only covered **XAPI objects**: VMs, hosts, SRs, networks. Users, groups, backups, schedules, and jobs were out of scope.
RBAC introduces a full role-based model with effects, selectors, and an action hierarchy, covering the entire infrastructure including XO management objects.
@@ -54,7 +54,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](xo5/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
@@ -304,7 +304,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](xo6/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" />
@@ -312,7 +312,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](xo5/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.

10
docs/docs/xo5/users.md → docs/docs/users-and-access/users.md
View File

@@ -4,9 +4,9 @@
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](../installation.md#first-login).
- **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).
- **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:
@@ -474,7 +474,7 @@ You can now connect with your Google account in the login page.
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).
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?
@@ -628,7 +628,7 @@ Finally, if a user has been granted access to multiple resource sets, they can b
### Toward the Cloud
Self-service is a major step in the Cloud. Combine it with our [Cloudinit compatible VM creation](vm-templates.md#cloud-init) for a full experience:
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
@@ -666,4 +666,4 @@ Now, the audit plugin will record users' actions and upload the last record in t
## Debugging
If you can't log in, please [check the logs of `xo-server`](../troubleshooting.md#logs).
If you can't log in, please [check the logs of `xo-server`](../getting-started/troubleshooting.md#logs).

100
docs/docusaurus.config.ts
View File

@@ -39,111 +39,107 @@ export default {
{
redirects: [
{
to: '/xo5/manage_infrastructure#vms',
to: '/manage-your-infrastructure/manage_infrastructure#vms',
from: '/administration',
},
{
to: '/rbac',
to: '/users-and-access/rbac',
from: '/xo6/acl-v2',
},
{
to: '/xo5/advanced',
to: '/manage-your-infrastructure/advanced',
from: '/advanced',
},
{
to: '/xo5/advanced#alerts',
to: '/manage-your-infrastructure/advanced#alerts',
from: '/alerts',
},
{
to: '/xo5/users#acls',
to: '/users-and-access/users#acls',
from: '/acls',
},
{
to: '/getting-started/architecture',
from: '/xo5/architecture',
to: '/architecture',
},
{
to: '/architecture#plugins',
to: '/getting-started/architecture#plugins',
from: '/plugins',
},
{
to: '/backup_howto',
to: '/backups-and-dr/backup_howto',
from: '/xo5/backup_howto',
},
{
to: '/calculator',
to: '/backups-and-dr/calculator',
from: '/xo5/calculator',
},
{
to: '/xo5/backup_reports',
to: '/backups-and-dr/backup_reports',
from: '/backup_reports',
},
{
to: '/xo5/backup_troubleshooting',
to: '/backups-and-dr/backup_troubleshooting',
from: '/backup_troubleshooting',
},
{
to: '/xo5/backups',
to: '/backups-and-dr/backup-features-and-settings',
from: '/backups',
},
{
to: '/community',
to: '/support-and-licencing/community',
from: '/xo6/community',
},
{
to: '/getting-started/configuration',
from: '/xo5/configuration',
to: '/configuration',
},
{
to: '/credential-encryption',
to: '/users-and-access/credential-encryption',
from: '/xo5/credential-encryption',
},
{
to: '/full_backups',
to: '/backups-and-dr/backup-types/full_backups',
from: '/xo5/full_backups',
},
{
to: '/full_replication',
to: '/backups-and-dr/backup-types/full_replication',
from: '/xo5/full_replication',
},
{
to: '/immutability',
to: '/backups-and-dr/scale-and-security/immutability',
from: '/xo5/immutability',
},
{
to: '/xo5/incremental_backups',
to: '/backups-and-dr/backup-types/incremental_backups',
from: '/incremental_backups',
},
{
to: '/xo5/incremental_replication',
to: '/backups-and-dr/backup-types/incremental_replication',
from: '/incremental_replication',
},
{
to: '/getting-started/installation',
from: '/xo5/installation',
to: '/installation',
},
{
to: '/support',
from: '/xo6/support',
},
{
to: '/backup',
to: '/backups-and-dr/backup-features-and-settings',
from: '/xo5/backup',
},
{
to: '/support',
from: ['/license_management', '/xo5/license_management'],
to: '/support-and-licencing/support',
from: ['/license_management', '/xo5/license_management', '/xo6/support'],
},
{
to: '/xo5/load_balancing',
to: '/manage-your-infrastructure/load_balancing',
from: '/load_balancing',
},
{
to: '/manage-your-infrastructure/manage_infrastructure',
from: ['/manage', '/xo5/manage'],
to: '/xo5/manage_infrastructure',
},
{
to: '/xo5/manage_infrastructure',
to: '/manage-your-infrastructure/manage_infrastructure',
from: '/manage_infrastructure',
},
{
@@ -151,32 +147,32 @@ export default {
from: ['/mcp', '/xo5/mcp'],
},
{
to: '/xo5/metadata_backup',
to: '/backups-and-dr/backup-types/metadata_backup',
from: '/metadata_backup',
},
{
from: '/xo5/migrate_to_new_xoa',
to: '/migrate_to_new_xoa',
to: '/getting-started/migrate_to_new_xoa',
from: '/migrate_to_new_xoa',
},
{
to: '/mirror_backup',
to: '/backups-and-dr/backup-types/mirror_backup',
from: '/xo5/mirror_backup',
},
{
to: '/object-storage-support',
to: '/backups-and-dr/scale-and-security/object-storage-support',
from: '/xo5/object-storage-support',
},
{
to: '/xo5/proxy',
to: '/backups-and-dr/scale-and-security/proxy',
from: '/proxy',
},
{
to: '/support',
to: '/support-and-licencing/support#licensing',
from: ['/purchase', '/xo6/purchase'],
},
{
from: '/xo5/releases',
to: '/releases',
to: '/getting-started/releases',
from: '/releases',
},
{
to: '/automation/restapi',
@@ -207,39 +203,39 @@ export default {
from: '/xo6/kubernetes',
},
{
to: '/rolling_snapshots',
to: '/backups-and-dr/backup-types/rolling_snapshots',
from: '/xo5/rolling_snapshots',
},
{
to: '/xo5/sdn_controller',
to: '/manage-your-infrastructure/sdn_controller',
from: '/sdn_controller',
},
{
from: '/xo5/supported_hosts',
to: '/supported_hosts',
to: '/getting-started/supported_hosts',
from: '/supported_hosts',
},
{
to: '/getting-started/troubleshooting',
from: ['/general-troubleshooting', '/xo5/troubleshooting'],
to: '/troubleshooting',
},
{
from: '/xo5/updater',
to: '/updater',
to: '/getting-started/updater',
from: '/updater',
},
{
to: '/xo5/users',
to: '/users-and-access/users',
from: '/users',
},
{
to: '/xo5/v2v-migration-guide',
to: '/guides/v2v-migration-guide',
from: '/v2v-migration-guide',
},
{
to: '/xo5/vm-templates',
to: '/manage-your-infrastructure/vm-templates',
from: '/vm-templates',
},
{
to: '/installation',
to: '/getting-started/installation',
from: ['/xoa', '/xo5/xoa'],
},
],
@@ -341,7 +337,7 @@ export default {
},
{
label: 'Installation',
href: '/installation',
href: '/getting-started/installation',
},
],
},

172
docs/sidebars.ts
View File

@@ -11,8 +11,8 @@ import type { SidebarsConfig } from '@docusaurus/plugin-content-docs'
Create as many sidebars as you want.
*/
/*
const sidebars: SidebarsConfig = {
const sidebars = {
// By default, Docusaurus generates a sidebar from the docs folder structure
tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
@@ -27,171 +27,7 @@ const sidebars: SidebarsConfig = {
items: ['tutorial-basics/create-a-document'],
},
],
*/
};
*/
export default {
docs: [
{
type: 'doc',
id: 'intro',
label: 'Introduction',
},
{
type: 'category',
label: 'Getting started',
collapsible: true,
collapsed: false,
items: [
'releases',
'supported_hosts',
'installation',
'install-from-sources',
'configuration',
'updater',
'migrate_to_new_xoa',
'troubleshooting',
'architecture',
],
},
{
type: 'category',
label: 'Discover Xen Orchestra',
collapsible: true,
collapsed: false,
items: ['xo6/whatsnew', 'xo6/xo6vsxo5', 'xo6/gettingstarted', 'xo6/coreconcepts'],
},
{
type: 'category',
label: 'Manage your infrastructure',
collapsible: true,
collapsed: true,
items: [
'xo6/management',
'xo5/manage_infrastructure',
'xo5/vm-templates',
'xo5/advanced',
'xo5/load_balancing',
'xo5/sdn_controller',
'xo5/ipmi-plugin',
],
},
{
type: 'category',
label: 'Backups and DR',
collapsible: true,
collapsed: true,
items: [
'intro_backup',
'backup_howto',
'xo6/backups',
{
type: 'category',
label: 'Backup types',
collapsible: true,
collapsed: true,
items: [
'rolling_snapshots',
'full_backups',
'xo5/incremental_backups',
'full_replication',
'xo5/incremental_replication',
'mirror_backup',
'xo5/metadata_backup',
],
},
'xo5/backups',
{
type: 'category',
label: 'Scale and security',
collapsible: true,
collapsed: true,
items: ['xo5/proxy', 'distributed_backups', 'object-storage-support', 'immutability'],
},
'xo5/backup_reports',
'xo5/backup_troubleshooting',
'calculator',
],
},
{
type: 'category',
label: 'Users and access',
collapsible: true,
collapsed: true,
items: ['xo5/users', 'rbac', 'credential-encryption'],
},
{
type: 'category',
label: 'Guides',
collapsible: true,
collapsed: true,
items: ['xo5/v2v-migration-guide', 'windows-templates'],
},
{
type: 'category',
label: 'Automation',
collapsible: true,
collapsed: true,
items: [
'automation/restapi',
'automation/mcp',
'automation/terraform-provider',
'automation/ansible',
'automation/pulumi-provider',
'automation/packer-provider',
'automation/powershell-module',
'automation/kubernetes',
],
},
{
type: 'category',
label: 'Support and licensing',
collapsible: true,
collapsed: true,
items: [
'intro_support',
{
type: 'link',
label: 'Vates VMS bundles',
href: 'https://docs.vates.tech/pricing-licencing/vms-bundle-overview/',
},
{
type: 'link',
label: 'Applying XO licenses',
href: 'https://docs.vates.tech/pricing-licencing/applying-xo-licences/',
},
'community',
],
},
{
type: 'category',
label: 'Project',
collapsible: true,
collapsed: true,
items: [
'intro_project',
{
type: 'link',
label: 'Blog',
href: 'https://xen-orchestra.com/blog/',
},
{
type: 'link',
label: 'Changelog',
href: 'https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.md#changelog',
},
'contributing',
'licenses',
{
type: 'link',
label: 'Roadmap',
href: 'https://docs.vates.tech/product-roadmap/',
},
'glossary',
],
},
],
}
//export default sidebars;
module.exports = sidebars;

2
docs/src/components/InterfaceNote/index.tsx
View File

@@ -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='/xo6/xo6vsxo5'>See what lives where</Link>.
<Link to='/discover-xen-orchestra/xo6vsxo5'>See what lives where</Link>.
</div>
</div>
)