chore: format Markdown files with Prettier
This commit is contained in:
Julien Fontanet
parent
3ea9ce0270
commit
c0049b3223
@ -35,7 +35,7 @@ Installation of the [npm package](https://npmjs.org/package/@xen-orchestra/async
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -16,7 +16,6 @@ Installation of the [npm package](https://npmjs.org/package/@xen-orchestra/cron)
|
||||
<minute> <hour> <day of month> <month> <day of week>
|
||||
```
|
||||
|
||||
|
||||
Each entry can be:
|
||||
|
||||
- a single value
|
||||
@ -29,12 +28,12 @@ A wildcard (`*`) can be used as a shortcut for the whole range
|
||||
Step values can be used in conjunctions with ranges. For instance,
|
||||
`1-7/2` is the same as `1,3,5,7`.
|
||||
|
||||
| Field | Allowed values |
|
||||
|------------------|----------------|
|
||||
| minute | 0-59 |
|
||||
| hour | 0-23 |
|
||||
| day of the month | 1-31 or 3-letter names (`jan`, `feb`, …) |
|
||||
| month | 0-11 |
|
||||
| Field | Allowed values |
|
||||
| ---------------- | ------------------------------------------------------------------ |
|
||||
| minute | 0-59 |
|
||||
| hour | 0-23 |
|
||||
| day of the month | 1-31 or 3-letter names (`jan`, `feb`, …) |
|
||||
| month | 0-11 |
|
||||
| day of week | 0-7 (0 and 7 both mean Sunday) or 3-letter names (`mon`, `tue`, …) |
|
||||
|
||||
> Note: the month range is 0-11 to be compatible with
|
||||
@ -131,7 +130,7 @@ job.stop()
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -35,7 +35,7 @@ Installation of the [npm package](https://npmjs.org/package/@xen-orchestra/defin
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -19,7 +19,7 @@ import emitAsync from '@xen-orchestra/emit-async'
|
||||
const ee = new EE()
|
||||
ee.emitAsync = emitAsync
|
||||
|
||||
ee.on('start', async function () {
|
||||
ee.on('start', async function() {
|
||||
// whatever
|
||||
})
|
||||
|
||||
@ -29,11 +29,14 @@ await ee.emitAsync('start')
|
||||
|
||||
// by default, it will rejects as soon as one listener reject, you can customise
|
||||
// error handling though:
|
||||
await ee.emitAsync({
|
||||
onError (error) {
|
||||
console.warn(error)
|
||||
}
|
||||
}, 'start')
|
||||
await ee.emitAsync(
|
||||
{
|
||||
onError(error) {
|
||||
console.warn(error)
|
||||
},
|
||||
},
|
||||
'start'
|
||||
)
|
||||
```
|
||||
|
||||
## Development
|
||||
@ -57,7 +60,7 @@ await ee.emitAsync({
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -51,13 +51,10 @@ const transport = transportEmail({
|
||||
service: 'gmail',
|
||||
auth: {
|
||||
user: 'jane.smith@gmail.com',
|
||||
pass: 'H&NbECcpXF|pyXe#%ZEb'
|
||||
pass: 'H&NbECcpXF|pyXe#%ZEb',
|
||||
},
|
||||
from: 'jane.smith@gmail.com',
|
||||
to: [
|
||||
'jane.smith@gmail.com',
|
||||
'sam.doe@yahoo.com'
|
||||
]
|
||||
to: ['jane.smith@gmail.com', 'sam.doe@yahoo.com'],
|
||||
})
|
||||
|
||||
configure([
|
||||
@ -67,14 +64,14 @@ configure([
|
||||
// matched against the namespace of the logs
|
||||
filter: process.env.DEBUG,
|
||||
|
||||
transport: transportConsole()
|
||||
transport: transportConsole(),
|
||||
},
|
||||
{
|
||||
// only levels >= warn
|
||||
level: 'warn',
|
||||
|
||||
transport
|
||||
}
|
||||
transport,
|
||||
},
|
||||
])
|
||||
|
||||
// send all global errors (uncaught exceptions, warnings, unhandled rejections)
|
||||
@ -105,18 +102,17 @@ Configuration:
|
||||
```js
|
||||
import transportEmail from '@xen-orchestra/log/transports/email'
|
||||
|
||||
configure(transportEmail({
|
||||
service: 'gmail',
|
||||
auth: {
|
||||
user: 'jane.smith@gmail.com',
|
||||
pass: 'H&NbECcpXF|pyXe#%ZEb'
|
||||
},
|
||||
from: 'jane.smith@gmail.com',
|
||||
to: [
|
||||
'jane.smith@gmail.com',
|
||||
'sam.doe@yahoo.com'
|
||||
]
|
||||
}))
|
||||
configure(
|
||||
transportEmail({
|
||||
service: 'gmail',
|
||||
auth: {
|
||||
user: 'jane.smith@gmail.com',
|
||||
pass: 'H&NbECcpXF|pyXe#%ZEb',
|
||||
},
|
||||
from: 'jane.smith@gmail.com',
|
||||
to: ['jane.smith@gmail.com', 'sam.doe@yahoo.com'],
|
||||
})
|
||||
)
|
||||
```
|
||||
|
||||
#### Syslog
|
||||
@ -160,7 +156,7 @@ configure(transportSyslog('tcp://syslog.company.lan'))
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -35,7 +35,7 @@ Installation of the [npm package](https://npmjs.org/package/@xen-orchestra/mixin
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -13,16 +13,19 @@ Installation of the [npm package](https://npmjs.org/package/@xen-orchestra/templ
|
||||
Create a string replacer based on a pattern and a list of rules.
|
||||
|
||||
```js
|
||||
const myReplacer = compileTemplate('{name}_COPY_\{name}_{id}_%\%', {
|
||||
const myReplacer = compileTemplate('{name}_COPY_{name}_{id}_%%', {
|
||||
'{name}': vm => vm.name_label,
|
||||
'{id}': vm => vm.id,
|
||||
'%': (_, i) => i
|
||||
'%': (_, i) => i,
|
||||
})
|
||||
|
||||
const newString = myReplacer({
|
||||
name_label: 'foo',
|
||||
id: 42,
|
||||
}, 32)
|
||||
const newString = myReplacer(
|
||||
{
|
||||
name_label: 'foo',
|
||||
id: 42,
|
||||
},
|
||||
32
|
||||
)
|
||||
|
||||
newString === 'foo_COPY_{name}_42_32%' // true
|
||||
```
|
||||
@ -48,7 +51,7 @@ newString === 'foo_COPY_{name}_42_32%' // true
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -8,19 +8,19 @@ In the interest of fostering an open and welcoming environment, we as contributo
|
||||
|
||||
Examples of behavior that contributes to creating a positive environment include:
|
||||
|
||||
* Using welcoming and inclusive language
|
||||
* Being respectful of differing viewpoints and experiences
|
||||
* Gracefully accepting constructive criticism
|
||||
* Focusing on what is best for the community
|
||||
* Showing empathy towards other community members
|
||||
- Using welcoming and inclusive language
|
||||
- Being respectful of differing viewpoints and experiences
|
||||
- Gracefully accepting constructive criticism
|
||||
- Focusing on what is best for the community
|
||||
- Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery and unwelcome sexual attention or advances
|
||||
* Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
* Public or private harassment
|
||||
* Publishing others' private information, such as a physical or electronic address, without explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a professional setting
|
||||
- The use of sexualized language or imagery and unwelcome sexual attention or advances
|
||||
- Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
- Public or private harassment
|
||||
- Publishing others' private information, such as a physical or electronic address, without explicit permission
|
||||
- Other conduct which could reasonably be considered inappropriate in a professional setting
|
||||
|
||||
## Our Responsibilities
|
||||
|
||||
|
||||
@ -14,9 +14,9 @@ the issues :)
|
||||
|
||||
- **XO origin**: the sources / XO Appliance
|
||||
- **Versions**:
|
||||
- Node: **FILL HERE**
|
||||
- xo-web: **FILL HERE**
|
||||
- xo-server: **FILL HERE**
|
||||
- Node: **FILL HERE**
|
||||
- xo-web: **FILL HERE**
|
||||
- xo-server: **FILL HERE**
|
||||
|
||||
### Expected behavior
|
||||
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
|
||||
# Xen Orchestra
|
||||
|
||||
## Introduction
|
||||
@ -21,11 +20,11 @@ Log in to your account and use the deploy form available on [this page](https://
|
||||
|
||||
### XOA credentials
|
||||
|
||||
* Web UI: `admin@admin.net` / `admin`
|
||||
* Console/SSH: `xoa` / `xoa` (first login)
|
||||
- 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)
|
||||
- [XOA installation](xoa.md)
|
||||
- [Main features](features.md)
|
||||
- [Pro Support](support.md)
|
||||
|
||||
158
docs/SUMMARY.md
158
docs/SUMMARY.md
@ -1,81 +1,81 @@
|
||||
# Summary
|
||||
|
||||
* [Introduction](README.md)
|
||||
* [Architecture](architecture.md)
|
||||
* [xo-server](xo-server.md)
|
||||
* [xo-web](xo-web.md)
|
||||
* [xo-cli](xo-cli.md)
|
||||
* [others](others.md)
|
||||
* [Installation](installation.md)
|
||||
* [XOA](xoa.md)
|
||||
* [Updater](updater.md)
|
||||
* [Trial activation](trial_activation.md)
|
||||
* [Plugins](plugins.md)
|
||||
* [Logs](logs.md)
|
||||
* [Compatibility](supported-version.md)
|
||||
* [Troubleshooting](troubleshooting.md)
|
||||
* [From the sources](from_the_sources.md)
|
||||
* [Configuration](configuration.md)
|
||||
* [Features](features.md)
|
||||
* [Administration](administration.md)
|
||||
* [Home view](user_interface.md)
|
||||
* [Search and filters](search.md)
|
||||
* [VM management](vm_management.md)
|
||||
* [VM creation](vm_creation.md)
|
||||
* [VM import and export](vm_import_export.md)
|
||||
* [XenServer Patching](patching.md)
|
||||
* [Docker support](docker_support.md)
|
||||
* [Backup and DR](backups.md)
|
||||
* [Full backups](full_backups.md)
|
||||
* [Rolling snapshots](rolling_snapshots.md)
|
||||
* [Continuous Delta backups](delta_backups.md)
|
||||
* [Continuous Replication](continuous_replication.md)
|
||||
* [Disaster recovery](disaster_recovery.md)
|
||||
* [Smart Backup](smart_backup.md)
|
||||
* [File level Restore](file_level_restore.md)
|
||||
* [Metadata Backup](metadata_backup.md)
|
||||
* [Backup Concurrency](concurrency.md)
|
||||
* [Configure backup reports](backup_reports.md)
|
||||
* [Backup troubleshooting](backup_troubleshooting.md)
|
||||
* [User authentication](authentication.md)
|
||||
* [Built-in](built-in.md)
|
||||
* [LDAP](ldap.md)
|
||||
* [SAML](saml.md)
|
||||
* [GitHub](github.md)
|
||||
* [Google](google.md)
|
||||
* [Resources delegation](resources_delegation.md)
|
||||
* [ACLs](acls.md)
|
||||
* [CloudInit](cloudinit.md)
|
||||
* [Self Service](self_service.md)
|
||||
* [Visualizations](visualizations.md)
|
||||
* [Health](health.md)
|
||||
* [Job manager](scheduler.md)
|
||||
* [Alerts](alerts.md)
|
||||
* [Web hooks](web-hooks.md)
|
||||
* [Load balancing](load_balancing.md)
|
||||
* [Emergency Shutdown](emergency_shutdown.md)
|
||||
* [Auto scalability](auto_scalability.md)
|
||||
* [Forecaster](forecaster.md)
|
||||
* [SDN Controller](sdn_controller.md)
|
||||
* [Recipes](recipes.md)
|
||||
* [Reverse proxy](reverse_proxy.md)
|
||||
* [How to contribute?](contributing.md)
|
||||
* [Support](support.md)
|
||||
* [Roadmap](roadmap.md)
|
||||
* [Purchase](purchase.md)
|
||||
* [Direct purchase](directpurchase.md)
|
||||
* [Through purchase department](through_purchase_department.md)
|
||||
* [Reseller](reseller.md)
|
||||
* [Editions](editions.md)
|
||||
* [Trial](trial.md)
|
||||
* [Invoices](invoices.md)
|
||||
* [Upgrade](upgrade.md)
|
||||
* [XOSAN](xosan.md)
|
||||
* [Requirements](xosan_requirements.md)
|
||||
* [Types](xosan_types.md)
|
||||
* [Replicated](xosan_replicated.md)
|
||||
* [Disperse](xosan_disperse.md)
|
||||
* [Creation](xosan_create.md)
|
||||
* [Trial](xosan_trial.md)
|
||||
* [General Troubleshooting](general-troubleshooting.md)
|
||||
* [Glossary](glossary.md)
|
||||
- [Introduction](README.md)
|
||||
- [Architecture](architecture.md)
|
||||
- [xo-server](xo-server.md)
|
||||
- [xo-web](xo-web.md)
|
||||
- [xo-cli](xo-cli.md)
|
||||
- [others](others.md)
|
||||
- [Installation](installation.md)
|
||||
- [XOA](xoa.md)
|
||||
- [Updater](updater.md)
|
||||
- [Trial activation](trial_activation.md)
|
||||
- [Plugins](plugins.md)
|
||||
- [Logs](logs.md)
|
||||
- [Compatibility](supported-version.md)
|
||||
- [Troubleshooting](troubleshooting.md)
|
||||
- [From the sources](from_the_sources.md)
|
||||
- [Configuration](configuration.md)
|
||||
- [Features](features.md)
|
||||
- [Administration](administration.md)
|
||||
- [Home view](user_interface.md)
|
||||
- [Search and filters](search.md)
|
||||
- [VM management](vm_management.md)
|
||||
- [VM creation](vm_creation.md)
|
||||
- [VM import and export](vm_import_export.md)
|
||||
- [XenServer Patching](patching.md)
|
||||
- [Docker support](docker_support.md)
|
||||
- [Backup and DR](backups.md)
|
||||
- [Full backups](full_backups.md)
|
||||
- [Rolling snapshots](rolling_snapshots.md)
|
||||
- [Continuous Delta backups](delta_backups.md)
|
||||
- [Continuous Replication](continuous_replication.md)
|
||||
- [Disaster recovery](disaster_recovery.md)
|
||||
- [Smart Backup](smart_backup.md)
|
||||
- [File level Restore](file_level_restore.md)
|
||||
- [Metadata Backup](metadata_backup.md)
|
||||
- [Backup Concurrency](concurrency.md)
|
||||
- [Configure backup reports](backup_reports.md)
|
||||
- [Backup troubleshooting](backup_troubleshooting.md)
|
||||
- [User authentication](authentication.md)
|
||||
- [Built-in](built-in.md)
|
||||
- [LDAP](ldap.md)
|
||||
- [SAML](saml.md)
|
||||
- [GitHub](github.md)
|
||||
- [Google](google.md)
|
||||
- [Resources delegation](resources_delegation.md)
|
||||
- [ACLs](acls.md)
|
||||
- [CloudInit](cloudinit.md)
|
||||
- [Self Service](self_service.md)
|
||||
- [Visualizations](visualizations.md)
|
||||
- [Health](health.md)
|
||||
- [Job manager](scheduler.md)
|
||||
- [Alerts](alerts.md)
|
||||
- [Web hooks](web-hooks.md)
|
||||
- [Load balancing](load_balancing.md)
|
||||
- [Emergency Shutdown](emergency_shutdown.md)
|
||||
- [Auto scalability](auto_scalability.md)
|
||||
- [Forecaster](forecaster.md)
|
||||
- [SDN Controller](sdn_controller.md)
|
||||
- [Recipes](recipes.md)
|
||||
- [Reverse proxy](reverse_proxy.md)
|
||||
- [How to contribute?](contributing.md)
|
||||
- [Support](support.md)
|
||||
- [Roadmap](roadmap.md)
|
||||
- [Purchase](purchase.md)
|
||||
- [Direct purchase](directpurchase.md)
|
||||
- [Through purchase department](through_purchase_department.md)
|
||||
- [Reseller](reseller.md)
|
||||
- [Editions](editions.md)
|
||||
- [Trial](trial.md)
|
||||
- [Invoices](invoices.md)
|
||||
- [Upgrade](upgrade.md)
|
||||
- [XOSAN](xosan.md)
|
||||
- [Requirements](xosan_requirements.md)
|
||||
- [Types](xosan_types.md)
|
||||
- [Replicated](xosan_replicated.md)
|
||||
- [Disperse](xosan_disperse.md)
|
||||
- [Creation](xosan_create.md)
|
||||
- [Trial](xosan_trial.md)
|
||||
- [General Troubleshooting](general-troubleshooting.md)
|
||||
- [Glossary](glossary.md)
|
||||
|
||||
38
docs/acls.md
38
docs/acls.md
@ -23,32 +23,32 @@ You can edit/remove existing ACLs here.
|
||||
|
||||
There are 3 different roles for your users:
|
||||
|
||||
* Admin
|
||||
* Operator
|
||||
* Viewer
|
||||
- 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
|
||||
- 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
|
||||
- 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.
|
||||
|
||||
@ -60,7 +60,7 @@ A viewer can only see the VM state and its metrics. That's all!
|
||||
|
||||
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).
|
||||
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
|
||||
|
||||
@ -68,5 +68,5 @@ If you give a *view* permission to a user (or a group) on a pool, he will automa
|
||||
|
||||
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.
|
||||
- _Operate_ on the VM (e.g to start it)
|
||||
- _View_ on the ISO Storage containing the needed ISO.
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
|
||||
This section contains everyday XenServer administration tasks.
|
||||
|
||||
* [Home view](user_interface.md)
|
||||
* [Search and filters](search.md)
|
||||
* [VM management](vm_management.md)
|
||||
* [VM creation](vm_creation.md)
|
||||
* [VM import and export](vm_import_export.md)
|
||||
* [XenServer Patching](patching.md)
|
||||
- [Home view](user_interface.md)
|
||||
- [Search and filters](search.md)
|
||||
- [VM management](vm_management.md)
|
||||
- [VM creation](vm_creation.md)
|
||||
- [VM import and export](vm_import_export.md)
|
||||
- [XenServer Patching](patching.md)
|
||||
|
||||
|
||||
|
||||
@ -8,12 +8,12 @@ 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)
|
||||
- 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.
|
||||
|
||||
@ -31,5 +31,5 @@ You can choose to be notified only if it fails or even after each backup job.
|
||||
|
||||
Current supported alerts system:
|
||||
|
||||
* Email
|
||||
* XMPP
|
||||
- Email
|
||||
- XMPP
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
|
||||
# Architecture
|
||||
|
||||
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`.
|
||||
@ -7,7 +6,7 @@ Xen Orchestra (XO) is software built with a server and clients, such as the web
|
||||
|
||||
## XOA
|
||||
|
||||
*Xen Orchestra Virtual Appliance* (XOA) is a virtual machine with Xen Orchestra already installed, thus working out-of-the-box.
|
||||
_Xen Orchestra Virtual Appliance_ (XOA) is a virtual machine with Xen Orchestra already installed, thus working out-of-the-box.
|
||||
|
||||
This is the easiest way to try Xen Orchestra quickly.
|
||||
|
||||
@ -20,9 +19,9 @@ Your XOA is connected to all your hosts, or the pool master only if you are usin
|
||||
|
||||
|
||||
Xen Orchestra itself is built as a modular solution. Each part has its role:
|
||||
|
||||
- The core is "[xo-server](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-server/)" - a daemon dealing directly with XenServer or XAPI capable hosts. This is where users are stored, and it's the center point for talking to your whole Xen infrastructure.
|
||||
- The web interface is "[xo-web](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-web)" - it runs directly from your browser. The connection with ```xo-server``` is done via *WebSockets*.
|
||||
- The web interface is "[xo-web](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-web)" - it runs directly from your browser. The connection with `xo-server` is done via _WebSockets_.
|
||||
- "[xo-cli](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-cli)" is a module allowing you to send commands directly from the command line.
|
||||
|
||||
|
||||
We have other modules as well (like the LDAP plugin for example). It allows us to use this modular architecture to add further parts as we need them. It's completely flexible, allowing us to adapt Xen Orchestra to every existing workflow.
|
||||
|
||||
@ -1,16 +1,14 @@
|
||||
# User authentication
|
||||
|
||||
|
||||
Xen Orchestra supports various types of user authentication, internal or even external thanks to the usage of the [Passport library](http://passportjs.org/).
|
||||
|
||||
There are 2 types of XO users:
|
||||
|
||||
* admins, with all rights on all connected resources
|
||||
* users, with no rights by default
|
||||
- admins, with all rights on all connected resources
|
||||
- users, with no rights by default
|
||||
|
||||
All users will land on the "flat" view, which displays no hierarchy, only all their visible objects (or no object if they are not configured).
|
||||
|
||||
|
||||
ACLs will thus apply only to "users".
|
||||
|
||||
> Any account created by an external authentication process (LDAP, SSO...) will be a **user** without any permission.
|
||||
|
||||
@ -6,15 +6,15 @@ At the end of a backup job, you can configure Xen Orchestra to send backup repor
|
||||
|
||||
### Step-by-step
|
||||
|
||||
1. On the "settings/plugins" view you have to activate and configure the "Backup-reports" plugin.
|
||||
|
||||
1. On the "settings/plugins" view you have to activate and configure the "Backup-reports" plugin.
|
||||
|
||||
|
||||
2. Still in the plugins view, you also have to configure the "transport-email" plugin.
|
||||
|
||||
|
||||
|
||||
3. Once it's done, you can now create your backup job. In the "report" selection you can choose the situation in wish you want to receive an email (always, never or failure).
|
||||
|
||||
> Note: You can also modify existing backup jobs and change the behaviour of the report system.
|
||||
3. Once it's done, you can now create your backup job. In the "report" selection you can choose the situation in wish you want to receive an email (always, never or failure).
|
||||
|
||||
> Note: You can also modify existing backup jobs and change the behaviour of the report system.
|
||||
|
||||
## XMPP nofications
|
||||
|
||||
@ -67,9 +67,9 @@ Like all other xo-server plugins, it can be configured directly via the web inte
|
||||
|
||||
You need to be an admin:
|
||||
|
||||
* Go into the MatterMost menu, then Integration
|
||||
* Click on "Add Incoming webhook"
|
||||
* "Add Incoming Webhook"
|
||||
- Go into the MatterMost menu, then Integration
|
||||
- Click on "Add Incoming webhook"
|
||||
- "Add Incoming Webhook"
|
||||
|
||||
### Testing the plugin
|
||||
|
||||
|
||||
@ -12,14 +12,14 @@ Another good way to check if there is activity is the XOA VM stats view (on the
|
||||
|
||||
### 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.
|
||||
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.
|
||||
|
||||
This mechanism and scheduling is handled by XenServer itself, not Xen Orchestra. But we can check your existing VDI chain and avoid creating more snapshots than your storage can merge. If we don't, this will lead to catastrophic consequences. Xen Orchestra is the **only** XenServer/XCP backup product that takes this into account and offers protection.
|
||||
|
||||
Without this detection, you could have 2 potential issues:
|
||||
|
||||
* `The Snapshot Chain is too Long`
|
||||
* `SR_BACKEND_FAILURE_44 (insufficient space)`
|
||||
- `The Snapshot Chain is too Long`
|
||||
- `SR_BACKEND_FAILURE_44 (insufficient space)`
|
||||
|
||||
The first issue is a chain that contains more than 30 elements (fixed XenServer limit), and the other one means it's full because the "coalesce" process couldn't keep up the pace and the storage filled up.
|
||||
|
||||
@ -31,15 +31,15 @@ Just remember this: **a coalesce should happen every time a snapshot is removed*
|
||||
|
||||
### Troubleshooting a constant VDI Chain Protection message (XenServer failure to coalesce)
|
||||
|
||||
As previously mentioned, this message can be normal and it just means XenServer needs to perform a coalesce to merge old snapshots. However if you repeatedly get this message and it seems XenServer is not coalescing, You can take a few steps to determine why.
|
||||
As previously mentioned, this message can be normal and it just means XenServer needs to perform a coalesce to merge old snapshots. However if you repeatedly get this message and it seems XenServer is not coalescing, You can take a few steps to determine why.
|
||||
|
||||
First check SMlog on the XenServer host for messages relating to VDI corruption or coalesce job failure. For example, by running `cat /var/log/SMlog | grep -i exception` or `cat /var/log/SMlog | grep -i error` on the XenServer host with the affected storage.
|
||||
First check SMlog on the XenServer host for messages relating to VDI corruption or coalesce job failure. For example, by running `cat /var/log/SMlog | grep -i exception` or `cat /var/log/SMlog | grep -i error` on the XenServer host with the affected storage.
|
||||
|
||||
Coalesce jobs can also fail to run if the SR does not have enough free space. Check the problematic SR and make sure it has enough free space, generally 30% or more free is recommended depending on VM size. You can check if this is the issue by searching `SMlog` with `grep -i coales /var/log/SMlog` (you may have to look at previous logs such as `SMlog.1`).
|
||||
|
||||
You can check if a coalesce job is currently active by running `ps axf | grep vhd` on the XenServer host and looking for a VHD process in the results (one of the resulting processes will be the grep command you just ran, ignore that one).
|
||||
You can check if a coalesce job is currently active by running `ps axf | grep vhd` on the XenServer host and looking for a VHD process in the results (one of the resulting processes will be the grep command you just ran, ignore that one).
|
||||
|
||||
If you don't see any running coalesce jobs, and can't find any other reason that XenServer has not started one, you can attempt to make it start a coalesce job by rescanning the SR. This is harmless to try, but will not always result in a coalesce. Visit the problematic SR in the XOA UI, then click the "Rescan All Disks" button towards the top right: it looks like a refresh circle icon. This should begin the coalesce process - if you click the Advanced tab in the SR view, the "disks needing to be coalesced" list should become smaller and smaller.
|
||||
If you don't see any running coalesce jobs, and can't find any other reason that XenServer has not started one, you can attempt to make it start a coalesce job by rescanning the SR. This is harmless to try, but will not always result in a coalesce. Visit the problematic SR in the XOA UI, then click the "Rescan All Disks" button towards the top right: it looks like a refresh circle icon. This should begin the coalesce process - if you click the Advanced tab in the SR view, the "disks needing to be coalesced" list should become smaller and smaller.
|
||||
|
||||
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.
|
||||
|
||||
@ -55,10 +55,10 @@ The Storage Repository (where your VM disks are currently stored) is full. Note
|
||||
|
||||
Workarounds:
|
||||
|
||||
* use a thin provisioned SR (local ext, NFS, XOSAN)
|
||||
* wait for Citrix to release thin provisioning on LVM
|
||||
* 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
|
||||
- use a thin provisioned SR (local ext, NFS, XOSAN)
|
||||
- wait for Citrix to release thin provisioning on LVM
|
||||
- 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
|
||||
|
||||
@ -72,12 +72,12 @@ To solve it, you have to change a parameter in your VM. `xe vm-param-set has-ven
|
||||
|
||||
### 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.
|
||||
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
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
Edit your job and try to see matching VMs or check if your pool is connected to XOA.
|
||||
|
||||
@ -6,13 +6,13 @@ This section is dedicated to all existing methods of rolling back or backing up
|
||||
|
||||
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*]
|
||||
- [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.
|
||||
|
||||
@ -54,16 +54,15 @@ The tooltip confirms this:
|
||||
|
||||
## Remotes
|
||||
|
||||
> Remotes are places where your *backup* and *delta backup* files will be stored.
|
||||
> Remotes are places where your _backup_ and _delta backup_ files will be stored.
|
||||
|
||||
To add a *remote*, go to the **Settings/Remotes** menu.
|
||||
To add a _remote_, go to the **Settings/Remotes** menu.
|
||||
|
||||
Supported remote types:
|
||||
|
||||
* Local (any folder in XOA filesystem)
|
||||
* NFS
|
||||
* SMB (CIFS)
|
||||
|
||||
- Local (any folder in XOA filesystem)
|
||||
- NFS
|
||||
- SMB (CIFS)
|
||||
|
||||
> **WARNING**: the initial "/" or "\\" is automatically added.
|
||||
|
||||
@ -73,15 +72,15 @@ On your NFS server, authorize XOA's IP address and permissions for subfolders. T
|
||||
|
||||
### SMB
|
||||
|
||||
We support SMB storage on *Windows Server 2012 R2*.
|
||||
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)
|
||||
|
||||
Also, read the UI twice when you add an SMB store. If you have:
|
||||
|
||||
* `192.168.1.99` as SMB host
|
||||
* `Backups` as folder
|
||||
* no subfolder
|
||||
- `192.168.1.99` as SMB host
|
||||
- `Backups` as folder
|
||||
- no subfolder
|
||||
|
||||
You'll have to fill it like this:
|
||||
|
||||
@ -112,13 +111,13 @@ All your scheduled backups are acccessible in the "Restore" view in the backup s
|
||||
|
||||
## 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, done on XenServer side). There is no absolute rule but in general uncompressed backups are faster (but sometimes much larger).
|
||||
|
||||
XenServer uses Gzip compression, which is:
|
||||
|
||||
* slow (single threaded)
|
||||
* space efficient
|
||||
* consumes less bandwidth (helpful if your NFS share is far away)
|
||||
- slow (single threaded)
|
||||
- space efficient
|
||||
- consumes less bandwidth (helpful if your NFS share is far away)
|
||||
|
||||
If you have compression on your NFS share (or destination filesystem like ZFS), you can disable compression in Xen Orchestra.
|
||||
|
||||
@ -152,4 +151,4 @@ Replicated VMs HA are taken into account by XS/XCP-ng. To avoid the resultant tr
|
||||
|
||||
|
||||
|
||||
> The tag won't be automatically removed by XO on the replicated VMs, even if HA is re-enabled.
|
||||
> The tag won't be automatically removed by XO on the replicated VMs, even if HA is re-enabled.
|
||||
|
||||
@ -22,16 +22,15 @@ All your scheduled backup are acccessible in the "Restore" view in backup sectio
|
||||
|
||||
|
||||
|
||||
|
||||
### Backup compression
|
||||
|
||||
By default, Backup are compressed (using GZIP, done in XenServer side). There is no absolute rule about using compression or not, but there is some rules.
|
||||
|
||||
Gzip compression is:
|
||||
|
||||
* slow
|
||||
* space efficient
|
||||
* consume less bandwidth (if your NFS share is far)
|
||||
- slow
|
||||
- space efficient
|
||||
- consume less bandwidth (if your NFS share is far)
|
||||
|
||||
If you have compression on your NFS share (or destination file-system like ZFS), you can disable compression in Xen Orchestra.
|
||||
|
||||
@ -45,4 +44,4 @@ This feature is close to Backups, but it creates a snapshot when planned to do s
|
||||
|
||||
**Warning**: snapshots are not backups. They help to rollback to a previous state, but all snapshots are on the same Storage than their original disk. If you lose the original VDI (or the SR), you'll **lose all your snapshots**.
|
||||
|
||||
[Read more about it](https://xen-orchestra.com/blog/xen-orchestra-4-2/#schedulerollingsnapshots).
|
||||
[Read more about it](https://xen-orchestra.com/blog/xen-orchestra-4-2/#schedulerollingsnapshots).
|
||||
|
||||
@ -3,8 +3,8 @@
|
||||
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)
|
||||
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.
|
||||
By default, a _user_ won't have any permissions. At the opposite, an _admin_ will have all rights.
|
||||
|
||||
@ -2,11 +2,11 @@
|
||||
|
||||
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!
|
||||
- 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.
|
||||
|
||||
@ -40,19 +40,19 @@ 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):
|
||||
- **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 ~]$
|
||||
[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]#
|
||||
[root@tmp-app1 centos]#
|
||||
```
|
||||
|
||||
Check the root file system size: indeed, **it was automatically increased** to what you need:
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
# Backup Concurrency
|
||||
|
||||
|
||||
Xen Orchestra 5.20 introduces new tools to manage backup concurrency. Below is an overview of the backup process and ways you can control concurrency in your own environment.
|
||||
|
||||
## Backup process
|
||||
@ -21,8 +20,8 @@ When it's done exporting, we'll remove the snapshot. Note: this operation will t
|
||||
|
||||
Let's say you want to backup 50 VMs (each with 1x disk) at 3:00 AM. There are **2 different strategies**:
|
||||
|
||||
1. backup VM #1 (snapshot, export, delete snapshots) **then** backup VM #2 -> *fully sequential strategy*
|
||||
2. snapshot all VMs, **then** export all snapshots, **then** delete all snapshots for finished exports -> *fully parallel strategy*
|
||||
1. backup VM #1 (snapshot, export, delete snapshots) **then** backup VM #2 -> _fully sequential strategy_
|
||||
2. snapshot all VMs, **then** export all snapshots, **then** delete all snapshots for finished exports -> _fully parallel strategy_
|
||||
|
||||
The first purely sequential strategy will lead to a big problem: **you can't predict when a snapshot of your data will occur**. Because you can't predict the first VM export time (let's say 3 hours), then your second VM will have its snapshot taken 3 hours later, at 6 AM. We assume that's not what you meant when you specified "backup everything at 3 AM". You would end up with data from 6 AM (and later) for other VMs.
|
||||
|
||||
@ -32,19 +31,18 @@ So what's the best choice? Continue below to learn how to best configure concurr
|
||||
|
||||
### Best choice
|
||||
|
||||
By default the *parallel strategy* is, on paper, the most logical one. But we need to give it some limits on concurrency.
|
||||
By default the _parallel strategy_ is, on paper, the most logical one. But we need to give it some limits on concurrency.
|
||||
|
||||
> Note: Xen Orchestra can be connected to multiple pools at once. So the concurrency number applies **per pool**.
|
||||
|
||||
Each step has its own concurrency to fit its requirements:
|
||||
|
||||
* **snapshot process** needs to be performed with the lowest concurrency possible. 2 is a good compromise: one snapshot is fast, but a stuck snapshot won't block the whole job. That's why a concurrency of 2 is not too bad on your storage. Basically, at 3 AM, we'll do all the VM snapshots needed, 2 at a time.
|
||||
* **disk export process** is bottlenecked by XCP-ng/XenServer - so to get the most of it, you can use up to 12 in parallel. As soon a snapshot is done, the export process will start, until reaching 12 at once. Then as soon as one in those 12 is finished, another one will appear until there is nothing more to export.
|
||||
* **snapshot deletion** can't happen all at once because the previous step durations are random - no need to implement concurrency on this one.
|
||||
|
||||
This is how it currently works in Xen Orchestra. But sometimes, you also want to have *sequential* backups combined with the *parallel strategy*. That's why we introduced a sequential option in the advanced section of backup-ng:
|
||||
- **snapshot process** needs to be performed with the lowest concurrency possible. 2 is a good compromise: one snapshot is fast, but a stuck snapshot won't block the whole job. That's why a concurrency of 2 is not too bad on your storage. Basically, at 3 AM, we'll do all the VM snapshots needed, 2 at a time.
|
||||
- **disk export process** is bottlenecked by XCP-ng/XenServer - so to get the most of it, you can use up to 12 in parallel. As soon a snapshot is done, the export process will start, until reaching 12 at once. Then as soon as one in those 12 is finished, another one will appear until there is nothing more to export.
|
||||
- **snapshot deletion** can't happen all at once because the previous step durations are random - no need to implement concurrency on this one.
|
||||
|
||||
This is how it currently works in Xen Orchestra. But sometimes, you also want to have _sequential_ backups combined with the _parallel strategy_. That's why we introduced a sequential option in the advanced section of backup-ng:
|
||||
|
||||
> Note: 0 means it will be fully **parallel** for all VMs.
|
||||
|
||||
If you job contains 50 VMs for example, you could specify a sequential backup with a limit of "25 at once" (enter 25 in the concurrency field). This means at 3 AM, we'll do 25 snapshots (2 at a time), then exports. As soon as the first VM backup is completely finished (snapshot removed), then we'll start the 26th and so on, to always keep a max of 25x VM backups going in parallel.
|
||||
If you job contains 50 VMs for example, you could specify a sequential backup with a limit of "25 at once" (enter 25 in the concurrency field). This means at 3 AM, we'll do 25 snapshots (2 at a time), then exports. As soon as the first VM backup is completely finished (snapshot removed), then we'll start the 26th and so on, to always keep a max of 25x VM backups going in parallel.
|
||||
|
||||
@ -15,7 +15,7 @@ user = 'nobody'
|
||||
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).
|
||||
**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
|
||||
|
||||
|
||||
@ -2,17 +2,17 @@
|
||||
|
||||
> 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 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:
|
||||
|
||||
* no storage vendor lock-in
|
||||
* no configuration (agent-less)
|
||||
* low Recovery Point Objective, from 10 minutes to 24 hours (or more)
|
||||
* flexibility
|
||||
* no intermediate storage needed
|
||||
* atomic replication
|
||||
* efficient DR (disaster recovery) process
|
||||
- no storage vendor lock-in
|
||||
- no configuration (agent-less)
|
||||
- low Recovery Point Objective, from 10 minutes to 24 hours (or more)
|
||||
- flexibility
|
||||
- no intermediate storage needed
|
||||
- atomic replication
|
||||
- efficient DR (disaster recovery) process
|
||||
|
||||
If you lose your main pool, you can start the copy on the other side, with very recent data.
|
||||
|
||||
@ -36,14 +36,13 @@ To protect the replication, we removed the possibility to boot your copied VM di
|
||||
|
||||
## Manual initial seed
|
||||
|
||||
**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).
|
||||
**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!
|
||||
|
||||
|
||||
### Job creation
|
||||
|
||||
Create the Continuous Replication backup job, and leave it disabled for now. On the main Backup-NG page, copy the job's `backupJobId` by hovering to the left of the shortened ID and clicking the copy to clipboard button:
|
||||
Create the Continuous Replication backup job, and leave it disabled for now. On the main Backup-NG page, copy the job's `backupJobId` by hovering to the left of the shortened ID and clicking the copy to clipboard button:
|
||||
|
||||
|
||||
|
||||
@ -87,7 +86,9 @@ Usage: xo-cr-seed <source XAPI URL> <source snapshot UUID> <target XAPI URL> <ta
|
||||
|
||||
xo-cr-seed v0.2.0
|
||||
```
|
||||
|
||||
Putting it altogether and putting our values and UUID's into the command, it will look like this (it is a long command):
|
||||
|
||||
```
|
||||
xo-cr-seed https://root:password@xen1.company.tld 4a21c1cd-e8bd-4466-910a-f7524ecc07b1 https://root:password@xen2.company.tld 5aaf86ca-ae06-4a4e-b6e1-d04f0609e64d 90d11a94-a88f-4a84-b7c1-ed207d3de2f9 369a26f0-da77-41ab-a998-fa6b02c69b9a
|
||||
```
|
||||
|
||||
@ -11,8 +11,9 @@ You can [open bug reports here](https://github.com/vatesfr/xen-orchestra/issues)
|
||||
Using the GitHub fork/pull-request feature, you may send us fixes or enhancements.
|
||||
|
||||
Please, do explain:
|
||||
* what you are fixing (issue number if available);
|
||||
* how you did it.
|
||||
|
||||
- what you are fixing (issue number if available);
|
||||
- how you did it.
|
||||
|
||||
### Pull requests
|
||||
|
||||
@ -22,7 +23,6 @@ to create a [GitHub pull request](https://help.github.com/articles/using-pull-re
|
||||
> Your pull request should always be against the `master`
|
||||
> branch and not against `stable` which is the stable branch!
|
||||
|
||||
|
||||
1. Create a branch for your work
|
||||
2. Add a summary of your changes to `CHANGELOG.md` under the `next` section, if your changes do not relate to an existing changelog item
|
||||
3. Create a pull request for this branch against the `master` branch
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
> 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.
|
||||
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
|
||||
|
||||
@ -16,10 +16,10 @@ It means huge files for each backup. Delta backups will only export the differen
|
||||
|
||||
You can imagine making your first initial full backup during a weekend, and then only delta backups every night. It combines the flexibility of snapshots and the power of full backups, because:
|
||||
|
||||
* delta are stored somewhere else than the current VM storage
|
||||
* they are small
|
||||
* quick to create
|
||||
* easy to restore
|
||||
- delta are stored somewhere else than the current VM storage
|
||||
- they are small
|
||||
- quick to create
|
||||
- easy to restore
|
||||
|
||||
So, if you want to rollback your VM to a previous state, the cost is only one snapshot on your SR (far less than the [rolling snapshot](rolling_snapshot.md) mechanism).
|
||||
|
||||
@ -42,6 +42,7 @@ This way we can go "forward" and remove this oldest VHD after the merge:
|
||||
Just go into your "Backup" view, and select Delta Backup. Then, it's the same as a normal backup.
|
||||
|
||||
## Snapshots
|
||||
|
||||
Unlike other types of backup jobs which delete the associated snapshot when the job is done and it has been exported, delta backups always keep a snapshot of every VM in the backup job, and uses it for the delta. Do not delete these snapshots!
|
||||
|
||||
## Exclude disks
|
||||
|
||||
@ -6,9 +6,8 @@ This is the easiest purchase option: you can buy XOA with your registered email
|
||||
|
||||
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)
|
||||
|
||||
- [the pricing page](https://xen-orchestra.com/#!/pricing)
|
||||
- [your account/purchases page](https://xen-orchestra.com/#!/purchases)
|
||||
|
||||
> 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).
|
||||
|
||||
@ -18,7 +17,7 @@ From your account page, click on the purchase menu, then select the edition you
|
||||
|
||||
## Purchase options
|
||||
|
||||
The second step is to select your purchase option:
|
||||
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.
|
||||
|
||||
@ -32,16 +31,17 @@ Then you need to fill in your information and select **"Buy for my own use"** (d
|
||||
|
||||
|
||||
## 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.
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
@ -8,10 +8,10 @@ This category is dedicated to creating a VM with Docker support.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
* XenServer 6.5 or higher
|
||||
* Plugin installation (see below)
|
||||
* CoreOS ISO ([download it here](http://stable.release.core-os.net/amd64-usr/current/coreos_production_iso_image.iso)) for CoreOS installations
|
||||
* Xen Orchestra 4.10 or newer
|
||||
- XenServer 6.5 or higher
|
||||
- Plugin installation (see below)
|
||||
- CoreOS ISO ([download it here](http://stable.release.core-os.net/amd64-usr/current/coreos_production_iso_image.iso)) for CoreOS installations
|
||||
- Xen Orchestra 4.10 or newer
|
||||
|
||||
## Docker plugin installation
|
||||
|
||||
@ -49,8 +49,8 @@ That's it! You can now enjoy Docker support!
|
||||
|
||||
There are two ways to use the newly exposed Docker features:
|
||||
|
||||
* Install a CoreOS VM
|
||||
* Transform an existing VM into a supported Docker VM
|
||||
- Install a CoreOS VM
|
||||
- Transform an existing VM into a supported Docker VM
|
||||
|
||||
### CoreOS
|
||||
|
||||
@ -80,7 +80,6 @@ And replace it with your actual SSH public key:
|
||||
|
||||
`- ssh-rsa AAAA....kuGgQ me@mypc`
|
||||
|
||||
|
||||
The rest of the configuration is identical to any other VM. Just click on "Create VM" and you are done. After a few seconds, your VM will be ready. Nothing else to do!
|
||||
|
||||
You can see it thanks to the docker logo in the main view:
|
||||
@ -165,10 +164,10 @@ During the VM creation, the XSContainer plugin will create an extra disk: "Autom
|
||||
|
||||
Basically, it reads configuration during the boot, allowing:
|
||||
|
||||
* SSH key management for newly created VM/instances
|
||||
* Root disk filesystem growing
|
||||
* User/group management
|
||||
* Arbitrary command execution (system update, custom scripts etc.)
|
||||
- SSH key management for newly created VM/instances
|
||||
- Root disk filesystem growing
|
||||
- User/group management
|
||||
- Arbitrary command execution (system update, custom scripts etc.)
|
||||
|
||||
In our case, it's used by the XSContainer plugin to allow host communication to the Docker daemon running in the VM, thus exposing Docker commands outside of the VM.
|
||||
|
||||
@ -178,9 +177,9 @@ You can also use the XSContainer plugin to "transform" an existing VM into a "Do
|
||||
|
||||
You need to have the following installed inside the VM:
|
||||
|
||||
* Docker
|
||||
* openssh-server
|
||||
* ncat
|
||||
- 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`.
|
||||
|
||||
|
||||
@ -2,10 +2,10 @@
|
||||
|
||||
There are 4 **editions** of the Xen Orchestra Appliance (XOA):
|
||||
|
||||
* Free
|
||||
* Starter
|
||||
* Enterprise
|
||||
* Premium
|
||||
- Free
|
||||
- Starter
|
||||
- Enterprise
|
||||
- Premium
|
||||
|
||||
**Also, you can try all features in the Premium Edition for free (without any commitment) for 15 days by registering a trial. [Read here for trial instructions](trial.md).**
|
||||
|
||||
@ -13,11 +13,11 @@ There are 4 **editions** of the Xen Orchestra Appliance (XOA):
|
||||
|
||||
This is the basic edition, allowing you to perform administrator tasks on a virtualized infrastructure. It's "like" XenCenter. You can:
|
||||
|
||||
* Create VMs, SRs etc.
|
||||
* Access to VM consoles (HTML5 web based!)
|
||||
* Edit resources (VM, pools etc.)
|
||||
* Make snapshots
|
||||
* Migrate VMs
|
||||
- Create VMs, SRs etc.
|
||||
- Access to VM consoles (HTML5 web based!)
|
||||
- Edit resources (VM, pools etc.)
|
||||
- Make snapshots
|
||||
- Migrate VMs
|
||||
|
||||
That's more or less the same features you can see on the [administration page](administration.md).
|
||||
|
||||
@ -27,10 +27,10 @@ The Starter Edition is intended for system administrators who want to do more wi
|
||||
|
||||
In addition to the free edition, you get:
|
||||
|
||||
* [Scheduled backups](full_backups.md)
|
||||
* [Scheduled snapshots](rolling_snapshots.md)
|
||||
* Patch detection and application in one click (even to whole pools at once!)
|
||||
* XenServer Docker management via XenServer plugin
|
||||
- [Scheduled backups](full_backups.md)
|
||||
- [Scheduled snapshots](rolling_snapshots.md)
|
||||
- Patch detection and application in one click (even to whole pools at once!)
|
||||
- XenServer Docker management via XenServer plugin
|
||||
|
||||
You'll also have access to our ticket system to report issues and be helped in less than 72h.
|
||||
|
||||
@ -38,10 +38,10 @@ You'll also have access to our ticket system to report issues and be helped in l
|
||||
|
||||
The Enterprise Edition allows you to access a lot more features than Starter:
|
||||
|
||||
* Disaster Recovery
|
||||
* Continuous Delta Backup
|
||||
* Live stats
|
||||
* ACLs + LDAP/SSO
|
||||
- Disaster Recovery
|
||||
- Continuous Delta Backup
|
||||
- Live stats
|
||||
- ACLs + LDAP/SSO
|
||||
|
||||
In addition, you'll have faster support to answer your issues/questions (48h or less).
|
||||
|
||||
@ -49,10 +49,10 @@ In addition, you'll have faster support to answer your issues/questions (48h or
|
||||
|
||||
Premium is the highest edition, with all features included without any limitations. This means:
|
||||
|
||||
* Dataviz
|
||||
* Infrastructure health check
|
||||
* Job Manager
|
||||
* Continuous Replication
|
||||
* Self Service
|
||||
- Dataviz
|
||||
- Infrastructure health check
|
||||
- Job Manager
|
||||
- Continuous Replication
|
||||
- Self Service
|
||||
|
||||
Along with the fastest guaranteed support - 24 hours or less (typically much less).
|
||||
Along with the fastest guaranteed support - 24 hours or less (typically much less).
|
||||
|
||||
@ -3,11 +3,12 @@
|
||||
If you have a UPS for your hosts, and lose power, you may have a limited amount of time to shut down all of your VM infrastructure before the batteries run out. If you find yourself in this situation, or any other situation requiring the fast shutdown of everything, you can use the **Emergency Shutdown** feature.
|
||||
|
||||
## How to activate
|
||||
On the host view, clicking on this button will trigger the _Emergency Shutdown_ procedure:
|
||||
|
||||
On the host view, clicking on this button will trigger the _Emergency Shutdown_ procedure:
|
||||
|
||||
|
||||
|
||||
1. **All running VMs will be suspended** (think of it like "hibernate" on your laptop: the RAM will be stored in the storage repository).
|
||||
1. **All running VMs will be suspended** (think of it like "hibernate" on your laptop: the RAM will be stored in the storage repository).
|
||||
2. Only after this is complete, the host will be halted.
|
||||
|
||||
Here, you can see the running VMs are being suspended:
|
||||
@ -21,6 +22,7 @@ And finally, that's it. They are cleanly shut down with the RAM saved to disk to
|
||||
Now the host is halted automatically.
|
||||
|
||||
## Powering back on
|
||||
|
||||
When the power outage is over, all you need to do is:
|
||||
|
||||
1. Start your host.
|
||||
|
||||
@ -4,17 +4,17 @@ All the following features are exposed through the web client, XO-Web, which is
|
||||
|
||||
We've made multiple categories to help you to find what you need:
|
||||
|
||||
* [XenServer Administration](administration.html)
|
||||
* [Docker Support](docker_support.html)
|
||||
* [Backups](backups.html)
|
||||
* [Disaster Recovery](disaster_recovery.html)
|
||||
* [Resources delegation](resources_delegation.html)
|
||||
* [CloudInit](cloudinit.md)
|
||||
* [Self Service](self_service.html)
|
||||
* [Visualizations](visualizations.html)
|
||||
* [Job Manager](scheduler.html)
|
||||
* [Alerts](alerts.html)
|
||||
* [Load balancing](load_balancing.html)
|
||||
* [SDN Controller](sdn_controller.html)
|
||||
- [XenServer Administration](administration.html)
|
||||
- [Docker Support](docker_support.html)
|
||||
- [Backups](backups.html)
|
||||
- [Disaster Recovery](disaster_recovery.html)
|
||||
- [Resources delegation](resources_delegation.html)
|
||||
- [CloudInit](cloudinit.md)
|
||||
- [Self Service](self_service.html)
|
||||
- [Visualizations](visualizations.html)
|
||||
- [Job Manager](scheduler.html)
|
||||
- [Alerts](alerts.html)
|
||||
- [Load balancing](load_balancing.html)
|
||||
- [SDN Controller](sdn_controller.html)
|
||||
|
||||
|
||||
|
||||
@ -18,4 +18,4 @@ Then, click on the VM where your files are, and follow the instructions:
|
||||
|
||||
|
||||
|
||||
That's it! Your chosen file will be restored.
|
||||
That's it! Your chosen file will be restored.
|
||||
|
||||
@ -88,6 +88,7 @@ The only part you need to launch is xo-server, which is quite easy to do. From t
|
||||
```
|
||||
$ yarn start
|
||||
```
|
||||
|
||||
That's it! Use your browser to visit the xo-server IP address, and it works! :)
|
||||
|
||||
## Updating
|
||||
@ -102,6 +103,7 @@ $ git pull --ff-only
|
||||
$ yarn
|
||||
$ yarn build
|
||||
```
|
||||
|
||||
Then restart Xen Orchestra if it was running.
|
||||
|
||||
## Always Running
|
||||
@ -114,7 +116,7 @@ yarn global add forever
|
||||
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:
|
||||
- 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
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
# Common errors and troubleshooting
|
||||
|
||||
## Recommendation
|
||||
If you think you have a problem with your XOA, start by typing`xoa check`command in your terminal:
|
||||
|
||||
If you think you have a problem with your XOA, start by typing`xoa check`command in your terminal:
|
||||
|
||||
```
|
||||
$ xoa check
|
||||
@ -12,27 +13,29 @@ $ xoa check
|
||||
✔ xo-server config syntax
|
||||
✔ Appliance registration
|
||||
✔ Internet connectivity
|
||||
```
|
||||
```
|
||||
|
||||
If the result you have is completely different from that, or if error messages are displayed, lost packets, etc., you have, indeed, a problem. The next step should be to check in this document if there is an existing troubleshooting for the problem you have.
|
||||
|
||||
> You can also access the log by using this command: `$ tail -f /var/log/syslog` ([learn more](https://xen-orchestra.com/docs/logs.html))
|
||||
|
||||
## General
|
||||
|
||||
* [Empty page after login](https://xen-orchestra.com/docs/troubleshooting.html#empty-page-after-login)
|
||||
* [Can't migrate XOA](https://xen-orchestra.com/docs/troubleshooting.html#xoa-migration-issues)
|
||||
* [Can't boot XOA](https://xen-orchestra.com/docs/troubleshooting.html#xoa-boot-issues)
|
||||
* [Network issues](https://xen-orchestra.com/docs/troubleshooting.html#network-issues)
|
||||
* [Out of memory](https://xen-orchestra.com/docs/troubleshooting.html#memory)
|
||||
* [Transparent proxy and updater](https://xen-orchestra.com/docs/troubleshooting.html#behind-a-transparent-proxy)
|
||||
* [SSL self-signed certificate expired](https://xen-orchestra.com/docs/troubleshooting.html#updating-ssl-self-signed-certificate)
|
||||
* [User authentication](https://xen-orchestra.com/docs/authentication.html#debugging)
|
||||
- [Empty page after login](https://xen-orchestra.com/docs/troubleshooting.html#empty-page-after-login)
|
||||
- [Can't migrate XOA](https://xen-orchestra.com/docs/troubleshooting.html#xoa-migration-issues)
|
||||
- [Can't boot XOA](https://xen-orchestra.com/docs/troubleshooting.html#xoa-boot-issues)
|
||||
- [Network issues](https://xen-orchestra.com/docs/troubleshooting.html#network-issues)
|
||||
- [Out of memory](https://xen-orchestra.com/docs/troubleshooting.html#memory)
|
||||
- [Transparent proxy and updater](https://xen-orchestra.com/docs/troubleshooting.html#behind-a-transparent-proxy)
|
||||
- [SSL self-signed certificate expired](https://xen-orchestra.com/docs/troubleshooting.html#updating-ssl-self-signed-certificate)
|
||||
- [User authentication](https://xen-orchestra.com/docs/authentication.html#debugging)
|
||||
|
||||
## Backup troubleshooting
|
||||
|
||||
* [Unhealthy VDI chain](https://xen-orchestra.com/docs/backup_troubleshooting.html#unhealthy-vdi-chain)
|
||||
* [SR_backend_failure_44](https://xen-orchestra.com/docs/backup_troubleshooting.html#srbackendfailure44-insufficient-space)
|
||||
* [Could not find the base VM](https://xen-orchestra.com/docs/backup_troubleshooting.html#could-not-find-the-base-vm)
|
||||
- [Unhealthy VDI chain](https://xen-orchestra.com/docs/backup_troubleshooting.html#unhealthy-vdi-chain)
|
||||
- [SR_backend_failure_44](https://xen-orchestra.com/docs/backup_troubleshooting.html#srbackendfailure44-insufficient-space)
|
||||
- [Could not find the base VM](https://xen-orchestra.com/docs/backup_troubleshooting.html#could-not-find-the-base-vm)
|
||||
|
||||
## You haven't found a solution here?
|
||||
|
||||
Open a ticket concerning your issue on your personal space [here](https://xen-orchestra.com/#!/member/support)
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
# Glossary
|
||||
|
||||
* CPU: Processor
|
||||
* HA: High Availability
|
||||
* HVM: Hardware virtualization
|
||||
* MTU: largest size packet that can be sent in the network
|
||||
* OS: Operating System
|
||||
* PIF: Physical Network Interface
|
||||
* PVM: Paravirtualization
|
||||
* SR: Storage Repository
|
||||
* vCPU: Virtual Processor
|
||||
* VDI: Virtual Disk Image
|
||||
* VIF: Virtual Network Interface
|
||||
* VM: Virtual Machine
|
||||
* XO: Xen Orchestra
|
||||
* XOA: Xen Orchestra Appliance
|
||||
- CPU: Processor
|
||||
- HA: High Availability
|
||||
- HVM: Hardware virtualization
|
||||
- MTU: largest size packet that can be sent in the network
|
||||
- OS: Operating System
|
||||
- PIF: Physical Network Interface
|
||||
- PVM: Paravirtualization
|
||||
- SR: Storage Repository
|
||||
- vCPU: Virtual Processor
|
||||
- VDI: Virtual Disk Image
|
||||
- VIF: Virtual Network Interface
|
||||
- VM: Virtual Machine
|
||||
- XO: Xen Orchestra
|
||||
- XOA: Xen Orchestra Appliance
|
||||
|
||||
@ -4,7 +4,6 @@ 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):
|
||||
@ -24,9 +23,9 @@ Add OAuth 2.0 credentials:
|
||||
|
||||
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`
|
||||
- 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`
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
|
||||
# Installation
|
||||
|
||||
Log in to your account and use the deploy form available on [this page](https://xen-orchestra.com/#!/xoa)
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
# LDAP
|
||||
|
||||
XO currently supports connections to LDAP directories, like *Open LDAP* or *Active Directory*.
|
||||
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:
|
||||
To configure your LDAP, you need to go into the _Plugins_ section in the "Settings" view. Then configure it:
|
||||
|
||||
|
||||
|
||||
@ -12,8 +12,8 @@ Don't forget to save the configuration, and also check if the plugin is activate
|
||||
|
||||
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.
|
||||
- `'(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.
|
||||
|
||||
|
||||
@ -12,18 +12,18 @@ In this coming new view, you'll be able to configure a new load balancing plan,
|
||||
|
||||
A plan has:
|
||||
|
||||
* a name
|
||||
* pool(s) where to apply the policy
|
||||
* a mode (see paragraph below)
|
||||
* a behavior (aggressive, normal, low)
|
||||
- a name
|
||||
- pool(s) where to apply the policy
|
||||
- a mode (see paragraph below)
|
||||
- a behavior (aggressive, normal, low)
|
||||
|
||||
### Plan modes
|
||||
|
||||
There are 3 modes possible:
|
||||
|
||||
* performance
|
||||
* density
|
||||
* mixed
|
||||
- performance
|
||||
- density
|
||||
- mixed
|
||||
|
||||
#### Performance
|
||||
|
||||
@ -37,8 +37,8 @@ This time, the objective is to use the least hosts possible, and to concentrate
|
||||
|
||||
This mode allows you to use both performance and density, but alternatively, depending of a schedule. E.g:
|
||||
|
||||
* **performance** from 6:00 AM to 7:00 PM
|
||||
* **density** from 7:01 PM to 5:59 AM
|
||||
- **performance** from 6:00 AM to 7:00 PM
|
||||
- **density** from 7:01 PM to 5:59 AM
|
||||
|
||||
In this case, you'll have the best of both when needed (energy saving during the night and performance during the day).
|
||||
|
||||
@ -46,8 +46,8 @@ In this case, you'll have the best of both when needed (energy saving during the
|
||||
|
||||
In a plan, you can configure various thresholds:
|
||||
|
||||
* CPU threshold
|
||||
* Free memory
|
||||
- CPU threshold
|
||||
- Free memory
|
||||
|
||||
If the CPU threshold is set to 90%, the load balancer will be only triggered if the average CPU usage on a host is more than 90%.
|
||||
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
|
||||
# Logs
|
||||
|
||||
This section will explain how to check the XOA logs, and use them to detect issues.
|
||||
|
||||
@ -8,8 +8,8 @@ XCP-ng and Citrix Hypervisor (Xenserver) hosts use a database to store metadata
|
||||
|
||||
In Xen Orchestra, Metadata backup is divided into two different options:
|
||||
|
||||
* Pool metadata backup
|
||||
* XO configuration backup
|
||||
- Pool metadata backup
|
||||
- XO configuration backup
|
||||
|
||||
### Performing a backup
|
||||
|
||||
@ -28,7 +28,6 @@ Once created, the job is displayed with the other classic jobs.
|
||||
|
||||
|
||||
|
||||
|
||||
### 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).
|
||||
@ -45,4 +44,4 @@ You can see both our Xen Orchestra config backup, and our pool metadata backup.
|
||||
|
||||
|
||||
|
||||
That's it!
|
||||
That's it!
|
||||
|
||||
@ -1,20 +1,19 @@
|
||||
|
||||
# Others
|
||||
|
||||
We already have other modules in place, e.g for authentication, like a LDAP, SAML, Google or GitHub as external providers.
|
||||
|
||||
If you want to understand how modules work, have a look here:
|
||||
|
||||
* [LDAP plugin](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-server-auth-ldap)
|
||||
* [GitHub authentication](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-server-auth-github)
|
||||
- [LDAP plugin](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-server-auth-ldap)
|
||||
- [GitHub authentication](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-server-auth-github)
|
||||
|
||||
XO's API can be explored through the `xo-cli` client (please refer to the previous section for details).
|
||||
|
||||
There are modules for a lot of various tasks, like:
|
||||
|
||||
* performance analysis
|
||||
* reporting
|
||||
* load management
|
||||
* various authentication providers
|
||||
- performance analysis
|
||||
- reporting
|
||||
- load management
|
||||
- various authentication providers
|
||||
|
||||
Check your Settings/Plugins view in XOA to see them.
|
||||
|
||||
@ -6,18 +6,18 @@ Patching a host manually can be time consuming (and boring). That's why we provi
|
||||
|
||||
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)
|
||||
- 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
|
||||
- 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/
|
||||
|
||||
@ -25,8 +25,8 @@ You can see more screenshots here: https://xen-orchestra.com/blog/hotfix-xs70e00
|
||||
|
||||
## 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**.
|
||||
- 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**.
|
||||
|
||||
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
|
||||
# Plugins
|
||||
|
||||
Xen Orchestra plugins allow you to extend features without rewriting the core of the application.
|
||||
@ -13,6 +12,6 @@ All plugin configuration should be done in the web interface:
|
||||
|
||||
A plugin can be:
|
||||
|
||||
* activated/deactivated
|
||||
* loaded on start of the application
|
||||
* configured (extend the plugin settings by clicking on the "+" icon
|
||||
- activated/deactivated
|
||||
- loaded on start of the application
|
||||
- configured (extend the plugin settings by clicking on the "+" icon
|
||||
|
||||
@ -2,9 +2,9 @@
|
||||
|
||||
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)](directpurchase.md)
|
||||
- [through your purchase department (purchaser)](through_purchase_department.md)
|
||||
- [for your own client (reseller)](reseller.md)
|
||||
|
||||
## XOA Editions
|
||||
|
||||
@ -16,16 +16,16 @@ Invoices are available in PDF format. [Details here](invoices.md).
|
||||
|
||||
## Receiving a quote
|
||||
|
||||
You can ask for an automatic quote on our website via the pricing page or directly from you personal account page.
|
||||
You can ask for an automatic quote on our website via the pricing page or directly from you personal account page.
|
||||
|
||||
|
||||
|
||||
Choose the plan you want, the years of commitment that suits you, then fill out the information required (it should be prefilled with your account information).
|
||||
Choose the plan you want, the years of commitment that suits you, then fill out the information required (it should be prefilled with your account information).
|
||||
|
||||
If you want to purchase XO using the quote you receive, you just have to enter the quote number into the purchase menu, on your personal account page.
|
||||
If you want to purchase XO using the quote you receive, you just have to enter the quote number into the purchase menu, on your personal account page.
|
||||
|
||||
## Edit your card information
|
||||
|
||||
If you choose a Stripe payment, you can always edit the credit card information in case it changes. To do so, you only have to login to your personal account page and access the *profile* menu.
|
||||
If you choose a Stripe payment, you can always edit the credit card information in case it changes. To do so, you only have to login to your personal account page and access the _profile_ menu.
|
||||
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
# Xen Orchestra Partner Program
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
> 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.
|
||||
> 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
|
||||
|
||||
@ -22,7 +22,7 @@ Now that you can see the reseller interface:
|
||||
|
||||
|
||||
|
||||
You can follow these steps to purchase an XOA edition for your customer.
|
||||
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)
|
||||
|
||||
@ -4,11 +4,11 @@ This chapter covers how to delegate resources (VM, hosts, etc) to users.
|
||||
|
||||
The idea is to allow external users (not admins) to:
|
||||
|
||||
* interact only with their objects
|
||||
* delegate VMs to your dev teams...
|
||||
* ... or to your clients
|
||||
- interact only with their objects
|
||||
- delegate VMs to your dev teams...
|
||||
- ... or to your clients
|
||||
|
||||
> Remember: admins can do everything, thus permissions don't apply on them. It's only for *users*.
|
||||
> Remember: admins can do everything, thus permissions don't apply on them. It's only for _users_.
|
||||
|
||||
## Groups
|
||||
|
||||
|
||||
@ -2,8 +2,7 @@
|
||||
|
||||
## 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.
|
||||
|
||||
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!:
|
||||
|
||||
@ -16,12 +15,10 @@ 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
|
||||
|
||||
@ -1,13 +1,12 @@
|
||||
# Roadmap
|
||||
|
||||
> Our roadmap is very flexible - you can check the **milestones** repository for a complete overview of all the features we are currently working on.
|
||||
> Our roadmap is very flexible - you can check the **milestones** repository for a complete overview of all the features we are currently working on.
|
||||
|
||||
## Features
|
||||
|
||||
- [Milestones](https://github.com/vatesfr/xen-orchestra/milestones)
|
||||
- [Alerts and reports](alerts.md)
|
||||
|
||||
|
||||
## Fixes
|
||||
|
||||
- [Known bugs](https://github.com/vatesfr/xen-orchestra/issues?q=is%3Aopen+is%3Aissue+label%3A%22type%3A+bug%22)
|
||||
|
||||
@ -12,6 +12,6 @@ This feature is similar to Backups, but it creates a snapshot when planned to do
|
||||
|
||||
Example:
|
||||
|
||||
* 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
|
||||
* And so forth!
|
||||
- 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
|
||||
- And so forth!
|
||||
|
||||
@ -35,20 +35,20 @@ The possibilities are infinite! You can schedule a **lot** of things (any action
|
||||
|
||||
### 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
|
||||
- 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)
|
||||
- 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!
|
||||
- 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
|
||||
- revoke your user ACLs Friday at 11:00PM (e.g: no access on the weekend)
|
||||
- restore them Monday at 6:00AM
|
||||
|
||||
@ -15,6 +15,7 @@ Please read the [dedicated devblog on the SDN Controller](https://xen-orchestra.
|
||||
### Network creation
|
||||
|
||||
In the network creation view:
|
||||
|
||||
- Select a `pool`
|
||||
- Select `Private network`
|
||||
- Select an interface on which to create the network's tunnels
|
||||
@ -25,9 +26,10 @@ In the network creation view:
|
||||
- Create the network
|
||||
- Have fun! ☺
|
||||
|
||||
***NB:***
|
||||
**_NB:_**
|
||||
|
||||
- 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.
|
||||
> 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
|
||||
@ -36,8 +38,9 @@ Like all other xo-server plugins, it can be configured directly via
|
||||
the web interface, see [the plugin documentation](https://xen-orchestra.com/docs/plugins.html).
|
||||
|
||||
The plugin's configuration contains:
|
||||
|
||||
- `cert-dir`: The path where the plugin will look for the certificates to create SSL connections with the hosts.
|
||||
If none is provided, the plugin will create its own self-signed certificates.
|
||||
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
|
||||
@ -57,4 +60,4 @@ If none is provided, the plugin will create its own self-signed certificates.
|
||||
- `systemctl enable ipsec`
|
||||
- `systemctl enable openvswitch-ipsec`
|
||||
- `systemctl start ipsec`
|
||||
- `systemctl start openvswitch-ipsec`
|
||||
- `systemctl start openvswitch-ipsec`
|
||||
|
||||
@ -2,10 +2,10 @@
|
||||
|
||||
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
|
||||
- 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!
|
||||
|
||||
@ -112,10 +112,9 @@ Postfix the name of a property by a question mark `?`:
|
||||
|
||||
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)
|
||||
|
||||
- `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
|
||||
|
||||
|
||||
@ -12,15 +12,15 @@ To create a new set of resources to delegate, go to the "Self Service" section i
|
||||
|
||||
> 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.
|
||||
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
|
||||
- "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
|
||||
|
||||
|
||||
|
||||
@ -32,11 +32,11 @@ As you can see, only compatible hosts are shown and can be used for this resourc
|
||||
|
||||
Then, you can define quotas on this set:
|
||||
|
||||
* max vCPUs
|
||||
* max RAM
|
||||
* max disk usage
|
||||
- max vCPUs
|
||||
- max RAM
|
||||
- max disk usage
|
||||
|
||||
> Note: Snapshotting a VM within a self-service will use the quota from the resource set. The same rule applies for backups and replication.
|
||||
> Note: Snapshotting a VM within a self-service will 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:
|
||||
|
||||
@ -44,7 +44,7 @@ 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".
|
||||
As soon as a user is granted a resource set, it displays a new button in their main view: "new".
|
||||
|
||||
|
||||
|
||||
@ -60,14 +60,13 @@ If the "Create" button is disabled, it means the user requested more resources t
|
||||
|
||||
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
|
||||
- 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!
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ There are two ways to select which VMs will be backed up:
|
||||
|
||||
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!
|
||||
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
|
||||
|
||||
@ -25,8 +25,8 @@ Want to narrow the job a bit? See below.
|
||||
|
||||
You can also:
|
||||
|
||||
* backup only running (or halted) VMs when the job is executed
|
||||
* backup only VMs with a specific tag
|
||||
- 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:
|
||||
|
||||
|
||||
@ -4,10 +4,10 @@ Xen Orchestra will run in a controlled/tested environment thanks to XOA ([Xen Or
|
||||
|
||||
XOA is available in multiple plans:
|
||||
|
||||
* Free
|
||||
* Starter
|
||||
* Enterprise
|
||||
* Premium
|
||||
- Free
|
||||
- Starter
|
||||
- Enterprise
|
||||
- Premium
|
||||
|
||||
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).
|
||||
|
||||
@ -19,8 +19,8 @@ With the free version of the Xen Orchestra Appliance (XOA free), you can open su
|
||||
|
||||
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`
|
||||
- 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.
|
||||
|
||||
|
||||
@ -6,20 +6,20 @@ Xen Orchestra is designed to work exclusively on [XCP-ng](https://xcp-ng.org/) a
|
||||
|
||||
Backup restore for large VM disks (>1TiB usage) is [broken on all XenServer versions](https://bugs.xenserver.org/browse/XSO-868) until Citrix release a fix.
|
||||
|
||||
* 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
|
||||
* 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
|
||||
- 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
|
||||
- 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
|
||||
|
||||
|
||||
|
||||
@ -27,8 +27,8 @@ Backup restore for large VM disks (>1TiB usage) is [broken on all XenServer vers
|
||||
|
||||
All the pending fixes are already integrated in the latest XCP-ng version. We strongly suggest people to keep using the latest XCP-ng version as far as possible.
|
||||
|
||||
* XCP-ng 7.6
|
||||
* XCP-ng 7.5
|
||||
* XCP-ng 7.4.1
|
||||
- XCP-ng 7.6
|
||||
- XCP-ng 7.5
|
||||
- XCP-ng 7.4.1
|
||||
|
||||
|
||||
|
||||
@ -4,29 +4,25 @@ If you can't purchase using your own account, usually because you need to go thr
|
||||
|
||||
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.
|
||||
- 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.
|
||||
|
||||
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.
|
||||
That's it, you have now completed the purchase.
|
||||
|
||||
**⚠ 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.**
|
||||
|
||||
@ -1,13 +1,12 @@
|
||||
|
||||
# Trial activation
|
||||
|
||||
A trial will allow you to test all available features in XOA, for 15 days.
|
||||
|
||||
The procedure is very simple:
|
||||
|
||||
* register, then download a Free Edition [on our website](https://xen-orchestra.com/#/member)
|
||||
* [deploy the virtual appliance](xoa.md)
|
||||
* activate the trial via the "Update" view (details below)
|
||||
- register, then download a Free Edition [on our website](https://xen-orchestra.com/#/member)
|
||||
- [deploy the virtual appliance](xoa.md)
|
||||
- activate the trial via the "Update" view (details below)
|
||||
|
||||
## Activate the trial
|
||||
|
||||
|
||||
@ -12,10 +12,9 @@ It means you don't have a default SR set on the pool you are importing XOA on. T
|
||||
|
||||
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
|
||||
|
||||
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:
|
||||
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:
|
||||
|
||||
`xo-server-recover-account youremail@here.com`
|
||||
|
||||
@ -69,7 +68,7 @@ If you have something completely different than that, or error messages, lost pa
|
||||
|
||||
You can see your current network configuration by running `ifconfig eth0`. If you have an external firewall, please check that you allow the XOA's IP.
|
||||
|
||||
You can modify the IP configuration with `xoa network static` (for a static IP address) or ` xoa network dhcp` to use DHCP.
|
||||
You can modify the IP configuration with `xoa network static` (for a static IP address) or `xoa network dhcp` to use DHCP.
|
||||
|
||||
### Memory
|
||||
|
||||
@ -120,6 +119,7 @@ $ echo NODE_TLS_REJECT_UNAUTHORIZED=0 >> /etc/xo-appliance/env
|
||||
$ npm config -g set strict-ssl=false
|
||||
$ systemctl restart xoa-updater
|
||||
```
|
||||
|
||||
Now try running an update again.
|
||||
|
||||
### Updating SSL self-signed certificate
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
|
||||
# Updater
|
||||
|
||||
The updater is the central piece that keeps your XO Appliance running the latest Xen Orchestra code.
|
||||
@ -42,9 +41,11 @@ However, if you want to start a manual check, you can do it by clicking on the "
|
||||
|
||||
|
||||
#### Release channel
|
||||
|
||||
In Xen Orchestra, you can make a choice between two different release channels.
|
||||
|
||||
##### 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
|
||||
@ -119,7 +120,7 @@ If your updater is down, you can restart it with `systemctl restart xoa-updater`
|
||||
|
||||
If you can't fetch updates, perform a few checks from your XOA:
|
||||
|
||||
* you should be able to successfully `ping xen-orchestra.com`
|
||||
* if not, check your `/etc/resolv.conf` file and modify it if necessary (give a correct DNS server)
|
||||
* use `ifconfig` to check your network configuration
|
||||
* check your firewall(s) and allow XOA to reach xen-orchestra.com (port 443)
|
||||
- you should be able to successfully `ping xen-orchestra.com`
|
||||
- if not, check your `/etc/resolv.conf` file and modify it if necessary (give a correct DNS server)
|
||||
- use `ifconfig` to check your network configuration
|
||||
- check your firewall(s) and allow XOA to reach xen-orchestra.com (port 443)
|
||||
|
||||
@ -1,34 +1,33 @@
|
||||
# How to uprade your active plan?
|
||||
|
||||
If you want to upgrade your active plan to a higher version of Xen Orchestra, you can do it from your **personal space**.
|
||||
If you want to upgrade your active plan to a higher version of Xen Orchestra, you can do it from your **personal space**.
|
||||
|
||||
### Step by step:
|
||||
|
||||
1. Connect on your personal account on the [website](https://xen-orchestra.com/#!/login?source=member.index).
|
||||
1. Connect on your personal account on the [website](https://xen-orchestra.com/#!/login?source=member.index).
|
||||
|
||||
|
||||
|
||||
2. Go on the purchase menu
|
||||
2. Go on the purchase menu
|
||||
|
||||
|
||||
|
||||
3. Pick the line corresponding to the account you want to upgrade. Click on the "upgrade" button on the right.
|
||||
3. Pick the line corresponding to the account you want to upgrade. Click on the "upgrade" button on the right.
|
||||
|
||||
|
||||
|
||||
4. At this point, you will see a standard subscription page. **Choose the same payment method you used to purchase the initial plan** and confirm the purchase.
|
||||
4. At this point, you will see a standard subscription page. **Choose the same payment method you used to purchase the initial plan** and confirm the purchase.
|
||||
|
||||
|
||||
|
||||
5. If you chosse wire transfer, you have now the possibility to download a quote. As you can see, the remaining period of your previous plan is now a credit note applied on this upgrade.
|
||||
5. If you chosse wire transfer, you have now the possibility to download a quote. As you can see, the remaining period of your previous plan is now a credit note applied on this upgrade.
|
||||
|
||||
|
||||
|
||||
6. As for a regular purchase, upload a proof of payment in order for us to activate your new plan as soon as possible.
|
||||
6. As for a regular purchase, upload a proof of payment in order for us to activate your new plan as soon as possible.
|
||||
|
||||
|
||||
|
||||
7. **Enjoy your new plan!**
|
||||
|
||||
|
||||
> As a reseller, the process is quite the same. The only difference is that you have to pick your customer line into you reseller space an not your personal space.
|
||||
> As a reseller, the process is quite the same. The only difference is that you have to pick your customer line into you reseller space an not your personal space.
|
||||
|
||||
@ -26,9 +26,9 @@ 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 
|
||||
- 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
|
||||
|
||||
|
||||
@ -36,7 +36,7 @@ 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.
|
||||
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:
|
||||
|
||||
@ -70,7 +70,7 @@ These templates will use PV configuration in order to boot: either from the righ
|
||||
|
||||
#### 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!
|
||||
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.
|
||||
|
||||
|
||||
@ -12,8 +12,8 @@ In the advanced tab, you have extra options:
|
||||
|
||||
### XenServer 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.
|
||||
- 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).
|
||||
|
||||
@ -53,11 +53,11 @@ If you pool supports HA (must have shared storage), you can activate "HA". Read
|
||||
|
||||
You can change the CPU Weight in the VM advanced view. The values are:
|
||||
|
||||
* Default
|
||||
* Quarter (64)
|
||||
* Half (128)
|
||||
* Normal (256)
|
||||
* Double (512)
|
||||
- Default
|
||||
- Quarter (64)
|
||||
- Half (128)
|
||||
- Normal (256)
|
||||
- Double (512)
|
||||
|
||||
By default, each VM has a weight of 256.
|
||||
|
||||
@ -71,8 +71,8 @@ VM copy allows you to make an export and an import via streaming. You can target
|
||||
|
||||
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
|
||||
- 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.
|
||||
|
||||
@ -8,16 +8,16 @@ 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
|
||||
- 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.
|
||||
|
||||
@ -43,7 +43,7 @@ The request's body is a JSON string representing an object with the following pr
|
||||
|
||||
## Request handling
|
||||
|
||||
*Quick Node.js example of how you may want to handle the requests*
|
||||
_Quick Node.js example of how you may want to handle the requests_
|
||||
|
||||
```js
|
||||
const http = require('http')
|
||||
@ -64,7 +64,11 @@ 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}`)
|
||||
console.log(
|
||||
`${new Date(
|
||||
timestamp
|
||||
).toISOString()} [${method}|${type}] ${params} → ${result || error}`
|
||||
)
|
||||
|
||||
// Run scripts
|
||||
exec(`./hook-scripts/${method}-${type}.sh`)
|
||||
|
||||
@ -35,7 +35,6 @@ Usage:
|
||||
|
||||
```
|
||||
|
||||
|
||||
#### Register your XO instance
|
||||
|
||||
```
|
||||
@ -74,8 +73,7 @@ Commands can be filtered using patterns:
|
||||
|
||||
#### Execute a command
|
||||
|
||||
The same syntax is used for all commands: `xo-cli <command> <param
|
||||
name>=<value>...`
|
||||
The same syntax is used for all commands: `xo-cli <command> <param name>=<value>...`
|
||||
|
||||
E.g., adding a new server:
|
||||
|
||||
@ -102,7 +100,8 @@ encoding by prefixing with `json:`:
|
||||
|
||||
##### VM import
|
||||
|
||||
```
|
||||
```
|
||||
> xo-cli vm.import sr=60a6939e-8b0a-4352-9954-5bde44bcdf7d @=vm.xva
|
||||
```
|
||||
|
||||
> Note: `xo-cli` only supports the import of XVA files. It will not import OVA files. To import OVA images, you must use the XOA web UI.
|
||||
|
||||
@ -1,7 +1,6 @@
|
||||
|
||||
# xo-server
|
||||
|
||||
XO-Server is the core of Xen Orchestra. Its central role opens a lot of possibilities versus other solutions - let's see why.
|
||||
XO-Server is the core of Xen Orchestra. Its central role opens a lot of possibilities versus other solutions - let's see why.
|
||||
|
||||
### Daemon mode
|
||||
|
||||
@ -57,7 +56,6 @@ Thanks to our architecture, it's now far easier:
|
||||
|
||||
|
||||
|
||||
|
||||
#### Patching on the fly
|
||||
|
||||
To install a patch manually, it requires a lot of steps: find, download, extract and apply the patch, sequentially.
|
||||
@ -68,7 +66,6 @@ To install a patch manually, it requires a lot of steps: find, download, extract
|
||||
2. unzip it and upload it on the fly to your host
|
||||
3. apply it as soon it's done
|
||||
|
||||
|
||||
### Pluggable
|
||||
|
||||
It's really easy to connect other modules to XO-server, and extend or adapt the solution to your needs (see XO-web and XO-cli for real examples).
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
|
||||
# xo-web
|
||||
|
||||
This is probably the first part of Xen Orchestra you'll see. The Web interface allows you to interact with your virtual infrastructure. As a module of XO-Web it facilitates everyday Xen administrator work, but also provides a solution to delegate parts of your infrastructure to other people.
|
||||
|
||||
55
docs/xoa.md
55
docs/xoa.md
@ -2,19 +2,19 @@
|
||||
|
||||
XOA is the Xen Orchestra Appliance. XOA is a Debian VM with:
|
||||
|
||||
* 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)
|
||||
- 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`)
|
||||
- 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.
|
||||
|
||||
@ -41,19 +41,21 @@ curl -sS https://xoa.io/deploy | bash
|
||||
> **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
|
||||
```
|
||||
> 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.
|
||||
- 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
|
||||
|
||||
@ -63,14 +65,13 @@ After the VM is imported, you just need to start it with `xe vm-start vm="XOA"`
|
||||
|
||||
## 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:
|
||||
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
|
||||
- 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).
|
||||
@ -79,11 +80,11 @@ Once you have started the VM, you can access the web UI by putting the IP you co
|
||||
|
||||
In your appliance, you can access the support section in the XOA menu. In this section you can:
|
||||
|
||||
* launch an `xoa check` command
|
||||
- launch an `xoa check` command
|
||||
|
||||
|
||||
|
||||
* Open a secure support tunnel so our team can remotely investigate
|
||||
- Open a secure support tunnel so our team can remotely investigate
|
||||
|
||||
|
||||
|
||||
@ -103,19 +104,18 @@ Give us this number, and we'll be able to access your XOA in a secure manner. Th
|
||||
|
||||
> 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`.
|
||||
|
||||
|
||||
### First console connection
|
||||
|
||||
If you connect via SSH or console, the default credentials are:
|
||||
|
||||
* user: xoa
|
||||
* password: xoa
|
||||
- user: xoa
|
||||
- password: xoa
|
||||
|
||||
During your first connection, the system will ask you to:
|
||||
|
||||
* enter the current password again (`xoa`)
|
||||
* enter your new password
|
||||
* retype your new password
|
||||
- enter the current password again (`xoa`)
|
||||
- enter your new password
|
||||
- retype your new password
|
||||
|
||||
When it's done, you'll be disconnected, so reconnect again with your new password.
|
||||
|
||||
@ -190,13 +190,12 @@ $ xoa network static
|
||||
? IP of the DNS server 192.168.100.254
|
||||
```
|
||||
|
||||
Xen Orchestra is now accessible in your browser at ` https://your-vm-ip`.
|
||||
Xen Orchestra is now accessible in your browser at `https://your-vm-ip`.
|
||||
|
||||
You can access the VM console through XenCenter or using VNC through a SSH tunnel.
|
||||
|
||||
If you want to go back in DHCP, just run `xoa network dhcp`
|
||||
|
||||
|
||||
### 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:
|
||||
|
||||
@ -16,10 +16,10 @@ XOSAN will "gather" all your local disks into a shared SR, that XenServer will j
|
||||
|
||||
The objectives are to:
|
||||
|
||||
* protect your data thanks to replication of data on multiple hosts
|
||||
* provide XenServer high availability without buying a NAS nor a SAN
|
||||
* give you flexibility to grow your storage by adding new nodes
|
||||
* work on all kind of hardware, from HDDs to SSDs, with hardware RAID or not
|
||||
- protect your data thanks to replication of data on multiple hosts
|
||||
- provide XenServer high availability without buying a NAS nor a SAN
|
||||
- give you flexibility to grow your storage by adding new nodes
|
||||
- work on all kind of hardware, from HDDs to SSDs, with hardware RAID or not
|
||||
|
||||
## Beta access - Phase II
|
||||
|
||||
@ -34,8 +34,8 @@ To activate you XOSAN beta, just go in the **"XOSAN"** menu in your (up-to-date)
|
||||
|
||||
To deploy XOSAN, please follow the rest of the documentation:
|
||||
|
||||
* [XOSAN Requirements](xosan_requirements.md)
|
||||
* [Types of XOSAN](xosan_types.md)
|
||||
* [How to create a new XOSAN Storage](xosan_create.md)
|
||||
* [XOSAN management](xosan_management.md)
|
||||
* [Get a free XOSAN trial](xosan_trial.md)
|
||||
- [XOSAN Requirements](xosan_requirements.md)
|
||||
- [Types of XOSAN](xosan_types.md)
|
||||
- [How to create a new XOSAN Storage](xosan_create.md)
|
||||
- [XOSAN management](xosan_management.md)
|
||||
- [Get a free XOSAN trial](xosan_trial.md)
|
||||
|
||||
@ -4,33 +4,32 @@
|
||||
|
||||
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)
|
||||
- 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
|
||||
- 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
@ -46,22 +45,23 @@ After the completion of all the requirements, you can install XOSAN itself.
|
||||
|
||||
### Advanced options
|
||||
|
||||
With the advanced option, you can:
|
||||
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 VLAN
|
||||
|
||||
* use a custom IP network
|
||||
> If you want to use a VLAN, don't forget to configure your switch as well!
|
||||
|
||||
* change the total size you want for your shared storage
|
||||
- use a custom IP network
|
||||
|
||||
* 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.
|
||||
- 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.
|
||||
> The process can take a few minutes to complete.
|
||||
|
||||
|
||||
|
||||
@ -4,15 +4,15 @@ Data are **chunked and dispersed** on multiple nodes. There is a kind of "parity
|
||||
|
||||
Pros:
|
||||
|
||||
* good capacity (perfect for **HDD storage**)
|
||||
* simple to setup
|
||||
* simple to maintain
|
||||
* various level of protection
|
||||
- good capacity (perfect for **HDD storage**)
|
||||
- simple to setup
|
||||
- simple to maintain
|
||||
- various level of protection
|
||||
|
||||
Cons:
|
||||
|
||||
* not all configrations possible (3, 5, 6 nodes and more)
|
||||
* limited performances on SSDs (replication is better in this case)
|
||||
- not all configrations possible (3, 5, 6 nodes and more)
|
||||
- limited performances on SSDs (replication is better in this case)
|
||||
|
||||
![pictore disperse principle]()
|
||||
|
||||
@ -44,7 +44,7 @@ It's very similar to **RAID6**. You can lose up to 2 nodes, it will continue to
|
||||
|
||||
You can grow a replicated XOSAN by adding extra disperse volumes, in other words a new disperse will be like in RAID 0 with the old one. It's a **distributed-disperse** type. Some examples:
|
||||
|
||||
* To grow a disperse 3, you need 3 new nodes. You'll add the total capacity of each disperse to make a distributed-disperse on 2x3 dispersed nodes.
|
||||
* To grow a disperse 6, you need 6 new nodes.
|
||||
- To grow a disperse 3, you need 3 new nodes. You'll add the total capacity of each disperse to make a distributed-disperse on 2x3 dispersed nodes.
|
||||
- To grow a disperse 6, you need 6 new nodes.
|
||||
|
||||
|
||||
|
||||
@ -4,13 +4,13 @@ Data are replicated from a node to another.
|
||||
|
||||
Pros:
|
||||
|
||||
* fast (**must be used for SSDs**)
|
||||
* relatively flexible
|
||||
- fast (**must be used for SSDs**)
|
||||
- relatively flexible
|
||||
|
||||
Cons:
|
||||
|
||||
* lower capacity (so higher cost, better for SSDs)
|
||||
* a bit more complex to maintain in distributed-replicated (see "RAID 10 like")
|
||||
- lower capacity (so higher cost, better for SSDs)
|
||||
- a bit more complex to maintain in distributed-replicated (see "RAID 10 like")
|
||||
|
||||
### 2-way replication
|
||||
|
||||
@ -48,8 +48,8 @@ This is a kind of special mode. On a 2 nodes setup, one node must know what's ha
|
||||
|
||||
Thanks to this arbiter, you'll have 3 nodes running on 2 XenServer hosts:
|
||||
|
||||
* if the host with 1 node is down, the other host will continue to provide a working XOSAN
|
||||
* if the host with 2 nodes (1 normal and 1 arbiter) id down, the other node will go into read only mode, to avoid split brain scenario.
|
||||
- if the host with 1 node is down, the other host will continue to provide a working XOSAN
|
||||
- if the host with 2 nodes (1 normal and 1 arbiter) id down, the other node will go into read only mode, to avoid split brain scenario.
|
||||
|
||||
This way, in all cases, you are protected.
|
||||
|
||||
@ -84,5 +84,5 @@ There is more fault tolerance on mode 2, but less space usable. It's up to you!
|
||||
|
||||
You can grow a replicated XOSAN by adding pairs, in other words "RAID 1"-like mirrors to the existing setup, like you would adds mirrored disks in "RAID 10" setup. Examples:
|
||||
|
||||
* on a 2 hosts setup, going for 4 hosts by adding 2 mirrored nodes
|
||||
* on a 3 hosts setup using 3-way replication, by adding 3 mirrored nodes
|
||||
- on a 2 hosts setup, going for 4 hosts by adding 2 mirrored nodes
|
||||
- on a 3 hosts setup using 3-way replication, by adding 3 mirrored nodes
|
||||
|
||||
@ -8,9 +8,9 @@ XOSAN can be deployed on an existing **Local LVM storage**, that XenServer confi
|
||||
|
||||
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`)
|
||||
- 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.
|
||||
|
||||
@ -34,8 +34,8 @@ Each XOSAN VM deployed will use 2x vCPUs. This setting should be enough for all
|
||||
|
||||
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
|
||||
- 12 vCPUs (usage is in general pretty low)
|
||||
- 12 GiB RAM
|
||||
- All Local LVM disk space
|
||||
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
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.
|
||||
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
|
||||
## 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)
|
||||
|
||||
@ -11,14 +11,15 @@ SSH in your XenServer and use the command line `curl -sS https://xoa.io/deploy |
|
||||
## 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)*
|
||||
|
||||
> _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.
|
||||
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.*
|
||||
> _You will always have the opportunity to upgrade an existing XOSAN cluster which is in trial version to a standard XOSAN license._
|
||||
|
||||
@ -4,25 +4,25 @@ There is 2 modes for creating an XOSAN storage. They are different and the choic
|
||||
|
||||
That's why it's **very important to understand pros and cons** of each type.
|
||||
|
||||
> 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.
|
||||
> 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)
|
||||
- [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
|
||||
- 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
|
||||
- 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
|
||||
|
||||
@ -52,7 +52,7 @@ new CM.String('foo').createPredicate()
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -15,16 +15,15 @@ Installation of the [npm package](https://npmjs.org/package/value-matcher):
|
||||
```js
|
||||
import { createPredicate } from 'value-matcher'
|
||||
|
||||
[
|
||||
;[
|
||||
{ user: 'sam', age: 65, active: false },
|
||||
{ user: 'barney', age: 36, active: true },
|
||||
{ user: 'fred', age: 40, active: false },
|
||||
].filter(createPredicate({
|
||||
__or: [
|
||||
{ user: 'sam' },
|
||||
{ active: true },
|
||||
],
|
||||
}))
|
||||
].filter(
|
||||
createPredicate({
|
||||
__or: [{ user: 'sam' }, { active: true }],
|
||||
})
|
||||
)
|
||||
// [
|
||||
// { user: 'sam', age: 65, active: false },
|
||||
// { user: 'barney', age: 36, active: true },
|
||||
@ -52,7 +51,7 @@ import { createPredicate } from 'value-matcher'
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -37,7 +37,7 @@ Installation of the [npm package](https://npmjs.org/package/vhd-cli):
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -38,7 +38,7 @@ Usage: xapi-explore-sr [--full] <SR UUID> <XenServer URL> <XenServer user> [<Xen
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -35,9 +35,9 @@ const xapi = createClient({
|
||||
allowUnauthorized: false,
|
||||
auth: {
|
||||
user: 'root',
|
||||
password: 'important secret password'
|
||||
password: 'important secret password',
|
||||
},
|
||||
readOnly: false
|
||||
readOnly: false,
|
||||
})
|
||||
```
|
||||
|
||||
@ -64,6 +64,7 @@ xapi.objects.on('add', objects => {
|
||||
> Note: all objects are frozen and cannot be altered!
|
||||
|
||||
Custom fields on objects (hidden − ie. non enumerable):
|
||||
|
||||
- `$type`: the type of the object (`VM`, `task`, …);
|
||||
- `$ref`: the (opaque) reference of the object;
|
||||
- `$id`: the identifier of this object (its UUID if any, otherwise its reference);
|
||||
@ -128,7 +129,7 @@ root@xen1.company.net> findAll({ $type: 'VM' }).length
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -17,10 +17,14 @@ import check from 'xo-acl-resolver'
|
||||
|
||||
// This object contains a list of permissions returned from
|
||||
// xo-server's acl.getCurrentPermissions.
|
||||
const permissions = { /* ... */ }
|
||||
const permissions = {
|
||||
/* ... */
|
||||
}
|
||||
|
||||
// This function should returns synchronously an object from an id.
|
||||
const getObject = id => { /* ... */ }
|
||||
const getObject = id => {
|
||||
/* ... */
|
||||
}
|
||||
|
||||
// For a single object:
|
||||
if (check(permissions, getObject, objectId, permission)) {
|
||||
@ -28,10 +32,12 @@ if (check(permissions, getObject, objectId, permission)) {
|
||||
}
|
||||
|
||||
// For multiple objects/permissions:
|
||||
if (check(permissions, getObject, [
|
||||
[ object1Id, permission1 ],
|
||||
[ object12d, permission2 ],
|
||||
])) {
|
||||
if (
|
||||
check(permissions, getObject, [
|
||||
[object1Id, permission1],
|
||||
[object12d, permission2],
|
||||
])
|
||||
) {
|
||||
console.log('all permissions checked')
|
||||
}
|
||||
```
|
||||
@ -60,7 +66,7 @@ The sources files are watched and automatically recompiled on changes.
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -1,4 +1,5 @@
|
||||
# XO-CLI
|
||||
|
||||
[](http://travis-ci.org/vatesfr/xen-orchestra)
|
||||
[](https://david-dm.org/vatesfr/xo-cli)
|
||||
[](https://david-dm.org/vatesfr/xo-cli#info=devDependencies)
|
||||
@ -85,8 +86,7 @@ Commands can be filtered using patterns:
|
||||
|
||||
#### Execute a command
|
||||
|
||||
The same syntax is used for all commands: `xo-cli <command> <param
|
||||
name>=<value>...`
|
||||
The same syntax is used for all commands: `xo-cli <command> <param name>=<value>...`
|
||||
|
||||
E.g., adding a new server:
|
||||
|
||||
@ -119,7 +119,7 @@ encoding by prefixing with `json:`:
|
||||
|
||||
##### VM import
|
||||
|
||||
```
|
||||
```
|
||||
> xo-cli vm.import sr=60a6939e-8b0a-4352-9954-5bde44bcdf7d @=vm.xva
|
||||
```
|
||||
|
||||
@ -144,7 +144,7 @@ encoding by prefixing with `json:`:
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -128,7 +128,7 @@ var bar = col.get('bar', 6.28)
|
||||
var _ = require('lodash')
|
||||
|
||||
// Prints all the items.
|
||||
_.forEach(col.all, function (value, key) {
|
||||
_.forEach(col.all, function(value, key) {
|
||||
console.log('- %s: %j', key, value)
|
||||
})
|
||||
|
||||
@ -153,7 +153,7 @@ var size = col.size
|
||||
**New items**
|
||||
|
||||
```javascript
|
||||
col.on('add', (added) => {
|
||||
col.on('add', added => {
|
||||
forEach(added, (value, key) => {
|
||||
console.log('+ %s: %j', key, value)
|
||||
})
|
||||
@ -163,7 +163,7 @@ col.on('add', (added) => {
|
||||
**Updated items**
|
||||
|
||||
```javascript
|
||||
col.on('update', (updated) => {
|
||||
col.on('update', updated => {
|
||||
forEach(updated, (value, key) => {
|
||||
console.log('± %s: %j', key, value)
|
||||
})
|
||||
@ -173,7 +173,7 @@ col.on('update', (updated) => {
|
||||
**Removed items**
|
||||
|
||||
```javascript
|
||||
col.on('remove', (removed) => {
|
||||
col.on('remove', removed => {
|
||||
// For consistency, `removed` is also a map but contrary to `added`
|
||||
// and `updated`, the values associated to the keys are not
|
||||
// significant since the items have already be removed.
|
||||
@ -224,7 +224,7 @@ const View = require('xo-collection/view')
|
||||
> can be briefly invalid.
|
||||
|
||||
```javascript
|
||||
const myView = new View(parentCollection, function predicate (value, key) {
|
||||
const myView = new View(parentCollection, function predicate(value, key) {
|
||||
// This function should return a boolean indicating whether the
|
||||
// current item should be in this view.
|
||||
})
|
||||
@ -251,7 +251,7 @@ const myView = new View(parentCollection, function predicate (value, key) {
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -35,7 +35,7 @@ Installation of the [npm package](https://npmjs.org/package/xo-common):
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -50,7 +50,7 @@ Shell command:
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -32,7 +32,7 @@ await xo.open()
|
||||
// be buffered until signed in).
|
||||
await xo.signIn({
|
||||
email: 'admin@admin.net',
|
||||
password: 'admin'
|
||||
password: 'admin',
|
||||
})
|
||||
|
||||
console('signed as', xo.user)
|
||||
@ -46,7 +46,7 @@ const xo = Xo({
|
||||
credentials: {
|
||||
email: 'admin@admin.net',
|
||||
password: 'admin',
|
||||
}
|
||||
},
|
||||
})
|
||||
|
||||
xo.open()
|
||||
@ -86,7 +86,7 @@ console.log('Token created', token)
|
||||
### Status
|
||||
|
||||
The connection status is available through the status property which
|
||||
is *open*, *connecting* or *closed*.
|
||||
is _open_, _connecting_ or _closed_.
|
||||
|
||||
```javascript
|
||||
console.log('%s to xo-server', xo.status)
|
||||
@ -118,7 +118,7 @@ xo.on('closed', () => {
|
||||
```
|
||||
|
||||
```javascript
|
||||
xo.on('notification', function (notif) {
|
||||
xo.on('notification', function(notif) {
|
||||
console.log('notification:', notif.method, notif.params)
|
||||
})
|
||||
```
|
||||
@ -154,7 +154,7 @@ xo.on('authenticationFailure', () => {
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -35,7 +35,7 @@ Installation of the [npm package](https://npmjs.org/package/xo-remote-parser):
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -46,7 +46,7 @@ The sources files are watched and automatically recompiled on changes.
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -59,7 +59,7 @@ the web iterface, see [the plugin documentation](https://xen-orchestra.com/docs/
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -64,7 +64,7 @@ could not authenticate john.smith
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -45,7 +45,7 @@ the web interface, see [the plugin documentation](https://xen-orchestra.com/docs
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -34,7 +34,7 @@ the web interface, see [the plugin documentation](https://xen-orchestra.com/docs
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -35,7 +35,7 @@ The sources files are watched and automatically recompiled on changes.
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -13,7 +13,7 @@ the web interface, see [the plugin documentation](https://xen-orchestra.com/docs
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -12,7 +12,7 @@ Please see the plugin's [official documentation](https://xen-orchestra.com/docs/
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
@ -34,24 +34,23 @@ XO clients send data to xo-server for testing the configuration and saving it if
|
||||
|
||||
#### The default export
|
||||
|
||||
It is just a factory function which will create an instance of the plugin. Usually it will be called only once, at startup.
|
||||
It is just a factory function which will create an instance of the plugin. Usually it will be called only once, at startup.
|
||||
Its only parameter is an object which currently only contains the instance of the currently running xo-server.
|
||||
|
||||
#### `configure(configuration) `
|
||||
#### `configure(configuration)`
|
||||
|
||||
This method is called each time the plugin is (re-)configured.
|
||||
Its only parameter is an object which contains the configuration values.
|
||||
|
||||
#### `load() `
|
||||
#### `load()`
|
||||
|
||||
This method is called to load the plugin.
|
||||
|
||||
#### `unload() `
|
||||
#### `unload()`
|
||||
|
||||
This method is called to unload the plugin.
|
||||
|
||||
#### `test(data) `
|
||||
#### `test(data)`
|
||||
|
||||
This method is called if the test option is activated.
|
||||
Its only parameter is an object which contains the test values.
|
||||
|
||||
Its only parameter is an object which contains the test values.
|
||||
|
||||
@ -25,39 +25,40 @@ src
|
||||
|
||||
The tests can describe:
|
||||
|
||||
- XO methods or scenarios:
|
||||
- XO methods or scenarios:
|
||||
|
||||
`src/user/index.js`
|
||||
|
||||
```js
|
||||
import xo from "../_xoConnection";
|
||||
|
||||
describe("user", () => {
|
||||
import xo from '../_xoConnection'
|
||||
|
||||
describe('user', () => {
|
||||
// testing a method
|
||||
describe(".set()", () => {
|
||||
it("sets an email", async () => {
|
||||
describe('.set()', () => {
|
||||
it('sets an email', async () => {
|
||||
// some tests using xo methods and helpers from _xoConnection.js
|
||||
const id = await xo.createTempUser(SIMPLE_USER);
|
||||
expect(await xo.call("user.set", params)).toBe(true);
|
||||
const id = await xo.createTempUser(SIMPLE_USER)
|
||||
expect(await xo.call('user.set', params)).toBe(true)
|
||||
expect(await xo.getUser(id)).toMatchSnapshot({
|
||||
id: expect.any(String),
|
||||
});
|
||||
});
|
||||
});
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
// testing a scenario
|
||||
test("create two users, modify a user email to be the same with the other and fail trying to connect them", () => {
|
||||
test('create two users, modify a user email to be the same with the other and fail trying to connect them', () => {
|
||||
/* some tests */
|
||||
});
|
||||
|
||||
});
|
||||
})
|
||||
})
|
||||
```
|
||||
- issues
|
||||
|
||||
- issues
|
||||
|
||||
`src/issues/index.js`
|
||||
|
||||
```js
|
||||
describe("issue", () => {
|
||||
test("5454", () => {
|
||||
describe('issue', () => {
|
||||
test('5454', () => {
|
||||
/* some tests */
|
||||
})
|
||||
})
|
||||
@ -66,8 +67,9 @@ describe("user", () => {
|
||||
### Best practices
|
||||
|
||||
- The test environment must remain the same before and after each test:
|
||||
* each resource created must be deleted
|
||||
* existing resources should not be altered
|
||||
|
||||
- each resource created must be deleted
|
||||
- existing resources should not be altered
|
||||
|
||||
- Make a sentence for the title of the test. It must be clear and consistent.
|
||||
|
||||
@ -79,46 +81,52 @@ describe("user", () => {
|
||||
|
||||
- `_xoConnection.js` contains helpers to create temporary resources and to interface with XO.
|
||||
You can use it if you need to create resources which will be automatically deleted after the test:
|
||||
```javascript
|
||||
import xo from "../_xoConnection";
|
||||
|
||||
describe(".create()", () => {
|
||||
it("creates a user without permission", async () => {
|
||||
```javascript
|
||||
import xo from '../_xoConnection'
|
||||
|
||||
describe('.create()', () => {
|
||||
it('creates a user without permission', async () => {
|
||||
// The user will be deleted automatically at the end of the test
|
||||
const userId = await xo.createTempUser({
|
||||
email: "wayne1@vates.fr",
|
||||
password: "batman1",
|
||||
});
|
||||
email: 'wayne1@vates.fr',
|
||||
password: 'batman1',
|
||||
})
|
||||
expect(await xo.getUser(userId)).toMatchSnapshot({
|
||||
id: expect.any(String),
|
||||
});
|
||||
});
|
||||
});
|
||||
})
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
The available helpers:
|
||||
* `createTempUser(params)`
|
||||
* `getUser(id)`
|
||||
* `createTempJob(params)`
|
||||
* `createTempBackupNgJob(params)`
|
||||
* `createTempVm(params)`
|
||||
* `getSchedule(predicate)`
|
||||
|
||||
- `createTempUser(params)`
|
||||
- `getUser(id)`
|
||||
- `createTempJob(params)`
|
||||
- `createTempBackupNgJob(params)`
|
||||
- `createTempVm(params)`
|
||||
- `getSchedule(predicate)`
|
||||
|
||||
## Usage
|
||||
|
||||
- Before running the tests, you have to create a config file for xo-server-test.
|
||||
|
||||
```
|
||||
> cp sample.config.toml ~/.config/xo-server-test/config.toml
|
||||
```
|
||||
|
||||
And complete it.
|
||||
|
||||
- To run the tests:
|
||||
|
||||
```
|
||||
> npm ci
|
||||
> yarn test
|
||||
```
|
||||
|
||||
You get all the test suites passed (`PASS`) or failed (`FAIL`).
|
||||
|
||||
```
|
||||
> yarn test
|
||||
yarn run v1.9.4
|
||||
@ -138,15 +146,15 @@ describe("user", () => {
|
||||
- You can run only tests related to changed files, and review the failed output by using: `> yarn test --watch`
|
||||
|
||||
- ⚠ Warning: snapshots ⚠
|
||||
After each run of the tests, check that snapshots are not inadvertently modified.
|
||||
After each run of the tests, check that snapshots are not inadvertently modified.
|
||||
|
||||
- ⚠ Jest known issue ⚠
|
||||
If a test timeout is triggered the next async tests can fail, it's due to an inadvertently modified snapshots.
|
||||
As a workaround, you can clean your git working tree and re-run jest using a large timeout: `> yarn test --testTimeout=100000`
|
||||
If a test timeout is triggered the next async tests can fail, it's due to an inadvertently modified snapshots.
|
||||
As a workaround, you can clean your git working tree and re-run jest using a large timeout: `> yarn test --testTimeout=100000`
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are *very* welcomed, either on the documentation or on
|
||||
Contributions are _very_ welcomed, either on the documentation or on
|
||||
the code.
|
||||
|
||||
You may:
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user