feat(docs): major rewrite using vue-press (#4957)
This commit is contained in:
Olivier Lambert
GitHub
parent
b138438036
commit
30d69dadbb
106
docs/.vuepress/config.js
Normal file
106
docs/.vuepress/config.js
Normal file
@ -0,0 +1,106 @@
|
||||
module.exports = {
|
||||
title: 'XO documentation',
|
||||
description: 'Official Xen Orchestra documentation',
|
||||
head: [
|
||||
[
|
||||
'link',
|
||||
{
|
||||
rel: 'shortcut icon',
|
||||
href: 'https://xen-orchestra.com/assets/favicon.ico',
|
||||
},
|
||||
],
|
||||
],
|
||||
base: '/docs/',
|
||||
themeConfig: {
|
||||
smoothScroll: true,
|
||||
logo: 'https://xen-orchestra.com/blog/content/images/2017/05/xo-logo.png',
|
||||
lastUpdated: 'Last Updated', // add latest Git commit modification for each file
|
||||
repo: 'vatesfr/xen-orchestra', // point to the GH repo
|
||||
editLinks: true, // display link for people to edit a page
|
||||
editLinkText: 'Help us to improve this page!', // link text
|
||||
docsDir: 'docs',
|
||||
nav: [
|
||||
{ text: 'Home', link: 'https://xen-orchestra.com' },
|
||||
{ text: 'News', link: 'https://xen-orchestra.com/blog' },
|
||||
{ text: 'Documentation', link: '/' },
|
||||
],
|
||||
sidebar: [
|
||||
{
|
||||
title: 'Xen Orchestra', // required
|
||||
path: '/', // optional, link of the title, which should be an absolute path and must exist
|
||||
collapsable: false, // optional, defaults to true
|
||||
sidebarDepth: 1, // optional, defaults to 1
|
||||
children: [
|
||||
['/releases', 'Releases'],
|
||||
['/supported_hosts', 'Host Compatibility List'],
|
||||
['/installation', 'Installation'],
|
||||
['/configuration', 'Configuration'],
|
||||
['/updater', 'Updates'],
|
||||
['/architecture', 'Architecture'],
|
||||
['/troubleshooting', 'Troubleshooting'],
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'Management', // required
|
||||
path: '/manage', // optional, link of the title, which should be an absolute path and must exist
|
||||
collapsable: false, // optional, defaults to true
|
||||
sidebarDepth: 1, // optional, defaults to 1
|
||||
children: [
|
||||
['/manage_infrastructure', 'Infrastructure'],
|
||||
['/users', 'Users'],
|
||||
['/advanced', 'Advanced features'],
|
||||
['/load_balancing', 'VM Load Balancing'],
|
||||
['/sdn_controller', 'SDN Controller'],
|
||||
['/xosan', 'XOSANv1'],
|
||||
['/xosanv2', 'XOSANv2'],
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'Backup', // required
|
||||
path: '/backup', // optional, link of the title, which should be an absolute path and must exist
|
||||
collapsable: false, // optional, defaults to true
|
||||
sidebarDepth: 1, // optional, defaults to 1
|
||||
children: [
|
||||
['/backups', 'Concepts'],
|
||||
['/proxy', 'Proxy'],
|
||||
['/rolling_snapshots', 'Snapshots'],
|
||||
['/full_backups', 'Full backup'],
|
||||
['/delta_backups', 'Delta Backup'],
|
||||
['/disaster_recovery.md', 'Disaster Recovery'],
|
||||
['/continuous_replication', 'Continuous Replication'],
|
||||
['/metadata_backup', 'Metadata Backup'],
|
||||
['/backup_reports', 'Backup Reports'],
|
||||
['/backup_troubleshooting', 'Backup Troubleshooting'],
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'Support', // required
|
||||
path: '/support', // optional, link of the title, which should be an absolute path and must exist
|
||||
collapsable: false, // optional, defaults to true
|
||||
sidebarDepth: 1, // optional, defaults to 1
|
||||
children: [
|
||||
['/xoa', 'XOA Support'],
|
||||
['/purchase', 'Purchase XOA'],
|
||||
['/community', 'Community Support'],
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'Project', // required
|
||||
path: '/project', // optional, link of the title, which should be an absolute path and must exist
|
||||
collapsable: false, // optional, defaults to true
|
||||
sidebarDepth: 1, // optional, defaults to 1
|
||||
children: [
|
||||
[
|
||||
'https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.md#changelog',
|
||||
'Changelog',
|
||||
],
|
||||
['/code_of_conduct', 'Code of Conduct'],
|
||||
['/contributing', 'Contributing'],
|
||||
['/licenses', 'Licenses'],
|
||||
['/roadmap', 'Roadmap'],
|
||||
['/glossary', 'Glossary'],
|
||||
],
|
||||
},
|
||||
],
|
||||
},
|
||||
}
|
||||
1
docs/.vuepress/styles/palette.styl
Normal file
1
docs/.vuepress/styles/palette.styl
Normal file
@ -0,0 +1 @@
|
||||
$accentColor = #cc584c
|
||||
@ -8,23 +8,10 @@ XO is a web interface to visualize and administer your XenServer (or XAPI enable
|
||||
|
||||
It aims to be easy to use on any device supporting modern web technologies (HTML 5, CSS 3, JavaScript), such as your desktop computer or your smartphone.
|
||||
|
||||
## Quick start
|
||||
|
||||
Log in to your account and use the deploy form available on [Xen Orchestra website](https://xen-orchestra.com/#!/xoa).
|
||||
|
||||
More details available on the [installation section](installation.md#xoa).
|
||||
|
||||
|
||||
|
||||
## XOA quick deploy
|
||||
|
||||
Log in to your account and use the deploy form available on [this page](https://xen-orchestra.com/#!/xoa)
|
||||
|
||||
> **Note:** no data will be sent to our servers, it's running only between your browser and your host!
|
||||
|
||||
[](https://xen-orchestra.com/#!/xoa)
|
||||
|
||||
### XOA credentials
|
||||
|
||||
- Web UI: `admin@admin.net` / `admin`
|
||||
- Console/SSH: `xoa` / `xoa` (first login)
|
||||
|
||||
## Must read
|
||||
|
||||
- [XOA installation](xoa.md)
|
||||
- [Main features](features.md)
|
||||
- [Pro Support](support.md)
|
||||
|
||||
277
docs/advanced.md
Normal file
277
docs/advanced.md
Normal file
@ -0,0 +1,277 @@
|
||||
# Advanced features
|
||||
|
||||
This section is dedicated to all others Xen Orchestra "advanced features".
|
||||
|
||||
## Live Telemetry
|
||||
|
||||
When you are working on your virtualized infrastructure, you might need a very detailed view on what's going on. From resource consumption analysis (CPU/RAM) to network traffic, but also storage, having a kind of very detailed dashboard per host can be really useful.
|
||||
|
||||
:::tip
|
||||
This feature will be only available in XCP-ng+XOA. If you are a hardcore Citrix Hypervisor user, let us know if you want this.
|
||||
:::
|
||||
|
||||
### Enable Advanced Live Telemtry for a host
|
||||
|
||||
Go into the Advanced host view:
|
||||
|
||||
|
||||
|
||||
By clicking here, XOA will handle everything: installing netdata on the host, and configure a secured/encrypted streaming toward your XOA.
|
||||
|
||||
As soon it's installed, the button will now be replaced by a "Go to Advanced Live Telemetry". As soon you'll click on it, you'll be redirected to the netdata page of the host. If you have multiple host, you can access any of them directly from the top menu of the netdata UI.
|
||||
|
||||
### Examples
|
||||
|
||||
IMPI info (power, temperatures, voltages, fans…):
|
||||
|
||||
|
||||
|
||||
:::tip
|
||||
This feature is only available in one-click in your XOA. However, all sources and packages to do it yourself are available!
|
||||
:::
|
||||
|
||||
Memory details:
|
||||
|
||||
|
||||
|
||||
Firewall:
|
||||
|
||||
|
||||
|
||||
## Cloud init
|
||||
|
||||
Cloud-init is a program "that handles the early initialization of a cloud instance"[^n]. In other words, you can, on a "cloud-init"-ready template VM, pass a lot of data at first boot:
|
||||
|
||||
- setting the hostname
|
||||
- add ssh keys
|
||||
- automatically grow the file system
|
||||
- create users
|
||||
- and a lot more!
|
||||
|
||||
This tool is pretty standard and used everywhere. A lot of existing cloud templates are using it.
|
||||
|
||||
So it means very easily customizing your VM when you create it from a compatible template. It brings you closer to the "instance" principle, like in Amazon cloud or OpenStack.
|
||||
|
||||
### Requirements
|
||||
|
||||
You only need to use a template of a VM with CloudInit installed inside it. [Check this blog post to learn how to install CloudInit](https://xen-orchestra.com/blog/centos-cloud-template-for-xenserver/).
|
||||
|
||||
:::tip
|
||||
In XOA 5.31, we changed the cloud-init config drive type from [OpenStack](https://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html) to the [NoCloud](https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html) type. This will allow us to pass network configuration to VMs in the future. For 99% of users, including default cloud-init installs, this change will have no effect. However if you have previously modified your cloud-init installation in a VM template to only look for `openstack` drive types (for instance with the `datasource_list` setting in `/etc/cloud/cloud.cfg`) you need to modify it to also look for `nocloud`.
|
||||
:::
|
||||
|
||||
### Usage
|
||||
|
||||
First, select your compatible template (CloudInit ready) and name it:
|
||||
|
||||
|
||||
|
||||
Then, activate the config drive and insert your SSH key. Or you can also use a custom CloudInit configuration:
|
||||
|
||||
|
||||
|
||||
> CloudInit configuration examples are [available here](http://cloudinit.readthedocs.org/en/latest/topics/examples.html).
|
||||
|
||||
You can extend the disk size (**in this case, the template disk was 8 GiB originally**). We'll extend it to 20GiB:
|
||||
|
||||
|
||||
|
||||
Finally, create the VM:
|
||||
|
||||
|
||||
|
||||
Now start the VM and SSH to its IP:
|
||||
|
||||
- **the system has the right VM hostname** (from VM name)
|
||||
- you don't need to use a password to access it (thanks to your SSH key):
|
||||
|
||||
```
|
||||
$ ssh centos@192.168.100.226
|
||||
[centos@tmp-app1 ~]$
|
||||
```
|
||||
|
||||
The default `cloud-init` configuration can allow you to be to be a sudoer directly:
|
||||
|
||||
```
|
||||
[centos@tmp-app1 ~]$ sudo -s
|
||||
[root@tmp-app1 centos]#
|
||||
```
|
||||
|
||||
Check the root file system size: indeed, **it was automatically increased** to what you need:
|
||||
|
||||
```
|
||||
[centos@tmp-app1 ~]$ df -h
|
||||
/dev/xvda1 20G 1,2G 18G 6% /
|
||||
```
|
||||
|
||||
## Web hooks
|
||||
|
||||
:::warning
|
||||
We need your feedback on this feature!
|
||||
:::
|
||||
|
||||
### Configuration
|
||||
|
||||
The plugin "web-hooks" needs to be installed and loaded for this feature to work.
|
||||
|
||||
You can trigger an HTTP POST request to a URL when a Xen Orchestra API method is called.
|
||||
|
||||
- Go to Settings > Plugins > Web hooks
|
||||
- Add new hooks
|
||||
- For each hook, configure:
|
||||
- Method: the XO API method that will trigger the HTTP request when called
|
||||
- Type:
|
||||
- pre: the request will be sent when the method is called
|
||||
- post: the request will be sent after the method action is completed
|
||||
- pre/post: both
|
||||
- URL: the full URL which the requests will be sent to
|
||||
- Save the plugin configuration
|
||||
|
||||
From now on, a request will be sent to the corresponding URLs when a configured method is called by an XO client.
|
||||
|
||||
### Request content
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Content-Type: application/json
|
||||
```
|
||||
|
||||
The request's body is a JSON string representing an object with the following properties:
|
||||
|
||||
- `type`: `"pre"` or `"post"`
|
||||
- `callId`: unique ID for this call to help match a pre-call and a post-call
|
||||
- `userId`: unique internal ID of the user who performed the call
|
||||
- `userName`: login/e-mail address of the user who performed the call
|
||||
- `method`: name of the method that was called (e.g. `"vm.start"`)
|
||||
- `params`: call parameters (object)
|
||||
- `timestamp`: epoch timestamp of the beginning ("pre") or end ("post") of the call in ms
|
||||
- `duration`: duration of the call in ms ("post" hooks only)
|
||||
- `result`: call result on success ("post" hooks only)
|
||||
- `error`: call result on error ("post" hooks only)
|
||||
|
||||
### Request handling
|
||||
|
||||
_Quick Node.js example of how you may want to handle the requests_
|
||||
|
||||
```js
|
||||
const http = require('http')
|
||||
const { exec } = require('child_process')
|
||||
|
||||
http
|
||||
.createServer((req, res) => {
|
||||
let body = ''
|
||||
req.on('data', chunk => {
|
||||
body += chunk
|
||||
})
|
||||
req.on('end', () => handleHook(body))
|
||||
res.end()
|
||||
})
|
||||
.listen(3000)
|
||||
|
||||
const handleHook = data => {
|
||||
const { method, params, type, result, error, timestamp } = JSON.parse(data)
|
||||
|
||||
// Log it
|
||||
console.log(
|
||||
`${new Date(
|
||||
timestamp
|
||||
).toISOString()} [${method}|${type}] ${params} → ${result || error}`
|
||||
)
|
||||
|
||||
// Run scripts
|
||||
exec(`./hook-scripts/${method}-${type}.sh`)
|
||||
}
|
||||
```
|
||||
|
||||
## Alerts
|
||||
|
||||
Alerts are a way to warn the administrator about various events. The first kind of alerts will be emails and also in a dedicated area of `xo-web` to display them.
|
||||
|
||||
### Performances alerts
|
||||
|
||||
The administrator will configure alerts based on performance thresholds.
|
||||
|
||||
The configurable metrics are:
|
||||
|
||||
- CPU usage (VM, host)
|
||||
- RAM usage (VM, host)
|
||||
- network bandwidth (VM, host)
|
||||
- load average (host)
|
||||
- disk IO (VM)
|
||||
- total IO (SR, only for XenServer Dundee and higher)
|
||||
|
||||
If any configured values exceed the threshold during a selected period of time, an alert will be sent.
|
||||
|
||||
Those alerts will be also stored and accessible in the web interface, and also later for the load balancing feature (helping it to solve those performance problems).
|
||||
|
||||
### Updates alerts
|
||||
|
||||
:::warning
|
||||
:construction_worker: This feature might be missing. We are investigating. :construction_worker:
|
||||
:::
|
||||
|
||||
When your XOA detects new packages, you'll be notified by email.
|
||||
|
||||
### Backup alerts
|
||||
|
||||
Same story for backups: if a backup fails, you'll receive an email.
|
||||
|
||||
You can choose to be notified only if it fails or even after each backup job.
|
||||
|
||||
Current supported alerts system:
|
||||
|
||||
- Email
|
||||
- XMPP
|
||||
|
||||
## Job manager
|
||||
|
||||
The key idea is to be able to schedule any action (migrate, reboot etc.), for things like backups, snapshots or DR actions.
|
||||
|
||||
In the main menu, go to the "Job Manager" section:
|
||||
|
||||
|
||||
|
||||
You can now **schedule all actions** on your hosts, VMs, or ACLs. It's configured in 2 steps:
|
||||
|
||||
1. Create a job
|
||||
1. Schedule it!
|
||||
|
||||
Real example, step by step: **Creating a job called "security reboot"** (in this case, restarting "nfs" and "Core1" VMs):
|
||||
|
||||
|
||||
|
||||
Note that you can execute this job **now** by clicking on the orange play button (to test it for instance):
|
||||
|
||||
|
||||
|
||||
**Schedule the job** (every Sunday at 5:00 AM):
|
||||
|
||||
|
||||
|
||||
And that's it! The job is listed in the Overview:
|
||||
|
||||
|
||||
|
||||
The possibilities are infinite! You can schedule a **lot** of things (any actions on a VM, like migrate, start, clone, suspend etc. Same thing also applies to hosts).
|
||||
|
||||
### Examples
|
||||
|
||||
#### Save on your electric bill
|
||||
|
||||
- plan a live migration of your VMs at 11:00PM to a less powerful host, then shutdown the big one
|
||||
- start the big server at 6:00AM and migrate the VMs back 15 minutes later
|
||||
|
||||
#### Scale when needed
|
||||
|
||||
- schedule the boot of extra VMs during your usual activity spikes (horizontal scaling)
|
||||
- also add more vCPUs or RAM to these VMs at the same time
|
||||
- go back to the previous state when your planned load is low (e.g: during the night)
|
||||
|
||||
#### Planned reboot
|
||||
|
||||
- For example: your client app is not very stable, or you need to reboot every month after kernel updates: schedule this during the weekend!
|
||||
|
||||
#### Add or Remove ACLs
|
||||
|
||||
- revoke your user ACLs Friday at 11:00PM (e.g: no access on the weekend)
|
||||
- restore them Monday at 6:00AM
|
||||
@ -2,7 +2,9 @@
|
||||
|
||||
Xen Orchestra (XO) is software built with a server and clients, such as the web client `xo-web`, but also a CLI capable client, called `xo-cli`.
|
||||
|
||||
> XO is totally agent-less: you don't have to install any program on your hosts to get it working!
|
||||
:::tip
|
||||
XO is totally agent-less: you don't have to install any program on your hosts to get it working!
|
||||
:::
|
||||
|
||||
## XOA
|
||||
|
||||
@ -10,7 +12,7 @@ _Xen Orchestra Virtual Appliance_ (XOA) is a virtual machine with Xen Orchestra
|
||||
|
||||
This is the easiest way to try Xen Orchestra quickly.
|
||||
|
||||
Your XOA is connected to all your hosts, or the pool master only if you are using Pools in XenServer:
|
||||
Your XOA is connected to all your hosts, or the pool master only if you are using Pools in XCP-ng/Citrix Hypervisor:
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
docs/assets/gpn.png
Normal file
BIN
docs/assets/gpn.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
BIN
docs/assets/proxy-section.png
Normal file
BIN
docs/assets/proxy-section.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.8 KiB |
21
docs/backup.md
Normal file
21
docs/backup.md
Normal file
@ -0,0 +1,21 @@
|
||||
# Backup
|
||||
|
||||
Xen Orchestra is currently the most capable and advanced solution to backup your VMs/infrastructure. There's many ways and solutions to achieve what you need, take time to read them all. Take a look on the [concept section](backups.md) to learn more about how it works.
|
||||
|
||||
Alternatively, here is a video recap on different backup capabilities:
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/FfUqIwT8KzI" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
- [Rolling Snapshots](rolling_snapshots.md)
|
||||
- [Full Backups](full_backups.md)
|
||||
- [Delta Backups](delta_backups.md)
|
||||
- [Disaster Recovery](disaster_recovery.md)
|
||||
- [Metadata Backups](metadata_backup.md)
|
||||
- [Continuous Replication](continuous_replication.md)
|
||||
- [File Level Restore](file_level_restore.md)
|
||||
|
||||
> Don't forget to take a look at the [backup troubleshooting](backup_troubleshooting.md) section. You can also take a look at the [backup reports](backup_reports.md) section for configuring notifications.
|
||||
|
||||
:::tip
|
||||
There is also a way to automatically select the VMs to backup: **[smart backup](backups.md#smart-backup)**.
|
||||
:::
|
||||
@ -1,8 +1,8 @@
|
||||
# How to configure backup reports
|
||||
# Backup reports
|
||||
|
||||
At the end of a backup job, you can configure Xen Orchestra to send backup reports directly by email, Slack or in Mattermost. It's up to you.
|
||||
|
||||
## Email notifications
|
||||
## Email
|
||||
|
||||
### Step-by-step
|
||||
|
||||
@ -16,7 +16,7 @@ At the end of a backup job, you can configure Xen Orchestra to send backup repor
|
||||
|
||||
> Note: You can also modify existing backup jobs and change the behaviour of the report system.
|
||||
|
||||
## XMPP nofications
|
||||
## XMPP
|
||||
|
||||
You can **be notified via XMPP** after the backup task is finished (scheduled "full backup", "snapshots" or "disaster recovery").
|
||||
|
||||
@ -29,7 +29,7 @@ That's it: your next scheduled job will be recapped in a message:
|
||||
|
||||
|
||||
|
||||
## Slack or Mattermost notifications
|
||||
## Slack or Mattermost
|
||||
|
||||
Xen Orchestra is able to send backup reports to Slack or Mattermost.
|
||||
|
||||
@ -45,23 +45,23 @@ Like all other xo-server plugins, it can be configured directly via the web inte
|
||||
|
||||
2. Click on the **Main menu** at the top and choose **Apps & Integrations**
|
||||
|
||||
|
||||
|
||||
|
||||
3. Search **Incoming WebHooks**
|
||||
|
||||
|
||||
|
||||
|
||||
4. Click on **Add Configuration**
|
||||
|
||||
|
||||
|
||||
|
||||
5. Choose the default channel and click on **Add Incoming WebHooks integration**
|
||||
|
||||
|
||||
|
||||
|
||||
6. Modify the default settings and click on **Save Settings**
|
||||
|
||||
|
||||
|
||||
|
||||
#### Mattermost
|
||||
|
||||
@ -75,12 +75,12 @@ You need to be an admin:
|
||||
|
||||
#### Slack
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### Mattermost
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
# Backup troubleshooting
|
||||
|
||||
This section is dedicated to help you if you have problems with XO Backups.
|
||||
|
||||
## Backup progress
|
||||
|
||||
While a backup job is running, you should see activity in the "Tasks" view (Menu/Tasks), like this:
|
||||
|
||||
|
||||
|
||||
|
||||
Another good way to check if there is activity is the XOA VM stats view (on the Network graph).
|
||||
|
||||
## Error messages
|
||||
|
||||
### VDI chain protection
|
||||
## VDI chain protection
|
||||
|
||||
Backup jobs regularly delete snapshots. When a snapshot is deleted, either manually or via a backup job, it triggers the need for Xenserver to coalesce the VDI chain - to merge the remaining VDIs and base copies in the chain. This means generally we cannot take too many new snapshots on said VM until Xenserver has finished running a coalesce job on the VDI chain.
|
||||
|
||||
@ -43,15 +43,17 @@ If you don't see any running coalesce jobs, and can't find any other reason that
|
||||
|
||||
As a last resort, migrating the VM (more specifically, its disks) to a new storage repository will also force a coalesce and solve this issue. That means migrating a VM to another host (with its own storage) and back will force the VDI chain for that VM to be coalesced, and get rid of the `VDI Chain Protection` message.
|
||||
|
||||
### Parse Error
|
||||
## Parse Error
|
||||
|
||||
This is most likely due to running a backup job that uses Delta functionality (eg: delta backups, or continuous replication) on a version of XenServer older than 6.5. To use delta functionality you must run [XenServer 6.5 or later](https://xen-orchestra.com/docs/supported-version.html).
|
||||
|
||||
### SR_BACKEND_FAILURE_44 (insufficient space)
|
||||
## SR_BACKEND_FAILURE_44
|
||||
|
||||
> This message can be triggered by any backup method.
|
||||
:::tip
|
||||
This message can be triggered by any backup method.
|
||||
:::
|
||||
|
||||
The Storage Repository (where your VM disks are currently stored) is full. Note that doing a snapshot on a thick provisioned SR (LVM family for all block devices, like iSCSI, HBA or Local LVM) will consume the current disk size. Eg if you are using this kind of SR at more than 50% and you want to backup ALL VM disks on it, you'll hit this wall.
|
||||
`SR_BACKEND_FAILURE_44 (insufficient space)` means the Storage Repository (where your VM disks are currently stored) is full. Note that doing a snapshot on a thick provisioned SR (LVM family for all block devices, like iSCSI, HBA or Local LVM) will consume the current disk size. Eg if you are using this kind of SR at more than 50% and you want to backup ALL VM disks on it, you'll hit this wall.
|
||||
|
||||
Workarounds:
|
||||
|
||||
@ -60,23 +62,23 @@ Workarounds:
|
||||
- wait for Citrix to allow another mechanism besides snapshot to be able to export disks
|
||||
- use less than 50% of SR space or don't backup all VMs
|
||||
|
||||
### Could not find the base VM
|
||||
## Could not find the base VM
|
||||
|
||||
This message appears when the previous replicated VM has been deleted on the target side which breaks the replication. To reset the process it's necessary to delete VM snapshot related to this CR job on the original VM. The name of this snapshot is: `XO_DELTA_EXPORT: <name label of target SR> (<UUID of target SR>)`
|
||||
|
||||
### LICENSE_RESTRICTION(PCI_device_for_auto_update)
|
||||
## LICENSE_RESTRICTION
|
||||
|
||||
This message appears when you try to do a backup/snapshot from a VM that was previously on a host with an active commercial XenServer license but is now on a host with a free edition of XenServer.
|
||||
`LICENSE_RESTRICTION (PCI_device_for_auto_update)` message appears when you try to do a backup/snapshot from a VM that was previously on a host with an **active commercial XenServer license** but is now on a host with a free edition of XenServer/Citrix Hypervisor.
|
||||
|
||||
To solve it, you have to change a parameter in your VM. `xe vm-param-set has-vendor-device=false uuid=<VM_UUID>`
|
||||
To solve it, you have to change a parameter in your VM. `xe vm-param-set has-vendor-device=false uuid=<VM_UUID>`.
|
||||
|
||||
### ENOSPC: no space left on device
|
||||
## ENOSPC: no space left on device
|
||||
|
||||
This message appears when you do not have enough free space on the target remote when running a backup to it.
|
||||
|
||||
To check your free space, enter your XOA and run `xoa check` to check free system space and `df -h` to check free space on your chosen remote storage.
|
||||
|
||||
### Error: no VMs match this pattern
|
||||
## Error: no VMs match this pattern
|
||||
|
||||
This is happening when you have a _smart backup job_ that doesn't match any VMs. For example: you created a job to backup all running VMs. If no VMs are running on backup schedule, you'll have this message. This could also happen if you lost connection with your pool master (the VMs aren't visible anymore from Xen Orchestra).
|
||||
|
||||
|
||||
172
docs/backups.md
172
docs/backups.md
@ -1,28 +1,14 @@
|
||||
# Backups
|
||||
# Concepts
|
||||
|
||||
> Watch our [introduction video](https://www.youtube.com/watch?v=FfUqIwT8KzI) (45m) to Backup in Xen Orchestra!
|
||||
This section is dedicated to all general concepts about Xen Orchestra backups.
|
||||
|
||||
This section is dedicated to all existing methods of rolling back or backing up your VMs in Xen Orchestra.
|
||||
## Interface
|
||||
|
||||
There are several ways to protect your VMs:
|
||||
|
||||
- [Full Backups](full_backups.md) [*Starter Edition*]
|
||||
- [Rolling Snapshots](rolling_snapshots.md) [*Starter Edition*]
|
||||
- [Delta Backups](delta_backups.md) (best of both previous ones) [*Enterprise Edition*]
|
||||
- [Disaster Recovery](disaster_recovery.md) [*Enterprise Edition*]
|
||||
- [Metadata Backups](metadata_backup.md) [*Enterprise Edition*]
|
||||
- [Continuous Replication](continuous_replication.md) [*Premium Edition*]
|
||||
- [File Level Restore](file_level_restore.md) [*Premium Edition*]
|
||||
|
||||
> Don't forget to take a look at the [backup troubleshooting](backup_troubleshooting.md) section. You can also take a look at the [backup reports](backup_reports.md) section for configuring notifications.
|
||||
|
||||
There is also a way to automatically select the VMs to backup: **[smart backup](smart_backup.md)** [*Enterprise Edition*]
|
||||
|
||||
## Overview
|
||||
### Overview
|
||||
|
||||
This is the welcome panel for the backup view. It recaps all existing scheduled jobs. This is also where the backup logs are displayed.
|
||||
|
||||
## Logs
|
||||
### Logs
|
||||
|
||||
All the scheduled operations (backup, snapshots and even DR) are displayed in the main backup view.
|
||||
|
||||
@ -30,15 +16,102 @@ A successful backup task will be displayed in green, a faulty one in red. You ca
|
||||
|
||||
You also have a filter to search anything related to these logs.
|
||||
|
||||
> Logs are not "live" tasks. If you restart XOA during a backup, the log associated with the job will stay in orange (in progress), because it wasn't finished. It will stay forever unfinished because the job was cut in the middle.
|
||||
:::tip
|
||||
Logs are not "live" tasks. If you restart XOA during a backup, the log associated with the job will stay in orange (in progress), because it wasn't finished. It will stay forever unfinished because the job was cut in the middle.
|
||||
:::
|
||||
|
||||
## Backups execution
|
||||
### Backups execution
|
||||
|
||||
Each backups' job execution is identified by a `runId`. You can find this `runId` in its detailed log.
|
||||
|
||||
|
||||
|
||||
## Consistent backup (with quiesce snapshots)
|
||||
## Schedule
|
||||
|
||||
> :construction_worker: This section needs to be completed: screenshots and how-to :construction_worker:
|
||||
|
||||
## Smart Backup
|
||||
|
||||
There are two ways to select which VMs will be backed up:
|
||||
|
||||
1. Manually selecting multiple VM's
|
||||
1. Smart backup
|
||||
|
||||
Picking VMs manually can be a limitation if your environment moves fast (i.e. having new VMs you need to backup often). In that situation you would previously need to constantly go back and edit the backup job to add new VM's.
|
||||
|
||||
But thanks to _smart backup_, you now have more flexibility: you won't select specific VMs, but VMs status/tag/placement **at the time backup job will be executed**. Let's see some examples!
|
||||
|
||||
### Backup all VMs on a pool
|
||||
|
||||
This job will backup all VMs on a pool "Lab Pool" when scheduled:
|
||||
|
||||
|
||||
|
||||
It means: **every VM existing on this pool at the time of the backup job will be backed up**. Doesn't matter if you create a new VM, it will be backed up too without editing any backup job.
|
||||
|
||||
**You now have the ability to intelligently backup VM's in production pools!**
|
||||
|
||||
Want to narrow the job a bit? See below.
|
||||
|
||||
### Backup filters
|
||||
|
||||
You can also:
|
||||
|
||||
- backup only running (or halted) VMs when the job is executed
|
||||
- backup only VMs with a specific tag
|
||||
|
||||
Remember the Prod VMs? I added a tag "prod" to each of them:
|
||||
|
||||
|
||||
|
||||
Now if you do this:
|
||||
|
||||
|
||||
|
||||
It means any VMs on "Lab Pool" with the "prod" tag will be backed up.
|
||||
|
||||
## RAM Enabled bakcup
|
||||
|
||||
:::tip
|
||||
This feature is **only compatible** with XCP-ng 8.0 or more recent. Citrix Hypervisor didn't yet merge our changes, despite we contributed to their code directly.
|
||||
:::
|
||||
|
||||
|
||||
|
||||
XCP-ng modified XAPI is now able to create VMs in a `Suspended` state with a `suspend_VDI` property set. When a VM is suspended, all of its memory contents are written into a disk called `suspend_VDI`. When the VM is restored, the `suspend_VDI` is read to recreate the memory of the VM. Once the resuming is done it's as if the VM was never suspended.
|
||||
|
||||
### Use cases
|
||||
|
||||
It is already possible to snapshot a VM with its RAM, however when restoring a VM, the VM was created in the `Halted` state so it wasn't possible to restore the VM with its RAM. With our XAPI modification a VM can now be created in a `Suspended` state with preset memory contents, so when snapshotting a VM with RAM, the snapshotted VM will also have the RAM contents set.
|
||||
|
||||
This can be very useful when you're running a VM that needs RAM coherence to run:
|
||||
|
||||
- For instance, snapshotting a Windows VM used to be very tricky for this reason. The Citrix VSS script previously answered part of this problem, when snapshotted, the VM flushed its cache but if it happened that the snapshot had coherence issues, the restored VM would be broken. And the VSS script is no longer available.
|
||||
- VMs running databases could also need such a feature in order to keep transient transactions.
|
||||
- A VM can be restored on a different host, now the RAM can be as well.
|
||||
|
||||
In a nutshell this functionality can be seen as _hot copy_, similar to _hot migration_ but the original VM is not deleted.
|
||||
|
||||
### Continuous replication with RAM
|
||||
|
||||
This feature allows you to regularly send a copy of a VM to a target SR. The copied VM will be `Suspended` and ready to be resumed if the original VM encounters issues. As the copied VM is `Suspended`, no reboot will be required, resuming it is much faster.
|
||||
|
||||
For instance, if an hourly continuous replication is configured on a VM, if the VM is lost, you can quickly resume a running VM with a memory loss of one hour tops.
|
||||
|
||||
:::warning
|
||||
In order to use this functionality, the CPU of the host the VM is restored on should be the same or more recent than the CPU of the host the VM was originally running on.
|
||||
:::
|
||||
|
||||
### Future of RAM enabled backup
|
||||
|
||||
- Better analyze of compatible CPUs to avoid manual compatibility checks
|
||||
- RAM snapshot using Xen copy-on-write memory capabilities (time to snapshot reduce to almost 0)
|
||||
|
||||
## Consistent backup
|
||||
|
||||
:::warning
|
||||
This feature is being deprecated in XCP-ng and Citrix Hypervisor. It's now replaced by RAM enabled backup!
|
||||
:::
|
||||
|
||||
All backup types rely on snapshots. But what about data consistency? By default, Xen Orchestra will try to take a **quiesced snapshot** every time a snapshot is done (and fall back to normal snapshots if it's not possible).
|
||||
|
||||
@ -64,7 +137,9 @@ Supported remote types:
|
||||
- NFS
|
||||
- SMB (CIFS)
|
||||
|
||||
> **WARNING**: the initial "/" or "\\" is automatically added.
|
||||
:::warning
|
||||
The initial "/" or "\\" is automatically added.
|
||||
:::
|
||||
|
||||
### NFS
|
||||
|
||||
@ -74,7 +149,9 @@ On your NFS server, authorize XOA's IP address and permissions for subfolders. T
|
||||
|
||||
We support SMB storage on _Windows Server 2012 R2_.
|
||||
|
||||
> WARNING: For continuous delta backup, SMB is **NOT** recommended (or only for small VMs, eg < 50GB)
|
||||
:::warning
|
||||
For continuous delta backup, SMB is **NOT** recommended (or only for small VMs, eg < 50GB)
|
||||
:::
|
||||
|
||||
Also, read the UI twice when you add an SMB store. If you have:
|
||||
|
||||
@ -86,7 +163,9 @@ You'll have to fill it like this:
|
||||
|
||||
|
||||
|
||||
**PATH TO BACKUP is only needed if you have subfolders in your share.**
|
||||
:::warning
|
||||
PATH TO BACKUP is only needed if you have subfolders in your share.
|
||||
:::
|
||||
|
||||
### Local
|
||||
|
||||
@ -99,7 +178,7 @@ If you need to mount an unsupported store (FTP for example), you can always do i
|
||||
|
||||
Any Debian Linux mount point could be supported this way, until we add further options directly in the web interface.
|
||||
|
||||
## Restore backups
|
||||
## Restore a backup
|
||||
|
||||
All your scheduled backups are acccessible in the "Restore" view in the backup section of Xen Orchestra.
|
||||
|
||||
@ -107,19 +186,45 @@ All your scheduled backups are acccessible in the "Restore" view in the backup s
|
||||
2. Choose the backup you want to restore
|
||||
3. Select the SR where you want to restore it
|
||||
|
||||
> Note: You can restore your backup even on a brand new XenServer and on brand new hardware.
|
||||
:::tip
|
||||
You can restore your backup even on a brand new host/pool and on brand new hardware.
|
||||
:::
|
||||
|
||||
## File level restore
|
||||
|
||||
You can also restore specific files and directories inside a VM. It works with all your existing delta backups.
|
||||
|
||||
:::warning
|
||||
File level restore **is only possible on delta backups**
|
||||
:::
|
||||
|
||||
### Restore a file
|
||||
|
||||
Go into the Backup/File restore section:
|
||||
|
||||
|
||||
|
||||
Then, click on the VM where your files are, and follow the instructions:
|
||||
|
||||
|
||||
|
||||
That's it! Your chosen file will be restored.
|
||||
|
||||
## About backup compression
|
||||
|
||||
By default, _Backups_ are compressed (using GZIP, done on XenServer side). There is no absolute rule but in general uncompressed backups are faster (but sometimes much larger).
|
||||
By default, _Backups_ are compressed (using GZIP or zstd, done on host side). There is no absolute rule but in general uncompressed backups are faster than GZIP backups (but sometimes much larger).
|
||||
|
||||
XenServer uses Gzip compression, which is:
|
||||
Citrix Hypervisor uses Gzip compression, which is:
|
||||
|
||||
- slow (single threaded)
|
||||
- space efficient
|
||||
- consumes less bandwidth (helpful if your NFS share is far away)
|
||||
|
||||
However, XCP-ng is using `zstd`, which is far better.
|
||||
|
||||
:::tip
|
||||
If you have compression on your NFS share (or destination filesystem like ZFS), you can disable compression in Xen Orchestra.
|
||||
:::
|
||||
|
||||
## Add a disk for local backups
|
||||
|
||||
@ -131,7 +236,6 @@ Then, create a filesystem on it:
|
||||
|
||||
```
|
||||
mkfs.ext4 /dev/xvdb
|
||||
|
||||
```
|
||||
|
||||
If you already have backups done, you can move them to the new disk. The orignal backups folder is in `/var/lib/xoa-backups`.
|
||||
@ -144,11 +248,13 @@ To make the mount point persistent in XOA, edit the `/etc/fstab` file, and add:
|
||||
|
||||
This way, without modifying your previous scheduled snapshot, they will be written to this new local mountpoint!
|
||||
|
||||
## High availability (HA) disabled on replicated VMs
|
||||
## HA behavior
|
||||
|
||||
Replicated VMs HA are taken into account by XS/XCP-ng. To avoid the resultant troubles, HA will be disabled from the replicated VMs and a tag indicating this change will be added.
|
||||
Replicated VMs HA are taken into account by XCP-ng. To avoid the resultant troubles, HA will be disabled from the replicated VMs and a tag indicating this change will be added.
|
||||
|
||||
|
||||
|
||||
|
||||
> The tag won't be automatically removed by XO on the replicated VMs, even if HA is re-enabled.
|
||||
:::tip
|
||||
The tag won't be automatically removed by XO on the replicated VMs, even if HA is re-enabled.
|
||||
:::
|
||||
|
||||
16
docs/community.md
Normal file
16
docs/community.md
Normal file
@ -0,0 +1,16 @@
|
||||
# Community support
|
||||
|
||||
:::warning
|
||||
If you installed your XO from a 3rd party script (any method outside [our official documentation](installation.md#from-the-sources)), please report your issue **first** on the script repository. We can't waste time on debugging 3rd party installers.
|
||||
:::
|
||||
|
||||
If you have issues on XO installed from the sources (via GitHub), please **always** do first:
|
||||
|
||||
1. update your XO to latest `master` commit (see how-to in the [dedicated section](installation.md#updating)) and retest again
|
||||
2. if the issue persist, double check you have all the requirements checked from the [installation section](installation.md#from-the-sources) and test again
|
||||
3. then, if you still experience problems, remove and rebuild from scratch
|
||||
|
||||
Only after that, you can go on 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 to use our preconfigured and validated [Xen Orchestra virtual Appliance](installation.md#xoa).
|
||||
@ -2,11 +2,13 @@
|
||||
|
||||
Once Xen Orchestra is installed, you can configure some parameters in the configuration file. Let's see how to do that.
|
||||
|
||||
## Configuration
|
||||
|
||||
:::tip
|
||||
The configuration file is located at `/etc/xo-server/config.toml`.
|
||||
:::
|
||||
|
||||
### User to run XO-server as
|
||||
If you need to do any configuration on the system itself (firewall, SSH…), check the [XOA dedicated section](xoa.md).
|
||||
|
||||
## User to run XO-server as
|
||||
|
||||
By default, XO-server runs as 'root'. You can change that by uncommenting these lines and choose whatever user/group you want:
|
||||
|
||||
@ -17,7 +19,7 @@ group = 'nogroup'
|
||||
|
||||
**Warning!** A non-privileged user requires the use of `sudo` to mount NFS shares. See [installation from the sources](from_the_sources.md).
|
||||
|
||||
### HTTP listen address and port
|
||||
## HTTP listen address and port
|
||||
|
||||
By default, XO-server listens on all addresses (0.0.0.0) and runs on port 80. If you need to, you can change this in the `# Basic HTTP` section:
|
||||
|
||||
@ -26,7 +28,7 @@ hostname = '0.0.0.0'
|
||||
port = 80
|
||||
```
|
||||
|
||||
### HTTPS
|
||||
## HTTPS
|
||||
|
||||
XO-server can also run in HTTPS (you can run HTTP and HTTPS at the same time) - just modify what's needed in the `# Basic HTTPS` section, this time with the certificates/keys you need and their path:
|
||||
|
||||
@ -37,9 +39,11 @@ certificate = './certificate.pem'
|
||||
key = './key.pem'
|
||||
```
|
||||
|
||||
> If a chain of certificates authorities is needed, you may bundle them directly in the certificate. Note: the order of certificates does matter, your certificate should come first followed by the certificate of the above certificate authority up to the root.
|
||||
:::tip
|
||||
If a chain of certificates authorities is needed, you may bundle them directly in the certificate. Note: the order of certificates does matter, your certificate should come first followed by the certificate of the above certificate authority up to the root.
|
||||
:::
|
||||
|
||||
#### HTTPS redirection
|
||||
### HTTPS redirection
|
||||
|
||||
If you want to redirect everything to HTTPS, you can modify the configuration like this:
|
||||
|
||||
@ -51,7 +55,7 @@ redirectToHttps = true
|
||||
|
||||
This should be written just before the `mount` option, inside the `http:` block.
|
||||
|
||||
### Link to XO-web
|
||||
## Link to xo-web
|
||||
|
||||
You shouldn't have to change this. It's the path where `xo-web` files are served by `xo-server`.
|
||||
|
||||
@ -60,7 +64,7 @@ You shouldn't have to change this. It's the path where `xo-web` files are served
|
||||
'/' = '../xo-web/dist/'
|
||||
```
|
||||
|
||||
### Custom certificate authority
|
||||
## Custom certificate authority
|
||||
|
||||
If you use certificates signed by an in-house CA for your XenServer hosts, and want to have Xen Orchestra connect to them without rejection, you need to add the `--use-openssl-ca` option in Node, but also add the CA to your trust store (`/etc/ssl/certs` via `update-ca-certificates` in your XOA).
|
||||
|
||||
@ -77,9 +81,11 @@ Don't forget to reload `systemd` conf and restart `xo-server`:
|
||||
# systemctl restart xo-server.service
|
||||
```
|
||||
|
||||
**Note:** The `--use-openssl-ca` option is ignored by Node if Xen-Orchestra is run with Linux capabilities. Capabilities are commonly used to bind applications to privileged ports (<1024) (i.e. `CAP_NET_BIND_SERVICE`). Local NAT rules (`iptables`) or a reverse proxy would be required to use privileged ports and a custom certficate authority.
|
||||
:::tip
|
||||
The `--use-openssl-ca` option is ignored by Node if Xen-Orchestra is run with Linux capabilities. Capabilities are commonly used to bind applications to privileged ports (<1024) (i.e. `CAP_NET_BIND_SERVICE`). Local NAT rules (`iptables`) or a reverse proxy would be required to use privileged ports and a custom certficate authority.
|
||||
:::
|
||||
|
||||
### Redis server
|
||||
## Redis server
|
||||
|
||||
By default, XO-server will try to contact Redis server on `localhost`, with the port `6379`. But you can define whatever you want:
|
||||
|
||||
@ -87,7 +93,7 @@ By default, XO-server will try to contact Redis server on `localhost`, with the
|
||||
uri = 'tcp://db:password@hostname:port'
|
||||
```
|
||||
|
||||
### Proxy for XenServer updates and patches
|
||||
## Proxy for updates and patches
|
||||
|
||||
To check if your hosts are up-to-date, we need to access `http://updates.xensource.com/XenServer/updates.xml`.
|
||||
|
||||
@ -105,6 +111,57 @@ You can add this at the end of your config file:
|
||||
httpProxy = 'http://username:password@proxyAddress:port'
|
||||
```
|
||||
|
||||
### Log file
|
||||
## Log file
|
||||
|
||||
On XOA, the log file for XO-server is in `/var/log/syslog`. It contains all the server information returned and can be a real help when you have trouble.
|
||||
|
||||
## Reverse proxy
|
||||
|
||||
If you don't want to have Xen Orchestra exposed directly outside, or just integrating it with your existing infrastructure, you can use a Reverse Proxy.
|
||||
|
||||
### Apache
|
||||
|
||||
As `xo-web` and `xo-server` communicate with _WebSockets_, you need to have the [`mod_proxy`](http://httpd.apache.org/docs/2.4/mod/mod_proxy.html), [`mod_proxy_http`](http://httpd.apache.org/docs/2.4/mod/mod_proxy_http.html), [`mod_proxy_wstunnel`](http://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html) and [`mod_rewrite`](http://httpd.apache.org/docs/2.4/mod/mod_rewrite.html) modules enabled.
|
||||
|
||||
Please use this configuration in this order or it will not work. Do not forget the trailing slashes:
|
||||
|
||||
```apacheconf
|
||||
RewriteEngine On
|
||||
RewriteCond %{HTTP:upgrade} websocket [NC]
|
||||
RewriteRule /[<path>]/(.*) ws://<xo-server ip>:<xo-server port>/$1 [L,P]
|
||||
|
||||
ProxyPass /[<path>]/ http://<xo-server ip>:<xo-server port>/
|
||||
ProxyPassReverse /[<path>]/ http://<xo-server ip>:<xo-server port>/
|
||||
```
|
||||
|
||||
### NGINX
|
||||
|
||||
Just configure your VirtualHost as usual (or your default site), with a `location` section like this one:
|
||||
|
||||
```nginx
|
||||
location /[<path>] {
|
||||
# Add some headers
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
|
||||
# Proxy configuration
|
||||
proxy_pass http://<XOA ip address>[:<port>]/;
|
||||
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Connection "upgrade";
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
|
||||
proxy_redirect default;
|
||||
|
||||
# Issue https://github.com/vatesfr/xen-orchestra/issues/1471
|
||||
proxy_read_timeout 1800; # Error will be only every 30m
|
||||
|
||||
# For the VM import feature, this size must be larger than the file we want to upload.
|
||||
# Without a proper value, nginx will have error "client intended to send too large body"
|
||||
client_max_body_size 4G;
|
||||
}
|
||||
```
|
||||
|
||||
That's all!
|
||||
|
||||
@ -1,7 +1,5 @@
|
||||
# Continuous Replication
|
||||
|
||||
> WARNING: it works only with XenServer 6.5 or later
|
||||
|
||||
This feature is a continuous replication system for your XenServer VMs **without any storage vendor lock-in**. You can replicate a VM every _X_ minutes/hours to any storage repository. It could be to a distant XenServer host or just another local storage target.
|
||||
|
||||
This feature covers multiple objectives:
|
||||
@ -18,7 +16,9 @@ If you lose your main pool, you can start the copy on the other side, with very
|
||||
|
||||
|
||||
|
||||
> Warning: it is normal that you can't boot the copied VM directly: we protect it. The normal workflow is to make a clone and then work on it.
|
||||
:::warning
|
||||
It is normal that you can't boot the copied VM directly: we protect it. The normal workflow is to make a clone and then work on it.
|
||||
:::
|
||||
|
||||
## Configure it
|
||||
|
||||
@ -38,7 +38,9 @@ To protect the replication, we removed the possibility to boot your copied VM di
|
||||
|
||||
**If you can't transfer the first backup through your network because it's too large**, you can make a seed locally. In order to do this, follow this procedure (until we make it accessible directly in XO).
|
||||
|
||||
> This is **only** if you need to make the initial copy without making the whole transfer through your network. Otherwise, **you don't need this**. These instructions are for Backup-NG jobs, and will not work to seed a legacy backup job. Please migrate any legacy jobs to Backup-NG!
|
||||
:::tip
|
||||
This is **only** if you need to make the initial copy without making the whole transfer through your network. Otherwise, **you don't need this**. These instructions are for Backup-NG jobs, and will not work to seed a legacy backup job. Please migrate any legacy jobs to Backup-NG!
|
||||
:::
|
||||
|
||||
### Job creation
|
||||
|
||||
|
||||
@ -6,6 +6,10 @@ XO is an Open Source project released under the [AGPL v3](http://www.gnu.org/lic
|
||||
|
||||
You can [open bug reports here](https://github.com/vatesfr/xen-orchestra/issues) (issues, enhancements, ideas etc.).
|
||||
|
||||
:::tip
|
||||
Before creating an issue, please take a look [into this section](community.md) for more details.
|
||||
:::
|
||||
|
||||
## Documentation / Code
|
||||
|
||||
Using the GitHub fork/pull-request feature, you may send us fixes or enhancements.
|
||||
|
||||
@ -1,7 +1,5 @@
|
||||
# Continuous Delta backups
|
||||
|
||||
> WARNING: Delta backups are only available on XenServer 6.5 or later
|
||||
|
||||
You can export only the delta (difference) between your current VM disks and a previous snapshot (called here the _reference_). They are called _continuous_ because you'll **never export a full backup** after the first one.
|
||||
|
||||
## Introduction
|
||||
|
||||
@ -14,13 +14,13 @@ As you may have seen in other parts of the documentation, XO is composed of two
|
||||
|
||||
### NodeJS
|
||||
|
||||
XO needs Node.js. **Please use Node LTS**.
|
||||
XO needs Node.js. **Please use Node LTS version 12**.
|
||||
|
||||
We'll consider at this point that you've got a working node on your box. E.g:
|
||||
|
||||
```
|
||||
$ node -v
|
||||
v12.16.1
|
||||
v12.16.3
|
||||
```
|
||||
|
||||
If not, see [this page](https://nodejs.org/en/download/package-manager/) for instructions on how to install Node.
|
||||
|
||||
@ -4,8 +4,6 @@ You can schedule full backups of your VMs, by exporting them to the local XOA fi
|
||||
|
||||
[](https://xen-orchestra.com/blog/backup-your-xenserver-vms-with-xen-orchestra/)
|
||||
|
||||
Full backups are space consuming! But they allow a very simple restoration without anything to think of (the file will contain all the VM disks and information).
|
||||
|
||||
## How it works
|
||||
|
||||
Full backups use XenServer's VM export capabilities. We store and rotate XVA files. It works very well. If you want to use less disk space, take a look at the [delta backups](delta_backups.md) feature.
|
||||
:::tip
|
||||
Full backups are space consuming! But they allow a very simple restoration without anything to think of (the file will contain all the VM disks and information). To use less space and data transferred, take a look at the [delta backups](delta_backups.md) feature.
|
||||
:::
|
||||
|
||||
@ -1,9 +1,246 @@
|
||||
# Installation
|
||||
|
||||
Log in to your account and use the deploy form available on [this page](https://xen-orchestra.com/#!/xoa)
|
||||
## XOA
|
||||
|
||||
Log in to your account and use the deploy form [available on this page](https://xen-orchestra.com/#!/xoa).
|
||||
|
||||
:::tip
|
||||
All the deploy code is within your browser, nothing is sent to our server!
|
||||
:::
|
||||
|
||||
|
||||
|
||||
## [More on XOA and alternate deploy](xoa.md)
|
||||
### First Login
|
||||
|
||||
Once you have started the VM, you can access the web UI by putting the IP you configured during deployment into your web browser. If you did not configure an IP or are unsure, try one of the following methods to find it:
|
||||
|
||||
- Run `xe vm-list params=name-label,networks | grep -A 1 XOA` on your host
|
||||
- Check your router's DHCP leases for an `xoa` lease
|
||||
|
||||
:::tip
|
||||
|
||||
- Default Web UI credentials are `admin@admin.net` / `admin`
|
||||
- Default console/SSH credentials are `xoa` / `xoa` (first login)
|
||||
:::
|
||||
|
||||
### Registration
|
||||
|
||||
**The first thing** you need to do with your XOA is register. [Read the documentation on the page dedicated to the updater/register inferface](updater.md#register).
|
||||
|
||||
:::tip
|
||||
We don't generate virtual appliances every month (unlike XO code itself). It's very likely you'll need to update Xen Orchestra after the initial deploy. You need to register to do so!
|
||||
:::
|
||||
|
||||
### More on XOA
|
||||
|
||||
You can get all the info you want on XOA in its [dedicated section](xoa.md).
|
||||
|
||||
|
||||
|
||||
## From the sources
|
||||
|
||||
:::warning
|
||||
We don't provide pro support for this installation method. We cannot guarantee anything if it's used in production. Use it at your own risk!
|
||||
:::
|
||||
|
||||
:::tip
|
||||
Please consider using XOA before trying to play with the manual build, which can be difficult if you are not used to NodeJS and NPM.
|
||||
:::
|
||||
|
||||
This installation has been validated against a fresh Debian 10 (Buster) x64 install. It should be nearly the same on other dpkg systems. For RPM based OS's, it should be close, as most of our dependencies come from NPM and not the OS itself.
|
||||
|
||||
As you may have seen in other parts of the documentation, XO is composed of two parts: [xo-server](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-server/) and [xo-web](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-web/). They can be installed separately, even on different machines, but for the sake of simplicity we will set them up together.
|
||||
|
||||
### Packages and Pre-requisites
|
||||
|
||||
#### NodeJS
|
||||
|
||||
XO needs Node.js. **Please use Node LTS**.
|
||||
|
||||
We'll consider at this point that you've got a working node on your box. E.g:
|
||||
|
||||
```
|
||||
$ node -v
|
||||
v12.16.1
|
||||
```
|
||||
|
||||
If not, see [this page](https://nodejs.org/en/download/package-manager/) for instructions on how to install Node.
|
||||
|
||||
#### Yarn
|
||||
|
||||
> Yarn is a package manager that offers more guarantees than npm.
|
||||
|
||||
See [this page](https://yarnpkg.com/en/docs/install#debian-stable) for instructions on how to install Yarn.
|
||||
|
||||
#### Packages
|
||||
|
||||
XO needs the following packages to be installed. Redis is used as a database by XO.
|
||||
|
||||
For example, on Debian/Ubuntu:
|
||||
|
||||
```
|
||||
$ apt-get install build-essential redis-server libpng-dev git python-minimal libvhdi-utils lvm2 cifs-utils
|
||||
```
|
||||
|
||||
On Fedora/CentOS like:
|
||||
|
||||
```
|
||||
$ dnf install redis libpng-devel git libvhdi-utils lvm2 cifs-utils make automake gcc gcc-c++
|
||||
```
|
||||
|
||||
### Fetching the Code
|
||||
|
||||
You need to use the `git` source code manager to fetch the code. Ideally, you should run XO as a non-root user, and if you choose to, you need to set up `sudo` to be able to mount NFS remotes. As your chosen non-root (or root) user, run the following:
|
||||
|
||||
```
|
||||
git clone -b master http://github.com/vatesfr/xen-orchestra
|
||||
```
|
||||
|
||||
:::tip
|
||||
`xo-server` and `xo-web` have been migrated to the [xen-orchestra](https://github.com/vatesfr/xen-orchestra) mono-repository - so you only need the single clone command above
|
||||
:::
|
||||
|
||||
### Installing dependencies
|
||||
|
||||
Now that you have the code, you can enter the `xen-orchestra` directory and use `yarn` to install other dependencies. Then finally build it using `yarn build`. Be sure to run `yarn` commands as the same user you will be using to run Xen Orchestra:
|
||||
|
||||
```
|
||||
$ cd xen-orchestra
|
||||
$ yarn
|
||||
$ yarn build
|
||||
```
|
||||
|
||||
Now you have to create a config file for `xo-server`:
|
||||
|
||||
```
|
||||
$ cd packages/xo-server
|
||||
$ mkdir -p ~/.config/xo-server
|
||||
$ cp sample.config.toml ~/.config/xo-server/config.toml
|
||||
```
|
||||
|
||||
> Note: If you're installing `xo-server` as a global service, you may want to copy the file to `/etc/xo-server/config.toml` instead.
|
||||
|
||||
In this config file, you can change default ports (80 and 443) for xo-server. If you are running the server as a non-root user, you will need to set the port to 1024 or higher.
|
||||
|
||||
You can try to start xo-server to see if it works. You should have something like this:
|
||||
|
||||
```
|
||||
$ yarn start
|
||||
WebServer listening on localhost:80
|
||||
[INFO] Default user: "admin@admin.net" with password "admin"
|
||||
```
|
||||
|
||||
### Running XO
|
||||
|
||||
The only part you need to launch is xo-server, which is quite easy to do. From the `xen-orchestra/packages/xo-server` directory, run the following:
|
||||
|
||||
```
|
||||
$ yarn start
|
||||
```
|
||||
|
||||
That's it! Use your browser to visit the xo-server IP address, and it works! :)
|
||||
|
||||
### Updating
|
||||
|
||||
If you would like to update your current version, enter your `xen-orchestra` directory and run the following:
|
||||
|
||||
```
|
||||
# This will clear any changes you made in the repository!!
|
||||
$ git checkout .
|
||||
|
||||
$ git pull --ff-only
|
||||
$ yarn
|
||||
$ yarn build
|
||||
```
|
||||
|
||||
Then restart Xen Orchestra if it was running.
|
||||
|
||||
### Always Running
|
||||
|
||||
- You can use [forever](https://github.com/nodejitsu/forever) to have the process always running:
|
||||
|
||||
```
|
||||
yarn global add forever
|
||||
# Run the below as the user owning XO
|
||||
forever start bin/xo-server
|
||||
```
|
||||
|
||||
- Or you can use [forever-service](https://github.com/zapty/forever-service) to install XO as a system service, so it starts automatically at boot. Run the following as root:
|
||||
|
||||
```
|
||||
yarn global add forever
|
||||
yarn global add forever-service
|
||||
# Be sure to edit the path below to where your install is located!
|
||||
cd /home/username/xen-orchestra/packages/xo-server/bin/
|
||||
# Change the username below to the user owning XO
|
||||
forever-service install orchestra -r username -s xo-server
|
||||
```
|
||||
|
||||
The forever-service command above must be run in the xo-server bin directory. Now you can manage the service, and it will start on boot with the machine:
|
||||
|
||||
```
|
||||
service orchestra start
|
||||
service orchestra status
|
||||
```
|
||||
|
||||
If you need to delete the service:
|
||||
|
||||
```
|
||||
forever-service delete orchestra
|
||||
```
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
If you have problems during the building phase, follow these steps in your `xen-orchestra` directory:
|
||||
|
||||
1. `rm -rf node_modules`
|
||||
1. `yarn`
|
||||
1. `yarn build`
|
||||
|
||||
### FreeBSD
|
||||
|
||||
If you are using FreeBSD, you need to install these packages:
|
||||
|
||||
```
|
||||
pkg install gmake redis python git npm node autoconf
|
||||
```
|
||||
|
||||
You can update `npm` itself right now with a `npm update -g`
|
||||
|
||||
A few of the npm packages look for system binaries as part of their installation, and if missing will try to build it themselves. Installing these will save some time and allow for easier upgrades later:
|
||||
|
||||
```
|
||||
pkg install jpeg-turbo optipng gifsicle
|
||||
```
|
||||
|
||||
Because FreeBSD is shipped with CLANG and not GCC, you need to do this:
|
||||
|
||||
```
|
||||
ln -s /usr/bin/clang++ /usr/local/bin/g++
|
||||
```
|
||||
|
||||
To enable redis on boot, add this in your `/etc/rc.conf`:
|
||||
|
||||
```
|
||||
redis_enable="YES"
|
||||
```
|
||||
|
||||
Don't forget to start redis if you don't reboot now:
|
||||
|
||||
```
|
||||
service redis start
|
||||
```
|
||||
|
||||
### sudo
|
||||
|
||||
If you are running `xo-server` as a non-root user, you need to use `sudo` to be able to mount NFS remotes. You can do this by editing `xo-server` configuration file and setting `useSudo = true`. It's near the end of the file:
|
||||
|
||||
```
|
||||
useSudo = true
|
||||
```
|
||||
|
||||
You need to configure `sudo` to allow the user of your choice to run mount/umount commands without asking for a password. Depending on your operating system / sudo version, the location of this configuration may change. Regardless, you can use:
|
||||
|
||||
```
|
||||
username ALL=(root)NOPASSWD: /bin/mount, /bin/umount
|
||||
```
|
||||
|
||||
5
docs/licenses.md
Normal file
5
docs/licenses.md
Normal file
@ -0,0 +1,5 @@
|
||||
# Licenses
|
||||
|
||||
XO is an Open Source project released under the [AGPL v3](http://www.gnu.org/licenses/agpl-3.0-standalone.html) license, contributions are therefore very welcome.
|
||||
|
||||
|
||||
15
docs/manage.md
Normal file
15
docs/manage.md
Normal file
@ -0,0 +1,15 @@
|
||||
# Manage
|
||||
|
||||
Xen Orchestra is based on the concept of **one interface to rule all your pools, hosts and VMs, from any device**. It's made to do any object creation, modification, displays metrics and statistics. In other words, all the tools you need to administer your XCP-ng/Citrix Hypervisor (formerly XenServer) infrastructure efficiently.
|
||||
|
||||
See the [Infrastructure management section](manage_infrastructure.md) for more details and examples.
|
||||
|
||||
|
||||
|
||||
But there's even more! You can:
|
||||
|
||||
- [create XO users](users.md) to delegate resources
|
||||
- use [advanced features](advanced.md) like Cloud Init or web hooks
|
||||
- [load balance](load_balancing.md) your VMs
|
||||
- extend your network with [our SDN controller](sdn_controller.md)
|
||||
- create an [hyperconverged storage](xosan.md)
|
||||
537
docs/manage_infrastructure.md
Normal file
537
docs/manage_infrastructure.md
Normal file
@ -0,0 +1,537 @@
|
||||
# Infrastructure management
|
||||
|
||||
This section is related on how to manage your XCP-ng/Citrix Hypervisor infrastructure.
|
||||
|
||||
## Home view
|
||||
|
||||
The home view is what you see when you access your Xen Orchestra URL. It displays all running VMs. This can be configured to your needs (see the "Filters section" below).
|
||||
|
||||
If you don't have any servers connected, you'll see a panel telling you to add a server:
|
||||
|
||||
|
||||
|
||||
### Add a host
|
||||
|
||||
Just click on "Add server", enter the IP of a XenServer host (ideally the pool master if in a pool):
|
||||
|
||||
|
||||
|
||||
After clicking on connect, the server is displayed as connected:
|
||||
|
||||
|
||||
|
||||
Now go back to the Home view (or click on the "Xen Orchestra" title on the top left of the screen), you'll see the default home view of VM objects.
|
||||
|
||||
### VMs
|
||||
|
||||
By default, this view groups all **running VMs** on your connected server:
|
||||
|
||||
|
||||
|
||||
Let's take a quick tour:
|
||||
|
||||
- the global menu is on the left, you can collapse it by clicking on the icon 
|
||||
- the home view has a header with a type selector (VMs, hosts or pools), a filter zone and a button to create new VMs
|
||||
- the VM list also has a header (number of filtered VMs and total VMs) and assisted filters (by pool, host and tags) and a sort menu (by name, memory etc.). You can also expand all VMs details here with the icon 
|
||||
|
||||
> Pro Tip: you can edit a VM name, description and even current host by long clicking on the field
|
||||
|
||||
## Bulk actions
|
||||
|
||||
You can select multiple objects (eg VMs) at once to perform a bulk action. The master checkbox will select all, or you can select anything yourself.
|
||||
|
||||
After selecting one or more object, an action bar is displayed:
|
||||
|
||||
|
||||
|
||||
This will execute the action for all selected objects!
|
||||
|
||||
### Hosts
|
||||
|
||||
All host objects are displayed:
|
||||
|
||||
|
||||
|
||||
You have power status, name, description, number of CPU cores, total memory, management IP and pool name displayed. You can also edit these by long clicking.
|
||||
|
||||
> Pro Tip: If hosts have missing patches, you'll see a red dot with the total patches missing. Click on it to go the patch section of the host. See this blog post on [patches for XenServer](https://xen-orchestra.com/blog/hotfix-xs70e004-for-xenserver-7-0/) for more details.
|
||||
|
||||
### Pools
|
||||
|
||||
All your pools are displayed here:
|
||||
|
||||
|
||||
|
||||
You can also see missing patches in red.
|
||||
|
||||
> Did you know? Even a single XenServer host is inside a pool!
|
||||
|
||||
## Live filter search
|
||||
|
||||
The idea is not just to provide a good search engine, but also a complete solution for managing all your XenServer infrastructure. Ideally:
|
||||
|
||||
- less clicks to see or do what you need
|
||||
- find a subset of interesting objects
|
||||
- perform bulk actions on all results found
|
||||
- sort your results for more pertinent insight
|
||||
|
||||
> Pro Tip: the URL of Xen Orchestra contains the search string, eg `home?s=power_state%3Arunning+`. You can share these URLs to your colleagues to share your search!
|
||||
|
||||
### Search examples
|
||||
|
||||
We include some predefined filters in the dropdown "Filters":
|
||||
|
||||
|
||||
|
||||
You can use custom filters here:
|
||||
|
||||
|
||||
|
||||
### Save your search
|
||||
|
||||
If you want to record your filter, just click on the "Save" icon 
|
||||
|
||||
After giving a name to your filter, you will be able to find it in the dropdown filter menu.
|
||||
|
||||
### Manage your saved search
|
||||
|
||||
Just go into your user panel (bottom of main left menu):
|
||||
|
||||
|
||||
|
||||
There, you can edit or remove any filter/search you've created!
|
||||
|
||||
### Set a default search
|
||||
|
||||
In this user section, you can set a default filter (preset filters or your own).
|
||||
|
||||
> Pro Tip: this is saved in your user preferences. It means that you can connect anywhere on any browser, and you'll still see the same behavior.
|
||||
|
||||
### Filter syntax
|
||||
|
||||
> A filter allows you to search through a collection of objects which have multiple properties and may even contain other nested objects.
|
||||
|
||||
#### Searching for a string (or substring)
|
||||
|
||||
Simply type the string, if it contains special characters just surround it with quotes:
|
||||
|
||||
- `simple-string`
|
||||
- `"string with special characters like whitespaces"`
|
||||
|
||||
> The search is recursive, case insensitive and non-anchored (i.e. matches if the pattern is contained in a string).
|
||||
|
||||
A simple string can also contain a wildcard character (`*`) to match any character in a portion of the string:
|
||||
|
||||
- `foo*bar`: matches `foobar`, `foo - bar`, etc.
|
||||
|
||||
#### Regular expression
|
||||
|
||||
For more advanced string matching, you can use regular expressions:
|
||||
|
||||
- `/^DNS server \d+$/`: matches `DNS server 1`, `DNS server 05` but not `DNS server`
|
||||
- `/foo/i`: with the `i` flag, it ignores the case, therefore it matches `Foo` and `FOO`
|
||||
|
||||
[More information about supported regular expressions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions).
|
||||
|
||||
#### Searching a specific property
|
||||
|
||||
Type the property name, followed by a colon `:` and a subfilter:
|
||||
|
||||
- `name_label:"my VM"`
|
||||
- `virtualizationMode:hvm`
|
||||
- `boot:order:cn`
|
||||
|
||||
#### Exclusion
|
||||
|
||||
Prefix your filter with an exclamation mark `!` to exclude any matching results:
|
||||
|
||||
- `!hvm`
|
||||
- `!power_state:Running` or `power_state:!Running`
|
||||
|
||||
#### Intersection
|
||||
|
||||
Simply type the filter's terms side by side:
|
||||
|
||||
- `power_state:Halted !virtualizationMode:hvm`
|
||||
|
||||
#### Grouping
|
||||
|
||||
Parentheses can be used to group terms together:
|
||||
|
||||
- `!(power_state:Running virtualizationMode:hvm)`
|
||||
|
||||
#### Union
|
||||
|
||||
Pipe `|` followed by a group of terms:
|
||||
|
||||
- `|(vm1 vm2)`
|
||||
- `power_state:|(Running suspended)`
|
||||
|
||||
#### Truthy property
|
||||
|
||||
This one is less common but can be used to check whether a property has a truth-like value (`true`, non-empty string or non-zero number).
|
||||
|
||||
Postfix the name of a property by a question mark `?`:
|
||||
|
||||
- `auto_poweron?`
|
||||
- `high_availability?`
|
||||
|
||||
#### Number comparison
|
||||
|
||||
You can use the search field/filter with number comparisons:
|
||||
|
||||
- `snapshots:length:>2` (to display VMs with more than 2 snapshots)
|
||||
- `$VBDs:length:>=4` (VMs with more 4 or more disks attached)
|
||||
- `VIFs:length:>=2` (number of network interfaces)
|
||||
|
||||
### Available properties
|
||||
|
||||
There isn't much documentation listing these (yet), but you can see all objects and their properties using `xo-cli --list-objects`. You can then use these properties for search in XOA.
|
||||
|
||||
Take a look at [the documentation](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-cli#xo-cli) for xo-cli :)
|
||||
|
||||
Example: to search by the Xen Tools status:
|
||||
|
||||
- `xenTools?`: whether the tools are installed
|
||||
- `xenTools:"up to date"`: whether they are installed and up to date
|
||||
|
||||
## VM creation
|
||||
|
||||
A new VM can be created via the "New" button in the main menu (bottom):
|
||||
|
||||
|
||||
|
||||
Or in the home view:
|
||||
|
||||
|
||||
|
||||
### Wizard
|
||||
|
||||
#### Select your Pool
|
||||
|
||||
Because Xen Orchestra can be connected to multiple pools, you must select which one you want to create your VMs on:
|
||||
|
||||
|
||||
|
||||
On which **host** the VM will actually run on will depend of various settings (local SR or not, RAM available etc.)
|
||||
|
||||
#### Infos category
|
||||
|
||||
##### Select your template
|
||||
|
||||
The next step is to select a template:
|
||||
|
||||
|
||||
|
||||
> What is a XenServer template? It can be 2 things: first an "empty" template, meaning it contains only the configuration for your future VM, such as example settings (minimum disk size, RAM and CPU, BIOS settings if HVM etc.) Or it could be a previous VM you converted into a template: in this case, creating a VM will clone the existing disks.
|
||||
|
||||
##### Name and description
|
||||
|
||||
These values can be changed anytime after your VM is created.
|
||||
|
||||
##### Multiple VMs
|
||||
|
||||
You can create multiple VMs at once by toggling the _Multiple VMs_ option. The `{name}` pattern is the "Name" field of the VM. By default, it will start with number 1 and increment up. You can change this via the "First index" field.
|
||||
|
||||
Click on the refresh icon to see the change:
|
||||
|
||||
|
||||
|
||||
#### Performance
|
||||
|
||||
This is where you can configure VM performance options: number of vCPUs, RAM, CPU weight and cap.
|
||||
|
||||
##### CPU weight and cap
|
||||
|
||||
The default CPU weight is `256` which means it will be scheduled by Xen like any other VMs on the host it runs from. If you raise it, eg with `512`, CPUs on this VM will be scheduled with twice the priority as others. If you decrease it, with `64` for example, it will be scheduled with 4 times less priority.
|
||||
|
||||
What about cap? It's the maximum amount of CPUs a VM can consume, using a 100 base (1 vCPU: 100). Default is 0 and means no upper cap.
|
||||
|
||||
> Should I mess with these settings? In general: nope. Change this only if you are sure of what are you doing. More can be found here: https://wiki.xen.org/wiki/Credit_Scheduler
|
||||
|
||||
#### Install settings
|
||||
|
||||
Depending of your template type (with existing disks or not, PV vs HVM) this panel can be changed.
|
||||
|
||||
##### HVM templates without existing disks
|
||||
|
||||
You can choose to boot from an ISO or using PXE:
|
||||
|
||||
|
||||
|
||||
##### PV templates
|
||||
|
||||
These templates will use PV configuration in order to boot: either from the right ISO or network URL. PV Args can be used to modify kernel parameters, but it's a very advanced setting you shouldn't play with.
|
||||
|
||||
##### Template with existing disks
|
||||
|
||||
Because there is already disks installed, you shouldn't have "Install settings" _per se_. But you can use our `config drive` setup if your template already has CloudInit installed!
|
||||
|
||||
Please refer to the [XenServer CloudInit section](cloudinit.md) for more.
|
||||
|
||||
#### Interfaces
|
||||
|
||||
This is the network section of the VM configuration: in general, MAC field is kept empty (autogenerated from XenServer). We also select the management network by default, but you can change it to reflect your own network configuration.
|
||||
|
||||
#### Disks
|
||||
|
||||
This section is for configuring new or existing disks (according to your selected template).
|
||||
|
||||
> Protip: avoid using large disks for your VMs. Want to store a lot of files? Use a network share for that (NFS, SMB) and keep using VMs with small system disks. It's far easier to maintain, migrate, backup and restore!
|
||||
|
||||
## VM management
|
||||
|
||||
### Live Editing
|
||||
|
||||
Any object with a dotted underline can be edited with a mouse click: VM title, description, CPU and memory.
|
||||
|
||||
|
||||
|
||||
In the advanced tab, you have extra options:
|
||||
|
||||
|
||||
|
||||
### XCP-ng/Citrix Hypervisor limitations
|
||||
|
||||
- Each VM has a maximum vCPU number. This value can't be changed while the VM is running. You can reduce the number of vCPUs, but you can't assign more than the set max. In XO, while your VM is halted, set the max vCPUs you would need, then boot it. Now you can reduce it and then expand it later to this maximum.
|
||||
- The same limitation applies to static RAM.
|
||||
|
||||
You can learn more about XenServer [resource management on the Citrix Website](https://docs.citrix.com/de-de/xencenter/6-5/xs-xc-vms-configuring/xs-xc-vms-memory/xs-xc-dmc-about.html).
|
||||
|
||||
### VDI live migration
|
||||
|
||||
Thanks to Xen Storage Motion, it's easy to move a VM disk from one storage location to another, while the VM is running! This feature can help you migrate from your local storage to a SAN, or just upgrade your SAN without any downtime.
|
||||
|
||||
To do so: Access the Xen Orchestra page for your running VM, then enter the Disk tab. Long click on the current SR of the disk, and a drop down menu will be displayed with all compatible destinations. Just select one, that's all: the migration will start live!
|
||||
|
||||
|
||||
|
||||
#### Offline VDI migration
|
||||
|
||||
Even though it's not currently supported in XenServer, we can do it in Xen Orchestra. It's exactly the same process as a running VM.
|
||||
|
||||
### VM recovery
|
||||
|
||||
In the advanced tab, use the "Recovery Start" button:
|
||||
|
||||
|
||||
|
||||
This button will allow you to boot directly from the CD drive, ignoring your current disks. Note that it works for all virtualization modes: HVM or PV.
|
||||
|
||||
### Auto power VM
|
||||
|
||||
Activating "Auto Power on" for a VM will also configure the pool accordingly. If your host is rebooted, the VM will be started right after the host is up.
|
||||
|
||||
### VM high availability (HA)
|
||||
|
||||
If you pool supports HA (must have shared storage), you can activate "HA". Read our blog post for more details on [VM high availability with XenServer](https://xen-orchestra.com/blog/xenserver-and-vm-high-availability/).
|
||||
|
||||
#### Docker management
|
||||
|
||||
> Please [read the dedicated section](docker_support.md) to install a Docker Ready VM.
|
||||
|
||||
### VM CPU priority
|
||||
|
||||
You can change the CPU Weight in the VM advanced view. The values are:
|
||||
|
||||
- Default
|
||||
- Quarter (64)
|
||||
- Half (128)
|
||||
- Normal (256)
|
||||
- Double (512)
|
||||
|
||||
By default, each VM has a weight of 256.
|
||||
|
||||
If one VM has for example, "Double", it will have double the priority on the Xen scheduler. [Read more on the official Citrix XenServer documentation](http://support.citrix.com/article/CTX117960).
|
||||
|
||||
### VM Copy
|
||||
|
||||
VM copy allows you to make an export and an import via streaming. You can target any SR in your whole XenServer infrastructure (even across different pools!)
|
||||
|
||||
### Snapshot management
|
||||
|
||||
You can create a snapshot with one click. It will be named automatically. After the snapshot is created, you can either:
|
||||
|
||||
- export it on your computer
|
||||
- revert your VM to this snapshot (it will restart the VM)
|
||||
- delete this snapshot
|
||||
|
||||
> By default, XOA will try to make a snapshot with quiesce. If the VM does not support it, it will fallback to the default snapshot system.
|
||||
|
||||
## VM import and export
|
||||
|
||||
Xen Orchestra can import and export VM's in XVA format (XenServer format) or import OVA files (OVF1 format).
|
||||
|
||||
> We support OVA import from VirtualBox. Feel free to report issues with OVA from other virtualization platforms.
|
||||
|
||||
### VM import
|
||||
|
||||
#### XVA files
|
||||
|
||||
To import an XVA file, just go to the New/Import menu:
|
||||
|
||||
|
||||
|
||||
Select the target pool and SR where the VM will be imported. Then, drag and drop your file and click on the import button.
|
||||
|
||||
#### OVA files
|
||||
|
||||
OVA files contains extra info that you need to check before importing, like name, etc.
|
||||
|
||||
|
||||
|
||||
When you are OK with these settings, just click on the "Import" button.
|
||||
|
||||
### VM export
|
||||
|
||||
> Exported VMs are in XVA format
|
||||
|
||||
Just access the page for the VM that you want to export, and click on the "Export" button in the toolbar. You'll instantly download a compressed XVA file.
|
||||
|
||||
It works even if the VM is running, because we'll automatically export a snapshot of this VM.
|
||||
|
||||
#### Snapshot export
|
||||
|
||||
In the VM "Snapshots" tab, you can also export a snapshot like you export a VM.
|
||||
|
||||
## Hosts updates
|
||||
|
||||
Patching a host manually can be time consuming (and boring). That's why we provide the high level feature of downloading and applying all missing patches automatically.
|
||||
|
||||
:::tip
|
||||
Update mechanism is different between Citrix Hypervisor and XCP-ng. However, Xen Orchestra provides a similar UI for both systems, handled entirely transparently for you!
|
||||
:::
|
||||
|
||||
### XOA smart update system
|
||||
|
||||
Your XOA will check the official Citrix servers for missing patches. They will be displayed if any:
|
||||
|
||||
- in dashboard view
|
||||
- in pool view (plus the number of missing patches in a red box)
|
||||
- in host view (in patching tab, same red pill)
|
||||
|
||||
### Installing patches
|
||||
|
||||
When you click on "Install all patches", XOA will do all of the following automatically:
|
||||
|
||||
- fetch all missing patches from Citrix servers
|
||||
- unzip them
|
||||
- upload them
|
||||
- apply them in the correct order
|
||||
|
||||
You can see more screenshots here: https://xen-orchestra.com/blog/hotfix-xs70e004-for-xenserver-7-0/
|
||||
|
||||
> 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-xenserver-updates-and-patches).
|
||||
|
||||
### Notes on patching
|
||||
|
||||
- Xen Orchestra won't reboot your hosts automatically. That's your call to choose when to do it.
|
||||
- Patching doesn't always require rebooting. Check the "Guidance" row: if "restartHost" is displayed, it means you need to reboot to have the patch fully applied (see screenshot below)
|
||||
- XO will install all patches without rebooting: that's not an issue. Even applying patches manually, **it's not mandatory to reboot after each patch**.
|
||||
|
||||
|
||||
|
||||
## Visualizations
|
||||
|
||||
Visualizations can help you to understand your XenServer infrastructure, as well as correlate events and detect bottlenecks.
|
||||
|
||||
> :construction_worker: This section needs to be completed: screenshots and how-to :construction_worker:
|
||||
|
||||
### Dashboard
|
||||
|
||||
The dashboard view gathers information on all your connected pools/hosts.
|
||||
|
||||
|
||||
|
||||
:::tip
|
||||
You can also update all your hosts (install missing patches) from this page.
|
||||
:::
|
||||
|
||||
### Parallel Coordinates
|
||||
|
||||
A Parallel Coordinates visualization helps to detect proportions in a hierarchical environment. In a XenServer environment, it's especially useful if you want to see useful information from a large amount of data.
|
||||
|
||||
|
||||
|
||||
## Health
|
||||
|
||||
This view will help you find any bottlenecks and compare the metrics of your infrastructure.
|
||||
|
||||
> :construction_worker: This section needs to be completed: screenshots and how-to :construction_worker:
|
||||
|
||||
### Heatmap
|
||||
|
||||
A heatmap allows its reader to understand when your VMs or hosts are stressed. Values are relative, thus it's easy to detect trends or spikes.
|
||||
|
||||
[](https://xen-orchestra.com/blog/xen-orchestra-4-4/#heatmapforinfrastructurehealth).
|
||||
|
||||
### Event correlation
|
||||
|
||||
This is the place to compare metrics on comparable objects (VMs to VMs, hosts to hosts).
|
||||
|
||||
[](https://xen-orchestra.com/blog/xen-orchestra-4-6#eventcorrelation).
|
||||
|
||||
## Docker support
|
||||
|
||||
This allows you to enjoy Docker containers displayed directly in Xen Orchestra.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- XenServer 6.5 or higher
|
||||
- Plugin installation (for Citrix Hypervisor, it's included in XCP-ng)
|
||||
|
||||
### Docker plugin installation
|
||||
|
||||
This first step is needed until Docker is supported natively in the XenServer API (XAPI).
|
||||
|
||||
> The plugin should be installed on every host you will be using, even if they are on the same pool.
|
||||
|
||||
#### For XenServer 6.5
|
||||
|
||||
1. SSH to your XenServer
|
||||
1. Download the plugin: `wget http://downloadns.citrix.com.edgesuite.net/10343/XenServer-6.5.0-SP1-xscontainer.iso`
|
||||
1. Install it: `xe-install-supplemental-pack XenServer-6.5.0-SP1-xscontainer.iso`
|
||||
|
||||
#### For XenServer 7.0
|
||||
|
||||
1. SSH to your XenServer
|
||||
1. Download the plugin: `wget http://downloadns.citrix.com.edgesuite.net/11621/XenServer-7.0.0-xscontainer.iso`
|
||||
1. Install it: `xe-install-supplemental-pack XenServer-7.0.0-xscontainer.iso`
|
||||
|
||||
#### For XenServer 7.1
|
||||
|
||||
1. SSH to your XenServer
|
||||
1. Download the plugin: `wget http://downloadns.citrix.com.edgesuite.net/11993/XenServer-7.1.0-xscontainer.iso`
|
||||
1. Install it: `xe-install-supplemental-pack XenServer-7.1.0-xscontainer.iso`
|
||||
|
||||
#### For XenServer 7.2
|
||||
|
||||
1. SSH to your XenServer
|
||||
1. Download the plugin: `wget http://downloadns.citrix.com.edgesuite.net/12641/XenServer-7.2.0-xscontainer.iso`
|
||||
1. Install it: `xe-install-supplemental-pack XenServer-7.2.0-xscontainer.iso`
|
||||
|
||||
That's it! You can now enjoy Docker support!
|
||||
|
||||
### Docker managed VMs
|
||||
|
||||
You can also use the XSContainer plugin to "transform" an existing VM into a "Docker" managed VM.
|
||||
|
||||
You need to have the following installed inside the VM:
|
||||
|
||||
- Docker
|
||||
- openssh-server
|
||||
- ncat
|
||||
|
||||
For Debian/Ubuntu like distro: `apt-get install docker.io openssh-server nmap`. For RHEL and derived (CentOS...): `yum install docker openssh-server nmap-ncat`.
|
||||
|
||||
To run Docker as non-root, please add the user you want inside the "Docker" group.
|
||||
|
||||
Now you need to access your host (Dom0) and use the following command:
|
||||
|
||||
```
|
||||
xscontainer-prepare-vm -v <VM_UUID> -u <username>
|
||||
```
|
||||
|
||||
:::tip
|
||||
Because "prepare-vm" is not exposed outside of the Dom0 (yet?), we can't use Xen Orchestra to give you a one-click solution as of now.
|
||||
:::
|
||||
@ -1,9 +1,5 @@
|
||||
# Metadata backup
|
||||
|
||||
> WARNING: Metadata backup is an experimental feature. Unexpected issues are possible, but unlikely.
|
||||
|
||||
## Introduction
|
||||
|
||||
XCP-ng and Citrix Hypervisor (Xenserver) hosts use a database to store metadata about VMs and their associated resources such as storage and networking. Metadata forms this complete view of all VMs available on your pool. Backing up the metadata of your pool allows you to recover from a physical hardware failure scenario in which you lose your hosts without losing your storage (SAN, NAS...).
|
||||
|
||||
In Xen Orchestra, Metadata backup is divided into two different options:
|
||||
@ -11,7 +7,7 @@ In Xen Orchestra, Metadata backup is divided into two different options:
|
||||
- Pool metadata backup
|
||||
- XO configuration backup
|
||||
|
||||
### Performing a backup
|
||||
## Performing a backup
|
||||
|
||||
In the backup job section, when creating a new backup job, you will now have a choice between backing up VMs and backing up Metadata:
|
||||
|
||||
@ -28,7 +24,7 @@ Once created, the job is displayed with the other classic jobs.
|
||||
|
||||
|
||||
|
||||
### Performing a restore
|
||||
## Performing a restore
|
||||
|
||||
> WARNING: restoring pool metadata completely overwrites the XAPI database of a host. Only perform a metadata restore if it is a new server with nothing running on it (eg replacing a host with new hardware).
|
||||
|
||||
|
||||
23
docs/project.md
Normal file
23
docs/project.md
Normal file
@ -0,0 +1,23 @@
|
||||
# Xen Orchestra project
|
||||
|
||||
Xen Orchestra is an Open Source project created by [Olivier Lambert](https://www.linkedin.com/in/olivier-lambert-22316b26/) with a long story behind it.
|
||||
|
||||
## Initial idea
|
||||
|
||||
The idea of Xen Orchestra was origally born in 2009, see the original announcement on [Xen User mailing list](https://lists.xenproject.org/archives/html/xen-users/2009-09/msg00537.html). It worked on Xen and `xend` (now deprecated).
|
||||
|
||||
## XO reboot for XenServer/XCP
|
||||
|
||||
Project was rebooted in the end of 2012, and "pushed" thanks to Lars Kurth. It's also a commercial project since 2016, and now with a team of 6 people dedicated fulltime.
|
||||
|
||||
Here is a video in LinuxCon 2013 telling the story:
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/TT2Q5l2K54k" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
## XCP-ng
|
||||
|
||||
After Citrix decided to close at lot of XenServer features, Olivier Lambert decided to fork the virtualization platform. That's why Xen Orchestra and XCP-ng team are so close. Feel free to learn more on [https://xcp-ng.org](https://xcp-ng.org).
|
||||
|
||||
## Team and contributors
|
||||
|
||||
See the [dedicated Github page](https://github.com/vatesfr/xen-orchestra/graphs/contributors) for all contributors.
|
||||
52
docs/proxy.md
Normal file
52
docs/proxy.md
Normal file
@ -0,0 +1,52 @@
|
||||
# Backup Proxy
|
||||
|
||||
A Xen Orchestra proxy is an architecture component you can deploy in an infrastructure in order to handle the data stream of your backup job.
|
||||
The most current situation in which you might wish to use a XO proxy are:
|
||||
|
||||
- To handle backup data stream in large infrastructure to avoid saturation of the main appliance and split the workload
|
||||
- To handle backup data stream in remote infrastructure to avoid useless back and forth from the main XOA to the remote location
|
||||
|
||||
|
||||
|
||||
## Deployment
|
||||
|
||||
### Prerequisites
|
||||
|
||||
To deploy Xen Orchestra proxies, you need to have an available proxy license. To purchase a license, you simply need to go on [our store](https://xen-orchestra.com/#!/member/purchaser) and follow the process.
|
||||
|
||||
### Minimum Requirements
|
||||
|
||||
XO proxies will require this ressources available:
|
||||
|
||||
- 2 vCPUs
|
||||
- 2GiB RAM
|
||||
- 20GiB disk (2GiB on thin pro SR)
|
||||
|
||||
### Installation
|
||||
|
||||
1. Go in the proxies section of your appliance
|
||||
|
||||
|
||||
|
||||
2. Deploy a proxy in your infrastructure
|
||||
|
||||
|
||||
|
||||
3. Do all the required configuration for your proxy (SR, network...)
|
||||
|
||||
|
||||
|
||||
4. If you have an available license, it will be automatically bind to your new proxy deployed.
|
||||
|
||||
## Proxy Remote creation
|
||||
|
||||
Once a proxy is deployed in your infrastructure, you can create a proxy remote using the remote form.
|
||||
|
||||
|
||||
|
||||
|
||||
## Backup job with Proxy
|
||||
|
||||
While creating a standard backup job from your main Xen Orchestra appliance, you will have the ability to select a proxy on which you want to execute the job.
|
||||
|
||||
|
||||
147
docs/purchase.md
147
docs/purchase.md
@ -1,20 +1,153 @@
|
||||
# Purchase
|
||||
|
||||
With a subscription, you'll have both Pro Support and XOA Appliance with various features (depending on XOA Edition).
|
||||
|
||||
:::tip
|
||||
To find which XOA Edition fits your needs, please read the [feature matrix page](https://xen-orchestra.com/#!/featuresmatrix) on Xen Orchestra website.
|
||||
:::
|
||||
|
||||
You can buy XOA in multiple ways, depending on your needs. Click on the following links for more documentation:
|
||||
|
||||
- [for your company (direct purchase)](directpurchase.md)
|
||||
- [through your purchase department (purchaser)](through_purchase_department.md)
|
||||
- [for your own client (reseller)](reseller.md)
|
||||
- [for your company (direct purchase)](purchase.md#direct-purchase)
|
||||
- [through your purchase department (purchaser)](purchase.md#via-your-purchase-departement)
|
||||
- [for your own client (reseller)](purchase.md#as-a-reseller)
|
||||
|
||||
## XOA Editions
|
||||
## Direct purchase
|
||||
|
||||
To find which XOA Edition fits your needs, please read the [dedicated editions page](editions.md).
|
||||
This is the easiest purchase option: you can buy XOA with your registered email account on <https://xen-orchestra.com>.
|
||||
|
||||
### Choose your edition
|
||||
|
||||
You can choose the edition you want in two places:
|
||||
|
||||
- [the pricing page](https://xen-orchestra.com/#!/pricing)
|
||||
- [your account/purchases page](https://xen-orchestra.com/#!/purchases)
|
||||
|
||||
:::tip
|
||||
You need to be logged in to make a purchase. If you don't have an account, please [register here](https://xen-orchestra.com/#!/signup).
|
||||
:::
|
||||
|
||||
From your account page, click on the purchase menu, then select the edition you need:
|
||||
|
||||
|
||||
|
||||
### Purchase options
|
||||
|
||||
The second step is to select your purchase option:
|
||||
|
||||
- Subscription: only available with a credit card payment. Choose this option for a monthly payment or a yearly payment **renewed automatically** each year.
|
||||
|
||||
- Paid period: **check or wire transfer only**. This purchase allows you to subscribe for a one, two or three year period
|
||||
|
||||
> A 2 year subscription period grants you 1 month discounted
|
||||
> A 3 year subscription period grants you 2 months discounted
|
||||
|
||||
Then you need to fill in your information and select **"Buy for my own use"** (direct purchase)
|
||||
|
||||
|
||||
|
||||
### Billing information
|
||||
|
||||
You need to complete all the required information on this page in order to move forward.
|
||||
|
||||
> Note: If you are part of the Eurozone, you will need to provide a valid EU VAT number in order to proceed to payment. Transactions between companies inside the Eurozone are VAT free.
|
||||
> Transactions outside the Eurozone are VAT free.
|
||||
|
||||
|
||||
|
||||
### Select your payment mode
|
||||
|
||||
Credit Card, Wire transfer or Bank check are the three payment methods available on our store. Some methods can be unavailable regarding the purchase option you have selected during step one.
|
||||
|
||||
> Wire transfer is not available for monthly and yearly subscription - Credit Card is not available for paid period.
|
||||
|
||||
|
||||
|
||||
> All required information for wire transfer and Check payment will be available in the last step of the payment AND on your proforma invoice.
|
||||
> ⚠ Please, use an explicit reference for your wire transfer in order for us to easily identify your payment.
|
||||
|
||||
## Via your purchase departement
|
||||
|
||||
If you can't purchase using your own account, usually because you need to go through a dedicated purchase department in your company, this is the process you need to follow.
|
||||
|
||||
Typically, you will provide two contacts:
|
||||
|
||||
- The "billing contact" (in general, the purchaser email). This account will have access to invoices. This is the account doing the purchase. Once purchased, the license needs to be bound to the second contact account, the technical contact.
|
||||
- The "technical contact", the email of the system administrator using the solution and making support requests.
|
||||
|
||||
### As "billing contact"
|
||||
|
||||
1. First of all, you need to create an account as a purchaser (eg: "purchase.dept@example.com"). Once it's done, you need to go inside the member page, in the **purchases** menu.
|
||||
|
||||
|
||||
|
||||
Now, you just have to pick the edition of Xen Orchestra you want to purchase for your IT team.
|
||||
|
||||
2. On the first payment screen, after you choose the plan and the subscription method. You can select the option "Buy for another account"
|
||||
|
||||
|
||||
|
||||
3. Once the payment is completed, you will have to bind the plan with the end-user account (technical contact). If the end-user doesn't have an account yet, the system will create one and send an e-mail to your end user.
|
||||
|
||||
|
||||
|
||||
That's it, you have now completed the purchase.
|
||||
|
||||
:::warning
|
||||
Once you have bound the plan to your end user account, you cannot change it. Double check the spelling of the e-mail before binding the account.
|
||||
:::
|
||||
|
||||
## As a reseller
|
||||
|
||||
The Xen Orchestra partner program is designed to offer you the opportunity to become a reseller of Xen Orchestra and deliver a full stack solution to your customers.
|
||||
|
||||
:::tip
|
||||
Becoming a reseller will grant you a standard discount. However, **the reseller status is designed for companies that want to actively prospect for new Xen Orchestra users**. That's why we are asking our partners to **resell Xen Orchestra at least two times a year**. If you are acting as a third party purchaser answering to a specific request from one of your customers, you don't need to apply to the reseller program - you can follow [this process](https://xen-orchestra.com/docs/through_purchase_department.html) instead.
|
||||
:::
|
||||
|
||||
### Apply to the program
|
||||
|
||||
To apply to our partner program, you can access the [partner page](https://xen-orchestra.com/#!/partner) and click on the "Register to become a partner" button:
|
||||
|
||||
|
||||
|
||||
You will have to complete a form in order to provide information regarding your expectations and location. Once you've finished, you should receive an email in order to **start the discussion with someone from our team**.
|
||||
|
||||
> It's important to answer the email - this will start the discussion with someone from our team in order to determine together if the partner status is what you really need.
|
||||
|
||||
Once we have activated your partner space, you will have the ability to access the purchasing page [at the same place](https://xen-orchestra.com/#!/partner).
|
||||
|
||||
### Purchase XOAs
|
||||
|
||||
Now that you can see the reseller interface:
|
||||
|
||||
|
||||
|
||||
You can follow these steps to purchase an XOA edition for your customer.
|
||||
|
||||
1. choose the edition you want to purchase for your customer
|
||||
2. Buy it on your reseller page (the discount is automatically applied - once it's done, a new line appears on your reseller page)
|
||||
3. assign/bind the plan to your final client email
|
||||
|
||||
You'll have all the invoices in your account.
|
||||
|
||||
### From your client's perspective
|
||||
|
||||
Your client can use the email assigned to register their appliance, and unlock the Edition you purchased. They will not get any invoices from us but can still access our support system.
|
||||
|
||||
## Invoices
|
||||
|
||||
Invoices are available in PDF format. [Details here](invoices.md).
|
||||
Invoices are available in PDF format. You can find them [in your account](https://xen-orchestra.com/#!/member).
|
||||
|
||||
## Receiving a quote
|
||||
Get in the "Invoices" tab:
|
||||
|
||||
|
||||
|
||||
:::tip
|
||||
You can download your invoice in PDF format, by clicking in the "Export" row, on the invoice name with the PDF extension.
|
||||
:::
|
||||
|
||||
## Ask for a quote
|
||||
|
||||
You can ask for an automatic quote on our website via the pricing page or directly from you personal account page.
|
||||
|
||||
|
||||
35
docs/releases.md
Normal file
35
docs/releases.md
Normal file
@ -0,0 +1,35 @@
|
||||
# Releases
|
||||
|
||||
Xen Orchestra is distributed in 2 ways:
|
||||
|
||||
1. Through XOA
|
||||
2. "as is" from GitHub
|
||||
|
||||
XOA (**X**en **O**rchestra virtual **A**ppliance) is the pre-installed VM with:
|
||||
|
||||
- everything ready to work
|
||||
- complete QA (tested) to guarantee it will work
|
||||
- a web updater
|
||||
- bundled remote support capabilities
|
||||
- extra services (XO Hub, XO Recipies, Advanced metrics, XOSAN…)
|
||||
- secured system (sudo, firewall)
|
||||
|
||||
It's really trivial to deploy it, as you can see [in the XOA install section](installation.html#xoa).
|
||||
|
||||
:::tip
|
||||
In any case, we suggest that you try XOA first, regardless your future usage. It's the easiest way to test everything!
|
||||
:::
|
||||
|
||||
## XOA updates
|
||||
|
||||
See the [updates dedicated section](updater.md) to learn how to keep your XOA up to date.
|
||||
|
||||
## Github updates
|
||||
|
||||
If you decide to install it [from the sources](installation.md#from-the-sources), please **always** try to stick to `master` as possible. Before opening any bug report or topic on the forum, update to the latest commit.
|
||||
|
||||
Because you cloned the repository on `master`, just `git pull`!
|
||||
|
||||
:::warning
|
||||
There's no community support on XO installations that aren't up to date to `master`.
|
||||
:::
|
||||
@ -1,16 +1,20 @@
|
||||
# Rolling snapshots
|
||||
|
||||
> Rolling snapshots are available since XOA 4.2
|
||||
:::warning
|
||||
Snapshots aren't really a backup, but a convenient way to rollback in time. All snapshots are on the same storage as their original disk: if you lose the original disk or storage, you'll **lose all your snapshots**. Also, they are not mutually exclusive with backups.
|
||||
|
||||
We strongly advise that you do NOT rely only on snapshots!
|
||||
:::
|
||||
|
||||
This feature is similar to Backups, but it creates a snapshot when planned to do so. It also handles the retention (removing the oldest snapshot). This feature is very convenient to rollback to a previous state.
|
||||
|
||||
**Warning**: snapshots are not backups. All snapshots are on the same storage as their original disk. If you lose the original VDI (or the SR), you'll **lose all your snapshots**.
|
||||
> :construction_worker: This section needs to be completed: screenshots and how-to :construction_worker:
|
||||
|
||||
[Read more about it](https://xen-orchestra.com/blog/xen-orchestra-4-2/#schedulerollingsnapshots).
|
||||
:::tip
|
||||
Due to space usage, rolling snapshots should be avoided for large VMs on non-thin provisioned storages.
|
||||
:::
|
||||
|
||||
> Advice: due to space usage, rolling snapshots should be avoided for large VMs on non-thin provisioned storages.
|
||||
|
||||
Example:
|
||||
## Examples
|
||||
|
||||
- Schedule a nightly snapshot for a group of VMs, let's say at 4:30 in the morning. With a max snapshot of 7, you'll have a week of revert possibility
|
||||
- Schedule a snapshot every week, but precisely Sunday at 11 PM, with 4 snapshots max. This will give you a month max of revert
|
||||
|
||||
@ -1,16 +1,22 @@
|
||||
# SDN Controller
|
||||
|
||||
> SDN Controller is available in XOA 5.36.0 and higher
|
||||
The SDN Controller enables a user to **create pool-wide and cross-pool private networks** and more. It's available as a Xen Orchestra plugin (included in XOA Premium).
|
||||
|
||||
The SDN Controller enables a user to **create pool-wide and cross-pool** (since XOA 5.38.0) **private networks**.
|
||||
## Global Private Networks
|
||||
|
||||
|
||||
Interconnect your VMs and hosts within a dedicated and secured private network, even accross different pools all around the world. This is a great way to protect "private links" (eg between applications and databases, management networks etc.) without any complicated deployment.
|
||||
|
||||
## How does it work?
|
||||
|
||||
|
||||
### How does it work?
|
||||
|
||||
Please read the [dedicated devblog on the SDN Controller](https://xen-orchestra.com/blog/xo-sdn-controller/) and its [extension for cross-pool private networks](https://xen-orchestra.com/blog/devblog-3-extending-the-sdn-controller/).
|
||||
|
||||
## Usage
|
||||
:::warning
|
||||
As VxLAN and GRE are protocols using extra encapsulation, they require extra bits on a network packet. If you create a Global Private Network with a default MTU at `1500`, you won't be able to use it "as is" in your VMs, unless you configure a smaller MTU for each virtual interface, in your VM operating system (eg: `1400`).
|
||||
|
||||
If you want something entirely transparent for your VMs, then you'll need to create a network with a MTU of `1546` for GRE or `1550` for VxLAN. However, larger MTU will require capable network equipements.
|
||||
:::
|
||||
|
||||
### Network creation
|
||||
|
||||
@ -26,11 +32,14 @@ In the network creation view:
|
||||
- Create the network
|
||||
- Have fun! ☺
|
||||
|
||||
**_NB:_**
|
||||
|
||||
|
||||
:::tip
|
||||
|
||||
- All hosts in a private network must be able to reach the other hosts' management interface.
|
||||
> The term ‘management interface’ is used to indicate the IP-enabled NIC that carries the management traffic.
|
||||
- Only 1 encrypted GRE network and 1 encrypted VxLAN network per pool can exist at a time due to Open vSwitch limitation.
|
||||
:::
|
||||
|
||||
### Configuration
|
||||
|
||||
@ -43,7 +52,7 @@ The plugin's configuration contains:
|
||||
If none is provided, the plugin will create its own self-signed certificates.
|
||||
- `override-certs`: Enable to uninstall the existing SDN controller CA certificate in order to replace it with the plugin's one.
|
||||
|
||||
## Requirements
|
||||
### Requirements
|
||||
|
||||
### VxLAN
|
||||
|
||||
@ -61,3 +70,9 @@ The plugin's configuration contains:
|
||||
- `systemctl enable openvswitch-ipsec`
|
||||
- `systemctl start ipsec`
|
||||
- `systemctl start openvswitch-ipsec`
|
||||
|
||||
## OpenFlow rules
|
||||
|
||||
:::tip
|
||||
This feature is about to be released soon. Stay tuned!
|
||||
:::
|
||||
|
||||
@ -1,6 +1,10 @@
|
||||
# Support
|
||||
|
||||
Xen Orchestra will run in a controlled/tested environment thanks to XOA ([Xen Orchestra virtual Appliance](https://xen-orchestra.com/#!/xoa)). **This is the way to get pro support**. Any account with a registered XOA can access a [dedicated support panel](https://xen-orchestra.com/#!/member/support).
|
||||
:::tip
|
||||
See the dedicated sub-section to read more about [XOA support and usage](xoa.md).
|
||||
:::
|
||||
|
||||
Xen Orchestra will run in a controlled/tested environment thanks to XOA ([Xen Orchestra virtual Appliance](https://xen-orchestra.com/#!/xoa)). **This is the only way to get pro support**. Any account with a registered XOA can access a [dedicated support panel](https://xen-orchestra.com/#!/member/support).
|
||||
|
||||
XOA is available in multiple plans:
|
||||
|
||||
@ -11,23 +15,16 @@ XOA is available in multiple plans:
|
||||
|
||||
Higher tier support plans include faster ticket response times (and cover more features). Paid support plans and response times are based on the plan you have, plans can be [reviewed here](https://xen-orchestra.com/#!/xo-pricing).
|
||||
|
||||
:::tip
|
||||
If you have a subscription (or at least a registered free XOA), you can open a ticket describing your issue directly from your [personal account page here](https://xen-orchestra.com/#!/member/support)
|
||||
:::
|
||||
|
||||
## XOA Free support
|
||||
|
||||
With the free version of the Xen Orchestra Appliance (XOA free), you can open support tickets and we will do our best to assist you, however, this support is limited and is not guaranteed in regards to response times or resolutions offered.
|
||||
With the free version of the Xen Orchestra Appliance (XOA free), **you can open private support tickets** and we will do our best to assist you, however, this support is limited and is not guaranteed in regards to response times or resolutions offered.
|
||||
|
||||
## Community support
|
||||
|
||||
If you are using Xen Orchestra via the source and not XOA, you can ask questions and try to recieve help through a number of different ways:
|
||||
|
||||
- In our [forum](https://xcp-ng.org/forum/category/12/xen-orchestra)
|
||||
- In our IRC - `#xen-orchestra` on `Freenode`
|
||||
|
||||
We encourage you to give back to the community by assisting other users via these two avenues as well.
|
||||
|
||||
Lastly while Xen Orchestra is free and Open Source software, supporting and developing it takes a lot of effort. If you are considering using Xen Orchestra in production, please subscribe for one of our [professional support plans](https://xen-orchestra.com/#!/xo-pricing).
|
||||
|
||||
> Note: support from the sources is harder, because Xen Orchestra can potentially run on any Linux distro (or even FreeBSD and Windows!). Always try to double check that you followed our guide on how to [install it from the sources](https://xen-orchestra.com/docs/from_the_sources.html) before going further.
|
||||
|
||||
## Open a ticket
|
||||
|
||||
If you have a subscription (or at least a registered free XOA), you can open a ticket describing your issue directly from your personal account page [here](https://xen-orchestra.com/#!/member/support)
|
||||
Read more in the [dedicated section for community support](community.md).
|
||||
|
||||
57
docs/supported_hosts.md
Normal file
57
docs/supported_hosts.md
Normal file
@ -0,0 +1,57 @@
|
||||
# Host Compatibility List
|
||||
|
||||
This section lists all supported hosts where Xen Orchestra can connect to.
|
||||
|
||||
Xen Orchestra is designed to work exclusively on [XCP-ng](https://xcp-ng.org/) and [Citrix Hypervisor](https://www.citrix.com/products/citrix-hypervisor/) (formerly XenServer).
|
||||
|
||||
Xen Orchestra should be fully functional with any version of these two virtualization platforms. However, to benefit from the best support quality, our product is tested to work the best with the versions displayed with a ✅.
|
||||
|
||||
### Legend
|
||||
|
||||
- ✅ Full support
|
||||
- 🚀 All extra features (eg: RAM enabled backup)
|
||||
- ❗ Virtualization platform without security updates anymore (upgrade your hosts!)
|
||||
- ❎ Not all XO features supported
|
||||
|
||||
## XCP-ng
|
||||
|
||||
:::tip
|
||||
Xen Orchestra and XCP-ng are mainly edited by the same company ([Vates](https://vates.fr)). That's why you are sure to have the best compatibility with both XCP-ng and XO!
|
||||
:::
|
||||
|
||||
- XCP-ng 8.1 ✅ 🚀
|
||||
- XCP-ng 8.0 ✅
|
||||
- XCP-ng 7.6 ✅ ❗
|
||||
- XCP-ng 7.5 ✅ ❗
|
||||
- XCP-ng 7.4 ✅ ❗
|
||||
|
||||
:::tip
|
||||
We strongly suggest people to keep using the latest XCP-ng version as far as possible (or N-1).
|
||||
:::
|
||||
|
||||
## Citrix Hypervisor (formerly XenServer)
|
||||
|
||||
Backup restore for large VM disks (>1TiB usage) is [broken on old XenServer versions](https://bugs.xenserver.org/browse/XSO-868) (except 7.1 LTS up-to-date and superior to 7.6).
|
||||
|
||||
- Citrix Hypervisor 8.1 ✅
|
||||
- Citrix Hypervisor 8.0 ✅
|
||||
- XenServer 7.6 ✅ ❗
|
||||
- XenServer 7.5 ✅ ❗
|
||||
- [VDI I/O error](https://bugs.xenserver.org/browse/XSO-873), waiting for Citrix to release our fix
|
||||
- XenServer 7.4 ✅ ❗
|
||||
- XenServer 7.3 ✅ ❗
|
||||
- XenServer 7.2 ✅ ❗
|
||||
- XenServer 7.1 LTS ✅
|
||||
- XenServer 7.0 ✅ ❗
|
||||
- XenServer 6.5 ✅ ❗
|
||||
- Random Delta backup issues
|
||||
- XenServer 6.1 and 6.2 ❎ ❗
|
||||
- No Delta backup and CR support
|
||||
- XenServer 5.x ❎ ❗
|
||||
- Basic administration features only
|
||||
|
||||
## Others
|
||||
|
||||
If you installed Xen hypervisor from your usual Linux distribution, it won't work. Xen Orchestra is **agent-less** and communicate to the host directly using XAPI toolstack. Without this toolstack, it's not possible to make Xen and XO communicate.
|
||||
|
||||
See more details in [architecture section](architecture.md).
|
||||
@ -2,17 +2,21 @@
|
||||
|
||||
This page recaps the actions you can perform if you have any problems with your XOA.
|
||||
|
||||
## XOA deploy error
|
||||
:::warning
|
||||
If you have issues with XO installed from GitHub (not XOA), [please go to the dedicated section first!](community.md).
|
||||
:::
|
||||
|
||||
## Deploy error
|
||||
|
||||
> Auto deploy failed. - No SR specified and Pool default SR is null
|
||||
|
||||
It means you don't have a default SR set on the pool you are importing XOA on. To set a default SR, you must first find the SR UUID you want, with `xe sr-list`. When you have the UUID, you can set the default SR with: `xe pool-param-set uuid=<pool-uuid> default-SR=<sr-uuid>`. For the pool UUID, just press tab after `xe pool-param-set uuid=` and it will autofill your pool UUID. When this is done, re-enter the deploy script command and it will work!
|
||||
|
||||
## XOA unreachable after boot
|
||||
## Unreachable after boot
|
||||
|
||||
XOA uses HVM mode. If your physical host doesn't support virtualization extensions, XOA won't work. To check if your XenServer supports hardware assisted virtualization (HVM), you can enter this command in your host: `grep --color vmx /proc/cpuinfo`. If you don't have any result, it means XOA won't work on this hardware.
|
||||
|
||||
## Recover XOA Web-UI login password
|
||||
## Recover web login password
|
||||
|
||||
If you have lost your password to log in to the XOA webpage, you can reset it. From the XOA CLI (for login/access info for the CLI, [see here](xoa.md#first-console-connection)), use the following command and insert the email/account you wish to recover:
|
||||
|
||||
@ -26,7 +30,7 @@ This happens when your antivirus or firewall is blocking the websocket protocol.
|
||||
|
||||
The solution is to use **HTTPS**. When doing so, websockets will be encapsulated in the secured protocol, avoiding interception from your firewall or antivirus system.
|
||||
|
||||
## XOA migration issues
|
||||
## Migration issues
|
||||
|
||||
By default, XOA has a static max memory set to 16GiB. Sometimes you can have trouble migrating with this error message:
|
||||
|
||||
@ -38,7 +42,7 @@ Internal error: Xenops_interface.Internal_error("Domain.Xenguest_failure(\"Error
|
||||
|
||||
In this case, it means you need to reduce the static max memory field to a lower value, and try again.
|
||||
|
||||
## XOA boot issues
|
||||
## Boot issues
|
||||
|
||||
XOA is configured in HVM. It means you need hardware that supports HVM instructions (almost all hardware since 2011). If that's not the case, the symptom is this:
|
||||
|
||||
@ -47,7 +51,7 @@ XOA is configured in HVM. It means you need hardware that supports HVM instructi
|
||||
|
||||
Please check that you have enabled virtualization settings in your BIOS or upgrade your hardware.
|
||||
|
||||
## XOA configuration
|
||||
## Configuration
|
||||
|
||||
XOA is a virtual appliance running Debian with Xen Orchestra installed. If you have any problems, the first thing to do is to use our check service by running the `xoa check` command in a terminal:
|
||||
|
||||
@ -90,14 +94,18 @@ FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memo
|
||||
1: node::Abort() [node]
|
||||
```
|
||||
|
||||
In that case, you need to increase the memory allocated to the XOA VM (from 2GB to 4GB or 8GB). Note that simply increasing the RAM for the VM is not enough. You must also edit the service file (`/etc/systemd/system/xo-server.service`) to increase the memory allocated to the xo-server process itself.
|
||||
In that case, you need to increase the memory allocated to the XOA VM (from 2GB to 4GB or 8GB). Note that simply increasing the RAM for the VM is not enough. You must also edit the service file (`/etc/systemd/system/xo-server.service`) to increase the memory allocated to the xo-server process itself.
|
||||
|
||||
:::tip
|
||||
You should leave ~512MB for the debian OS itself. Meaning if your VM has 4096MB total RAM, you should use `3584` for the memory value below.
|
||||
|
||||
**Note:** you should leave ~512MB for the debian OS itself. Meaning if your VM has 4096MB total RAM, you should use `3584` for the memory value below.
|
||||
```diff
|
||||
- ExecStart=/usr/local/bin/xo-server
|
||||
+ ExecStart=/usr/local/bin/node --max-old-space-size=3584 /usr/local/bin/xo-server
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
The last step is to refresh and restart the service:
|
||||
|
||||
```
|
||||
@ -134,7 +142,7 @@ $ openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -nodes -
|
||||
$ systemctl restart xo-server.service
|
||||
```
|
||||
|
||||
## XO Configuration
|
||||
## Configuration
|
||||
|
||||
The system logs are visible by using this command:
|
||||
|
||||
@ -153,7 +161,7 @@ If you have ghost tasks accumulating in your Xen Orchestra you can try the follo
|
||||
1. restart the XenAPI Toolstack of the XenServer master
|
||||
1. restart xo-server
|
||||
|
||||
### Redownload and rebuild all the packages
|
||||
### Redownload and rebuild
|
||||
|
||||
If a package disappears due to a build problem or human error, you can redownload them using the updater:
|
||||
|
||||
@ -162,7 +170,7 @@ If a package disappears due to a build problem or human error, you can redownloa
|
||||
|
||||
> We'll have a `xoa-updater --force-reinstall` option soon, to do this automatically
|
||||
|
||||
### Reset XO configuration
|
||||
### Reset configuration
|
||||
|
||||
If you have problems with your `xo-server` configuration, you can reset the database. **This operation will delete all your configured users and servers, plus any backup jobs**:
|
||||
|
||||
|
||||
@ -1,10 +1,12 @@
|
||||
# Updater
|
||||
# Updates
|
||||
|
||||
The updater is the central piece that keeps your XO Appliance running the latest Xen Orchestra code.
|
||||
All updates are pushed through the updater, which is the central piece that keeps your XO Appliance running the latest Xen Orchestra code.
|
||||
|
||||
It also allows you to change your current version into another (Trial, Starter, Enterprise or Premium) **without downloading a new XOA**.
|
||||
It also allows you to change your current version into another (Free, Starter, Enterprise or Premium) **without downloading a new XOA**.
|
||||
|
||||
> By design, the updater is only available in XOA. If you are using XO from the sources, you'll have to use `git` commands and rebuild to keep up.
|
||||
:::tip
|
||||
By design, the updater is only available in XOA. If you are using XO from the sources, you'll have to use `git` commands and rebuild to keep up.
|
||||
:::
|
||||
|
||||
## Requirements
|
||||
|
||||
@ -40,29 +42,30 @@ However, if you want to start a manual check, you can do it by clicking on the "
|
||||
|
||||
|
||||
|
||||
#### Release channel
|
||||
### Release channel
|
||||
|
||||
In Xen Orchestra, you can make a choice between two different release channels.
|
||||
|
||||
##### Stable
|
||||
#### Stable 
|
||||
|
||||
The stable channel is intended to be a version of Xen Orchestra that is already **one month old** (and therefore will benefit from one month of community feedback and various fixes). This way, users more concerned with the stability of their appliance will have the option to stay on a slightly older (and tested) version of XO (still supported by our pro support).
|
||||
|
||||
##### Latest
|
||||
#### Latest 
|
||||
|
||||
The latest channel will include all the latest improvements available in Xen Orchestra. The version available in latest has already been QA'd by our team, but issues may still occur once deployed in vastly varying environments, such as our user base has.
|
||||
|
||||
> To select the release channel of your choice, go to the XOA > Updates view.
|
||||
|
||||
:::tip
|
||||
To select the release channel of your choice, go to the XOA > Updates view:
|
||||
|
||||
:::
|
||||
|
||||
#### Upgrade
|
||||
### Upgrade
|
||||
|
||||
If a new version is found, you'll have an upgrade button and its tooltip displayed:
|
||||
|
||||
|
||||
|
||||
#### Proxy configuration
|
||||
### Proxy configuration
|
||||
|
||||
If you are behind a proxy, you can edit your proxy settings in this panel:
|
||||
|
||||
|
||||
0
docs/updates.md
Normal file
0
docs/updates.md
Normal file
271
docs/users.md
Normal file
271
docs/users.md
Normal file
@ -0,0 +1,271 @@
|
||||
# Users
|
||||
|
||||
:::tip
|
||||
For system users (in XOA), please refer to [XOA section](xoa.md). Here, we are only talking about users in Xen Orchestra application
|
||||
:::
|
||||
|
||||
There are 2 types of XO users:
|
||||
|
||||
- **admins**, with all rights on all connected resources
|
||||
- **users**, with no rights by default
|
||||
|
||||
## Authentication
|
||||
|
||||
Xen Orchestra supports various types of user authentication, internal or even external thanks to the usage of the [Passport library](http://passportjs.org/).
|
||||
|
||||
:::tip
|
||||
Any account created by an external authentication process (LDAP, SSO...) will be a **user** without any permission.
|
||||
Also, you don't have to create an external user by yourself: it will be created automatically in Xen Orchestra after its first connection.
|
||||
:::
|
||||
|
||||
### Built-in
|
||||
|
||||
This is the default method. Creating a user is very simple:
|
||||
|
||||
1. Go into the Settings view, select "Users"
|
||||
2. You can create a _user_ or an _admin_, with their password (or generate one)
|
||||
|
||||
|
||||
|
||||
By default, a _user_ won't have any permissions. At the opposite, an _admin_ will have all rights.
|
||||
|
||||
### LDAP
|
||||
|
||||
XO currently supports connections to LDAP directories, like _Open LDAP_ or _Active Directory_.
|
||||
|
||||
To configure your LDAP, you need to go into the _Plugins_ section in the "Settings" view. Then configure it:
|
||||
|
||||
|
||||
|
||||
Don't forget to save the configuration, and also check if the plugin is activated (green button on top).
|
||||
|
||||
#### Filters
|
||||
|
||||
LDAP Filters allow you to properly match your user. It's not an easy task to always find the right filter, and it entirely depends on your LDAP configuration. Still, here is a list of common filters:
|
||||
|
||||
- `'(uid={{name}})'` is usually the default filter for _Open LDAP_
|
||||
- `'(cn={{name}})'`, `'(sAMAccountName={{name}})'`, `'(sAMAccountName={{name}}@<domain>)'` or even `'(userPrincipalName={{name}})'` are widely used for _Active Directory_. Please check with your AD Admin to find the right one.
|
||||
|
||||
After finishing the configuration, you can try to log in with your LDAP username and password. Finally, right after your initial successful log in, your account will be visible in the user list of Xen Orchestra.
|
||||
|
||||
### SAML
|
||||
|
||||
This plugin allows SAML users to authenticate to Xen-Orchestra.
|
||||
|
||||
The first time a user signs in, XO will create a new XO user with the same identifier.
|
||||
|
||||
#### Configuration
|
||||
|
||||
In the "Settings" then "Plugins" view, expand the SAML plugin configuration. Then provide the needed fields:
|
||||
|
||||
|
||||
|
||||
Save the configuration and then activate the plugin (button on top).
|
||||
|
||||
> Important: When registering your instance to your identity provider,
|
||||
> you must configure its callback URL to
|
||||
> `http://xo.example.net/signin/saml/callback`!
|
||||
|
||||
### GitHub
|
||||
|
||||
This plugin allows GitHub users to authenticate to Xen-Orchestra.
|
||||
|
||||
The first time a user signs in, XO will create a new XO user with the same identifier, without any permissions.
|
||||
|
||||
First you need to configure a new app in your GitHub account:
|
||||
|
||||
|
||||
|
||||
When you get your `clientID` and your `clientSecret`, you can configure them in the GitHub Plugin inside the "Settings/Plugins" view of Xen Orchestra.
|
||||
|
||||
Be sure to activate the plugin after you save the configuration (button on top). When it's done, you'll see a link in the login view, this is where you'll go to authenticate:
|
||||
|
||||
|
||||
|
||||
### Google
|
||||
|
||||
This plugin allows Google users to authenticate to Xen-Orchestra.
|
||||
|
||||
The first time a user signs in, XO will create a new XO user with the same identifier, without any permissions.
|
||||
|
||||
#### Creating the Google project
|
||||
|
||||
[Create a new project](https://console.developers.google.com/project):
|
||||
|
||||
|
||||
|
||||
Enable the Google+ API:
|
||||
|
||||
|
||||
|
||||
Add OAuth 2.0 credentials:
|
||||
|
||||
|
||||
|
||||
|
||||
#### Configure the XO plugin
|
||||
|
||||
In Settings, then Plugins, expand the Google plugin detail and provide:
|
||||
|
||||
- a `clientID` e.g `326211154583-nt2s112d3t7f4f1hh49oo9164nivvbnu.apps.googleusercontent.com`
|
||||
- a `clientSecret`, e.g `HTDb8I4jXiLRMaRL15qCffQ`
|
||||
- the `callbackURL`, e.g `http://xo.company.net/signin/google/callback`
|
||||
|
||||
|
||||
|
||||
Be sure to activate the plugin after you save the configuration (button on top).
|
||||
|
||||
You can now connect with your Google account in the login page.
|
||||
|
||||
## ACLs
|
||||
|
||||
:::tip
|
||||
ACLs are permissions that apply to pre-existing objects. Only a super admin (XO administrator) can create objects.
|
||||
:::
|
||||
|
||||
ACLs are the permissions for your users or groups. The ACLs view can be accessed in the "Settings" panel.
|
||||
|
||||
1. Select the user or group you want to apply permissions on
|
||||
2. Select the object on which the permission will apply
|
||||
3. Choose the role for this ACL
|
||||
4. Click on "Create"
|
||||
|
||||
|
||||
|
||||
> Pro tip: you can click to add multiple objects at the same time!
|
||||
|
||||
Your ACL is now available in the right list:
|
||||
|
||||
|
||||
|
||||
You can edit/remove existing ACLs here.
|
||||
|
||||
### Roles
|
||||
|
||||
There are 3 different roles for your users:
|
||||
|
||||
- Admin
|
||||
- Operator
|
||||
- Viewer
|
||||
|
||||
#### Admin
|
||||
|
||||
An object admin can do everything on it, even destroy it. E.g with its admin VM:
|
||||
|
||||
- remove it
|
||||
- migrate it (to a host with admin permission on it)
|
||||
- modify the VM resources, name and description
|
||||
- clone it
|
||||
- copy it
|
||||
- convert it into a template
|
||||
- snapshot it (even revert from a snapshot)
|
||||
- export it
|
||||
- attach/add visible disks
|
||||
- same for network cards
|
||||
|
||||
#### Operator
|
||||
|
||||
An operator can make everyday operations on assigned objects. E.g on a VM:
|
||||
|
||||
- eject a CD
|
||||
- insert a CD (if he can view the ISO storage repository)
|
||||
- start, restart, shutdown, suspend/resume it
|
||||
|
||||
All other operations are forbidden.
|
||||
|
||||
#### Viewer
|
||||
|
||||
A viewer can only see the VM state and its metrics. That's all!
|
||||
|
||||
### Inheritance
|
||||
|
||||
Objects have a hierarchy: a Pool contains all its hosts, containing itself all its VMs.
|
||||
|
||||
If you give a _view_ permission to a user (or a group) on a pool, he will automatically see all the objects inside this pool (SRs, hosts, VMs).
|
||||
|
||||
### Examples
|
||||
|
||||
#### Allow a user to install an OS
|
||||
|
||||
If the OS install needs an ISO, you need to give this user 2 permissions:
|
||||
|
||||
- _Operate_ on the VM (e.g to start it)
|
||||
- _View_ on the ISO Storage containing the needed ISO.
|
||||
|
||||
## Self-service portal
|
||||
|
||||
The self-service feature allows users to create new VMs. This is different from delegating existing resources (VM's) to them, and it leads to a lot of possibilities.
|
||||
|
||||
### Set of resources
|
||||
|
||||
To create a new set of resources to delegate, go to the "Self Service" section in the main menu:
|
||||
|
||||
|
||||
|
||||
#### Create a set
|
||||
|
||||
> Only an admin can create a set of resources
|
||||
|
||||
To allow people to create VMs as they want, we need to give them a _part_ of your XenServer resources (disk space, CPUs, RAM). You can call this "general quotas" if you like. But you first need to decide which resources will be used.
|
||||
|
||||
In this example below, we'll create a set called **"sandbox"** with:
|
||||
|
||||
- "devs" is the group that can use this set (all users in the group)
|
||||
- "Lab Pool" is the pool where they can play
|
||||
- "Debian 8 Cloud Ready" is the only template they can use
|
||||
- "SSD NFS" is the only SR where they can create VMs
|
||||
- "Pool-wide network with eth0" is the only available network for them
|
||||
|
||||
|
||||
|
||||
As you can see, only compatible hosts are shown and can be used for this resource set (hosts in another pool aren't shown). This way, you can be sure to have resources free for tasks other than self-service.
|
||||
|
||||
> Don't forget to add an ISO SR to allow your users to install VMs with CD if necessary
|
||||
|
||||
##### Quotas
|
||||
|
||||
Then, you can define quotas on this set:
|
||||
|
||||
- max vCPUs
|
||||
- max RAM
|
||||
- max disk usage
|
||||
|
||||
> Note: Snapshotting a VM within a self-service will _not_ use the quota from the resource set. The same rule applies for backups and replication.
|
||||
|
||||
When you click on create, you can see the resource set and remove or edit it:
|
||||
|
||||
|
||||
|
||||
### Usage (user side)
|
||||
|
||||
As soon as a user is granted a resource set, it displays a new button in their main view: "new".
|
||||
|
||||
|
||||
|
||||
Now, the user can create a VM with only the resources granted in the set:
|
||||
|
||||
|
||||
|
||||
And the recap before creation:
|
||||
|
||||
|
||||
|
||||
If the "Create" button is disabled, it means the user requested more resources than available.
|
||||
|
||||
Finally, if a user has been granted access to multiple resource sets, they can be switched in the top right of the screen.
|
||||
|
||||
### Toward the Cloud
|
||||
|
||||
Self-service is a major step in the Cloud. Combine it with our [Cloudinit compatible VM creation](cloudinit.md) for a full experience:
|
||||
|
||||
- create a Cloud ready template
|
||||
- create a set and put Cloud templates inside
|
||||
- delegate this set to a group of users
|
||||
|
||||
Now, your authorized users can create VMs with their SSH keys, grow template disks if needed, etc. Everything is inside a "sandbox" (the resource set) you defined earlier!
|
||||
|
||||
|
||||
|
||||
## Debugging
|
||||
|
||||
If you can't log in, please check the logs of `xo-server` while you attempt to connect. It will give you hints about the error encountered. You can do that with a `tail -f /var/log/syslog -n 100` on your XOA.
|
||||
160
docs/xoa.md
160
docs/xoa.md
@ -1,89 +1,26 @@
|
||||
# XOA
|
||||
# XOA Support
|
||||
|
||||
XOA is the Xen Orchestra Appliance. XOA is a Debian VM with:
|
||||
This is the section dedicated to all XOA details and how to get support on it.
|
||||
|
||||
- Xen Orchestra already installed (nothing to do!)
|
||||
- Tested with all bundled dependencies (QA)
|
||||
- The web updater (update in one click)
|
||||
- Support (+SSH support, tooling)
|
||||
- Secured system (sudo, firewall)
|
||||
|
||||
## Specifications
|
||||
|
||||
By default, the VM is configured with:
|
||||
|
||||
- 2 vCPUs
|
||||
- 2GB of RAM
|
||||
- 15GB of disk (10GB for `/` and 5GB for `/var`)
|
||||
|
||||
For use on huge infrastructure (more than 500+ VMs), feel free to increase the RAM.
|
||||
|
||||
## Deployment
|
||||
|
||||
### The quickest way
|
||||
|
||||
The **fastest and most secure way** to install Xen Orchestra is to use our web deploy page. Go to https://xen-orchestra.com/#!/xoa and follow the instructions.
|
||||
|
||||
> **Note:** no data will be sent to our servers, the deployment only runs between your browser and your host!
|
||||
|
||||
|
||||
|
||||
### Via a bash script
|
||||
|
||||
Alternatively, you can deploy it by connecting to your XenServer host and executing the following:
|
||||
|
||||
```
|
||||
curl -sS https://xoa.io/deploy | bash
|
||||
```
|
||||
|
||||
> **Note 1:** This won't write or modify anything on your XenServer host: it will just import the XOA VM into your default storage repository.
|
||||
|
||||
> **Note 2:** If you are using an old XenServer version, you may get a `curl` error:
|
||||
>
|
||||
> ```
|
||||
> curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
|
||||
> ```
|
||||
>
|
||||
> It means that the secure HTTPS protocol is not supported, you can bypass this using the unsecure command instead:
|
||||
>
|
||||
> ```
|
||||
> curl -sS http://xoa.io/deploy | bash
|
||||
> ```
|
||||
|
||||
Follow the instructions:
|
||||
|
||||
- Your IP configuration will be requested: it's set to **DHCP by default**, otherwise you can enter a fixed IP address (eg `192.168.0.10`)
|
||||
- If DHCP is selected, the script will continue automatically. Otherwise a netmask, gateway, and DNS server should be provided.
|
||||
- XOA will be deployed on your default storage repository. You can move it elsewhere anytime after.
|
||||
|
||||
### Via a manual XVA download
|
||||
|
||||
You can also download XOA from xen-orchestra.com in an XVA file. Once you've got the XVA file, you can import it with `xe vm-import filename=xoa_unified.xva` or via XenCenter.
|
||||
|
||||
After the VM is imported, you just need to start it with `xe vm-start vm="XOA"` or with XenCenter.
|
||||
|
||||
## First Login
|
||||
|
||||
Once you have started the VM, you can access the web UI by putting the IP you configured during deployment into your web browser. If you did not configure an IP or are unsure, try one of the following methods to find it:
|
||||
|
||||
- Run `xe vm-list params=name-label,networks | grep -A 1 XOA` on your host
|
||||
- Check your router's DHCP leases for an `xoa` lease
|
||||
|
||||
**Note:** The default Web UI credentials are `admin@admin.net` / `admin`
|
||||
|
||||
## Registration
|
||||
|
||||
**The first thing** you need to do with your XOA is register. [Read the documentation on the page dedicated to the updater/register inferface](updater.md).
|
||||
:::tip
|
||||
As a XOA user, you can open tickets in your support panel: <https://support.vates.fr/>.
|
||||
:::
|
||||
|
||||
## Technical Support
|
||||
|
||||
In your appliance, you can access the support section in the XOA menu. In this section you can:
|
||||
XOA is the only way to get our pro support, which is available remotely via SSH and a special tunnel.
|
||||
|
||||
- launch an `xoa check` command
|
||||
### XOA Check
|
||||
|
||||
XOA check is a way to test if you XOA is correctly configured. It should be the first thing to do if you have any problem!
|
||||
|
||||
To run this check, in the web UI, you can access the support section in the XOA menu. In this section you can launch an `xoa check` command:
|
||||
|
||||
|
||||
|
||||
- Open a secure support tunnel so our team can remotely investigate
|
||||
### Support tunnel
|
||||
|
||||
Open a secure support tunnel so our team can remotely investigate on your XOA. For that, we need to get the "support ID". See below:
|
||||
|
||||
|
||||
|
||||
@ -101,9 +38,64 @@ Give this id to the support: 40713
|
||||
|
||||
Give us this number, and we'll be able to access your XOA in a secure manner. Then, close the tunnel with `Ctrl+C` after your issue has been solved by support.
|
||||
|
||||
> The tunnel utilizes the user `xoa-support`. If you want to deactivate this bundled user, you can run `chage -E 0 xoa-support`. To re-activate this account, you must run `chage -E 1 xoa-support`.
|
||||
:::tip
|
||||
The user `xoa-support` is used by the tunnel. If you want to deactivate this bundled user, you can run `chage -E 0 xoa-support`. To re-activate this account, you must run `chage -E 1 xoa-support`.
|
||||
:::
|
||||
|
||||
### First console connection
|
||||
## XOA VM Specifications
|
||||
|
||||
By default, the VM is configured with:
|
||||
|
||||
- 2 vCPUs
|
||||
- 2GiB of RAM
|
||||
- 20GiB of free SR space (2GiB on thin pro SR)
|
||||
|
||||
For use on huge infrastructure (more than 500+ VMs), feel free to increase the RAM.
|
||||
|
||||
## Alternative install
|
||||
|
||||
Please only use this if you have issues with [the default way to deploy XOA](installation.html#xoa).
|
||||
|
||||
### Via a bash script
|
||||
|
||||
Alternatively, you can deploy it by connecting to your XenServer host and executing the following:
|
||||
|
||||
```
|
||||
curl -sS https://xoa.io/deploy | bash
|
||||
```
|
||||
|
||||
:::tip
|
||||
This won't write or modify anything on your XenServer host: it will just import the XOA VM into your default storage repository.
|
||||
:::
|
||||
|
||||
:::warning
|
||||
If you are using an old XenServer version, you may get a `curl` error:
|
||||
|
||||
```
|
||||
curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
|
||||
```
|
||||
|
||||
It means that the secure HTTPS protocol is not supported, you can bypass this using the unsecure command instead:
|
||||
|
||||
```
|
||||
curl -sS http://xoa.io/deploy | bash
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
Follow the instructions:
|
||||
|
||||
- Your IP configuration will be requested: it's set to **DHCP by default**, otherwise you can enter a fixed IP address (eg `192.168.0.10`)
|
||||
- If DHCP is selected, the script will continue automatically. Otherwise a netmask, gateway, and DNS server should be provided.
|
||||
- XOA will be deployed on your default storage repository. You can move it elsewhere anytime after.
|
||||
|
||||
### Via a manual XVA download
|
||||
|
||||
You can also download XOA from xen-orchestra.com in an XVA file. Once you've got the XVA file, you can import it with `xe vm-import filename=xoa_unified.xva` or via XenCenter.
|
||||
|
||||
After the VM is imported, you just need to start it with `xe vm-start vm="XOA"` or with XenCenter.
|
||||
|
||||
## First console connection
|
||||
|
||||
If you connect via SSH or console, the default credentials are:
|
||||
|
||||
@ -177,7 +169,7 @@ Administrator. It usually boils down to these three things:
|
||||
|
||||
```
|
||||
|
||||
### Network configuration
|
||||
## Network configuration
|
||||
|
||||
XOA uses **DHCP** by default, so if you need to configure the IP address, please run the command `xoa network static`. It will ask you network details:
|
||||
|
||||
@ -195,7 +187,7 @@ You can access the VM console through XenCenter or using VNC through a SSH tunne
|
||||
|
||||
If you want to go back in DHCP, just run `xoa network dhcp`
|
||||
|
||||
### Firewall
|
||||
## Firewall
|
||||
|
||||
By default XOA is firewalled, with only ports 22, 80 and 443 opened. You can see the current status of the firewall using the `sudo ufw status verbose` command:
|
||||
|
||||
@ -219,11 +211,13 @@ To Action From
|
||||
|
||||
If you want to open or close ports, please check the [documentation of UFW](https://help.ubuntu.com/community/UFW).
|
||||
|
||||
## Default XO admin account
|
||||
## Default XO account
|
||||
|
||||
Default user is **admin@admin.net** with **admin** as a password.
|
||||
|
||||
> **SECURITY NOTICE**: create a new admin account and remove this one.
|
||||
:::warning
|
||||
If you are using the default credentials, **please** create a new admin account and remove this one.
|
||||
:::
|
||||
|
||||
In any case, if you lose your password, you can reset the database and get the default credentials back.
|
||||
|
||||
|
||||
175
docs/xosan.md
175
docs/xosan.md
@ -1,6 +1,10 @@
|
||||
# XOSAN
|
||||
# XOSANv1
|
||||
|
||||
XOSAN is a virtual SAN that allows you to create a shared SR (Storage Repository) by combining your existing local SRs. It's a software defined and hyperconverged solution for XenServer.
|
||||
XOSAN is a virtual SAN that allows you to create a shared SR (Storage Repository) by combining your existing local SRs. It's a software defined and hyperconverged solution for Citrix Hypervisor.
|
||||
|
||||
:::warning
|
||||
Due to their difference, XOSANv1 (the initial implementation) is incompatible with XCP-ng. For XCP-ng, see the [XOSANv2 dedicated documentation](xosanv2.md).
|
||||
:::
|
||||
|
||||
|
||||
|
||||
@ -21,8 +25,6 @@ The objectives are to:
|
||||
- give you flexibility to grow your storage by adding new nodes
|
||||
- work on all kinds of hardware, HDDs or SSDs, with hardware RAID or not
|
||||
|
||||
## Deployment
|
||||
|
||||
To deploy XOSAN, please follow the rest of the documentation:
|
||||
|
||||
- [XOSAN Requirements](xosan_requirements.md)
|
||||
@ -30,3 +32,168 @@ To deploy XOSAN, please follow the rest of the documentation:
|
||||
- [How to create a new XOSAN Storage](xosan_create.md)
|
||||
- [XOSAN management](xosan_management.md)
|
||||
- [Get a free XOSAN trial](xosan_trial.md)
|
||||
|
||||
## Requirements
|
||||
|
||||
In order to work, XOSAN need a minimal set of requirements.
|
||||
|
||||
### Storage
|
||||
|
||||
XOSAN can be deployed on an existing **Local LVM storage**, that XenServer configure by default during its installation. You need 10GiB for XOSAN VM (one on each host) and the rest for XOSAN data, eg all the space left.
|
||||
|
||||
However, if you have unused disks on your host, you can also create yourself a local LVM storage while using Xen Orchestra:
|
||||
|
||||
- Go on the "New" menu entry, then select "Storage"
|
||||
- Select the host having the disk you want to use for XOSAN
|
||||
- Select "Local LVM" and enter the path of this disk (e.g: `/dev/sdf`)
|
||||
|
||||
> You can discover disks names by issuing `fdisk -l` command on your XenServer host.
|
||||
|
||||
> **Recommended hardware:** we don't have specific hardware recommendation regarding hard disks. It could be directly a disk or even a disk exposed via a hardware RAID. Note that RAID mode will influence global speed of XOSAN.
|
||||
|
||||
### Network
|
||||
|
||||
XOSAN will use the network card you choose at creation. For better performances, a dedicated storage network should be used.
|
||||
|
||||
> **Recommended hardware:** 1 Gbit/s network card is the minmum to have decent performances. However, a **10 Gbits/s** network is preferable, especially for a setup using SSDs or more than 2 nodes.
|
||||
|
||||
### RAM
|
||||
|
||||
Each XOSAN VM will use 2GiB of RAM. It could be increased (sweet spot seems to be around 4GiB), but it's also workload and infrastructure related. If you don't have a lot of RAM, keep it to 2GiB. If RAM is not an issue, 4GiB is better.
|
||||
|
||||
### CPU
|
||||
|
||||
Each XOSAN VM deployed will use 2x vCPUs. This setting should be enough for all cases.
|
||||
|
||||
### Examples
|
||||
|
||||
For a 6 nodes setup, XOSAN will use in total:
|
||||
|
||||
- 12 vCPUs (usage is in general pretty low)
|
||||
- 12 GiB RAM
|
||||
- All Local LVM disk space
|
||||
|
||||
|
||||
|
||||
## XOSAN types
|
||||
|
||||
There is 2 modes for creating an XOSAN storage. They are different and the choice is done forever. You can't **switch from a mode to another** when XOSAN is created, except by removing and re-creating it.
|
||||
|
||||
That's why it's **very important to understand pros and cons** of each type.
|
||||
|
||||
:::tip
|
||||
On "top" of there 2 types, you can also decide to spread all operations to multiple number of volumes. This is called **distributed** mode. It's very similar to _RAID 0_, which can be placed on top of a _RAID 1_ for example. We'll talk about it in the end of this guide.
|
||||
:::
|
||||
|
||||
Here is those 2 types:
|
||||
|
||||
- [Replicated](xosan_replicated.md)
|
||||
- [Disperse](xosan_disperse.md)
|
||||
|
||||
### Which mode to choose
|
||||
|
||||
In the vast majority of cases, **replicated is better**, because:
|
||||
|
||||
- it's almost ALWAYS faster
|
||||
- it's easier to manage
|
||||
- it's easier to grow
|
||||
|
||||
The only downside is that replicated will "waste" more space.
|
||||
|
||||
Using disperse makes sense only if:
|
||||
|
||||
- you have big HDDs and you want use the space at most
|
||||
- you don't use database (or don't care about performances)
|
||||
- you store big files and you don't need ultra fast data access
|
||||
|
||||
XOSAN will need a pool with:
|
||||
|
||||
- XenServer 7 or higher
|
||||
- Local LVM SR with at lease 15GiB of free space on **each** host
|
||||
- 2 GiB of free RAM on each host for the XOSAN VM
|
||||
- A working connection with the updater (same way as the XO trial)
|
||||
- Our XOSAN pack installed on each hosts (it's automatically deployed during the first XOSAN install)
|
||||
|
||||
> The pack will install user-space packages and add a new SR type: "xosan". Their will be no other modification. The tool stack has to be restarted to be able to deal with XOSAN (no VM or service interruption). It's also fully automated in the XOSAN install process.
|
||||
|
||||
### Optional
|
||||
|
||||
- An extra/dedicated physical network for storage to deliver high performances
|
||||
- 10G networks will deliver higher throughput
|
||||
|
||||
## Creation
|
||||
|
||||
After the completion of all the requirements, you can install XOSAN itself.
|
||||
|
||||
1. Go in your XOSAN panel in Xen Orchestra.
|
||||
|
||||
|
||||
|
||||
2. Click on `new` and select the pool on which you want to create a shared cluster. Click on `install it now` to install the XOSAN package on every hosts in the pool.
|
||||
|
||||
|
||||
|
||||
3. Select the PIF on which you want to create the XOSAN network.
|
||||
|
||||
4. Select all the SR you want to use in your shared cluster.
|
||||
|
||||
> Note: you can only select on SR on each host. If you select SR with different size, the size of the cluster will be limited by the size of the smallest SR selected. We recommend you to use the same type of SR (SSD/HDD) and with the same size to avoid space loss
|
||||
|
||||
|
||||
|
||||
5. Select the mode you want to use for your cluster: disperse or replicate.
|
||||
|
||||
> We do not recommend the disperse mode for now. See [XOSAN types](https://xen-orchestra.com/docs/xosan_types.html) for additional information about modes.
|
||||
|
||||
|
||||
|
||||
### Advanced options
|
||||
|
||||
With the advanced option, you can:
|
||||
|
||||
- use a VLAN
|
||||
|
||||
> If you want to use a VLAN, don't forget to configure your switch as well!
|
||||
|
||||
- use a custom IP network
|
||||
|
||||
- change the total size you want for your shared storage
|
||||
|
||||
- increase the memory allocated to XOSAN
|
||||
> 2GiB is the minimum to allocate to XOSAN. You will get better result with 4GiB and if you have a lot of memory available, 8GiB is the best.
|
||||
|
||||
|
||||
|
||||
Once you are ready, you can click on `Create`. XOSAN will automatically deploy itself and create the virtual shared storage you have selected.
|
||||
|
||||
> The process can take a few minutes to complete.
|
||||
|
||||
|
||||
|
||||
## Try it!
|
||||
|
||||
XOSAN is a 100% software defined solution for XenServer hyperconvergence. You can unlock a free 50GiB cluster to test the solution in your infrastructure and discover all the benefits you can get by using XOSAN.
|
||||
|
||||
### Step 1
|
||||
|
||||
You will need to be registered on our website in order to use Xen Orchestra. If you are not yet registered, [here is the way](https://xen-orchestra.com/#!/signup)
|
||||
|
||||
SSH in your XenServer and use the command line `curl -sS https://xoa.io/deploy | bash` - it will deploy Xen Orchestra Appliance on your XenServer infrastructure which is required to use XOSAN.
|
||||
|
||||
> Note: You can also download the XVA file and follow [these instructions](https://xen-orchestra.com/docs/xoa.html#the-alternative).
|
||||
|
||||
### Step 2
|
||||
|
||||
Register your XOA appliance
|
||||
|
||||
> _If you are not familiar with Xen Orchestra, note that you can also activate a 15 days Premium trial for XOA. More informations [here](https://xen-orchestra.com/#!/trial)_
|
||||
|
||||
|
||||
|
||||
### Step 3
|
||||
|
||||
Access the XOSAN menu and click on the "new" button. By default, your XOSAN will be a trial license, limited to 50GiB of space.
|
||||
|
||||
|
||||
|
||||
> _You will always have the opportunity to upgrade an existing XOSAN cluster which is in trial version to a standard XOSAN license._
|
||||
|
||||
11
docs/xosanv2.md
Normal file
11
docs/xosanv2.md
Normal file
@ -0,0 +1,11 @@
|
||||
# XOSANv2
|
||||
|
||||
The next generation of XOSAN, built for XCP-ng only!
|
||||
|
||||
:::warning
|
||||
XOSANv2 is working in closed beta. Ask us for a demo that we manually install on your setup! The UI will come soon for everyone.
|
||||
:::
|
||||
|
||||
## Why XOSANv2?
|
||||
|
||||
Unlike Citrix Hypervisor, XCP-ng host can be modified. Thanks to that possiblity, extra layers are removed and something more "integrated" can be designed. Due to that different behavior, the architecture is different.
|
||||
@ -25,7 +25,8 @@
|
||||
"lodash": "^4.17.4",
|
||||
"prettier": "^1.10.2",
|
||||
"promise-toolbox": "^0.15.0",
|
||||
"sorted-object": "^2.0.1"
|
||||
"sorted-object": "^2.0.1",
|
||||
"vuepress": "^1.4.1"
|
||||
},
|
||||
"engines": {
|
||||
"yarn": "^1.7.0"
|
||||
@ -64,6 +65,8 @@
|
||||
"clean": "scripts/run-script --parallel clean",
|
||||
"dev": "scripts/run-script --parallel dev",
|
||||
"dev-test": "jest --bail --watch \"^(?!.*\\.integ\\.spec\\.js$)\"",
|
||||
"docs:dev": "vuepress dev docs",
|
||||
"docs:build": "vuepress build docs",
|
||||
"posttest": "scripts/run-script test",
|
||||
"prepare": "scripts/run-script prepare",
|
||||
"pretest": "eslint --ignore-path .gitignore .",
|
||||
|
||||
Loading…
Reference in New Issue
Block a user