fix(all): links
This commit is contained in:
Olivier Lambert
25
docs/README.md
Normal file
25
docs/README.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Xen Orchestra
|
||||
|
||||
## Introduction
|
||||
|
||||
XO is a web interface to visualize and administrate your XenServer (or XAPI enabled) hosts.
|
||||
|
||||
It aims to be easy to use on any device supporting modern web technologies (HTML 5, CSS 3, JavaScript) such as your desktop computer or your smartphone.
|
||||
|
||||
XO is developed by [Vates](https://vates.fr) ([@vatesfr](https://twitter.com/vatesfr)), a French company specializing in Open Source, and released under the [AGPL v3](http://www.gnu.org/licenses/agpl-3.0-standalone.html) license.
|
||||
|
||||
|
||||
__XO is evolving fast, [check our blog](https://xen-orchestra.com/blog) or follow us on Twitter ([@xenorchestra](https://twitter.com/xenorchestra)) to stay tuned about the project!__
|
||||
|
||||
|
||||
|
||||
|
||||
## Documentation
|
||||
|
||||
Documentation is available here: https://xen-orchestra.com/docs
|
||||
|
||||
## Toolstack
|
||||
|
||||
Xen Orchestra is agent-less thanks to the [XAPI toolstack](http://wiki.xen.org/wiki/Choice_of_Toolstacks). This toolstack is configured out-of-the-box with [XenServer](http://xenserver.org). If you want to use your Xen on your own distribution, you'll have to [install XAPI manually](https://github.com/xenserver/buildroot).
|
||||
|
||||
|
||||
75
docs/acls.md
Normal file
75
docs/acls.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# ACLs
|
||||
|
||||
ACLs are the permissions for your users or groups. The ACLs view can be accessed in the "Settings".
|
||||
|
||||
1. Select the user or group you want to apply permissions on it
|
||||
2. Select the object on which the permission will apply
|
||||
3. Choose the role for this ACL
|
||||
4. Click on "Create"
|
||||
|
||||
|
||||
|
||||
> Pro tip: you can click to add multiple objects at the same time!
|
||||
|
||||
Your ACL is now available in the right list:
|
||||
|
||||
|
||||
|
||||
You can edit/remove existing ACLs here.
|
||||
|
||||
## Roles
|
||||
|
||||
There is 3 different roles for your users:
|
||||
|
||||
* Admin
|
||||
* Operator
|
||||
* Viewer
|
||||
|
||||
### Admin
|
||||
|
||||
An object admin can do everything on it, even destroy it. E.g with its admin VM:
|
||||
|
||||
* create a new VM
|
||||
* remove it
|
||||
* migrate it (to a host with admin permission on it)
|
||||
* modify the VM resources, name and description
|
||||
* clone it
|
||||
* copy it
|
||||
* convert it into a template
|
||||
* snapshot it (even revert from a snapshot)
|
||||
* export it
|
||||
* attach/add visible disks
|
||||
* same for network cards
|
||||
|
||||
### Operator
|
||||
|
||||
An operator can make everyday operations on assigned objects. E.g on a VM:
|
||||
|
||||
* eject a CD
|
||||
* insert a CD (if he can view the ISO storage repository)
|
||||
* start, restart, shutdown, suspend/resume it
|
||||
|
||||
All other operations are forbidden.
|
||||
|
||||
### Viewer
|
||||
|
||||
A viewer can only access the object console (if any) and see the object metrics. That's all!
|
||||
|
||||
## Inheritance
|
||||
|
||||
Objects have a hierarchy: a Pool contains all its hosts, containing itself all its VMs.
|
||||
|
||||
If you give a *view* permission to a user (or a group) on a pool, he will automatically see all the objects inside this pool (SRs, hosts, VMs).
|
||||
|
||||
## Examples
|
||||
|
||||
### Allow a user to install an OS
|
||||
|
||||
If the OS install needs a 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.
|
||||
|
||||
### Console only
|
||||
|
||||
If you want to give your user access to the VM console only, the *View* permission is enough.
|
||||
204
docs/administration.md
Normal file
204
docs/administration.md
Normal file
@@ -0,0 +1,204 @@
|
||||
# Administration
|
||||
|
||||
This part is about everyday XenServer administration tasks.
|
||||
|
||||
### Infrastructure overview
|
||||
|
||||
The original motivation of XO was to provide a view to understand the whole infrastructure in a single page. In short, to answer the question: "where is my VM?".
|
||||
|
||||
|
||||
[](https://xen-orchestra.com/blog/introducing-new-interface/#horizontalhierarchy)
|
||||
|
||||
### Live filter search
|
||||
|
||||
If you infrastructure starts to be big, it could be useful to find exactly what you need. It could be an IP address, a VM name, or a storage name: any object!
|
||||
|
||||
|
||||
[](https://xen-orchestra.com/blog/introducing-new-interface/#flatviewwithpowerfulsearchengine)
|
||||
|
||||
You can also use a special query filter with the `*` char:
|
||||
|
||||
* `*{running,halted}`
|
||||
* `*{VM,SR,Host,Pool}`
|
||||
|
||||
Those "helpers" are accessible in the sub-bar of the search view:
|
||||
|
||||
|
||||
|
||||
#### Examples
|
||||
|
||||
* All running VMs: `*running *vm`
|
||||
* All halted VMs with a "production" (in a tag): `*vm *halted production`
|
||||
* Find all SR with a broken link to a host: `*disconnected *sr`
|
||||
|
||||
|
||||
|
||||
|
||||
### Easy VM creation
|
||||
|
||||
Creating a VM should be trivial! That's why we are constantly improving our interface to display only what's necessary, but also allow the user to access advanced stuff when needed.
|
||||
|
||||
Be advised we are in the middle of a full interface rewrite, you can read [more about it here](https://xen-orchestra.com/blog/announcing-xen-orchestra-5-x/).
|
||||
|
||||
### Change de default SR
|
||||
|
||||
In XenServer, the default SR (Storage Repository) is where your VDIs are stored by default.
|
||||
|
||||
It's very useful for a lot of things, avoiding the user to configure itself for each operation.
|
||||
|
||||
Just go inside your pool view, you'll have a list of your SRs. Just click on the "disk" icon at the end of the line corresponding to the SR you want to be the new default one:
|
||||
|
||||
|
||||
|
||||
### VM import and export
|
||||
|
||||
You can import or export a VM directly on your computer, through your web browser.
|
||||
|
||||
If your VM is currently running, XO will automatically create a snapshot then delete it at the end of the export process.
|
||||
|
||||
[](https://xen-orchestra.com/blog/import-and-export-vm-in-xo/)
|
||||
|
||||
### VM Copy
|
||||
|
||||
VM copy allow to make an export and an import in streaming. You can target any SR in your whole XenServer infrastructure (even across different pools!)
|
||||
|
||||
|
||||
|
||||
### Snapshots management
|
||||
|
||||
You can create a snapshot in 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
|
||||
|
||||
|
||||
[
|
||||
](https://xen-orchestra.com/blog/snapshot-export-with-xen-orchestra/)
|
||||
|
||||
> By default, XOA will try to make a snapshot with quiesce. If the VM do not support it, it will fallback to the default snapshot system.
|
||||
|
||||
If your snapshot was done with quiesce support, you'll see a icon:
|
||||
|
||||
|
||||
|
||||
### Statistics
|
||||
|
||||
Live statistics are showing the last 10 minutes of VM/host/SR usage.
|
||||
|
||||
|
||||
[
|
||||
](https://xen-orchestra.com/blog/vm-live-metrics-in-xenserver-with-xen-orchestra/)
|
||||
|
||||
### Auto patching
|
||||
|
||||
Patching a host manually could be time consuming (and boring). That's why we provide a high level feature downloading and applying all missong patches automatically.
|
||||
|
||||
[
|
||||
](https://xen-orchestra.com/blog/xen-orchestra-4-8/#fullyautomatedpatching)
|
||||
|
||||
> If you are behind a proxy, please update your `xo-server` configuration to add a proxy server, as [explained in the appropriate section](configuration.md#proxy-for-xenserver-updates-and-patches).
|
||||
|
||||
|
||||
### Batch operations
|
||||
|
||||
You can make simultaneous operations on many objects: like migrate a bunch of VM, or start them at the same time. For this, you can select multiple VMs at the same time (in the home view), then apply actions on it thanks to the "action" bar on the top.
|
||||
|
||||
Please consider that booting a lot of VM at the same time could be longer than doing it per smaller batches.
|
||||
|
||||
### Drag'n drop live migration
|
||||
|
||||
You can live migrate a VM just by drag'n drop! But also select multiple VM and migrate them at the same time on a targeted host.
|
||||
|
||||
|
||||
[
|
||||
](https://xen-orchestra.com/blog/vm-live-migration-with-xenserver-and-xen-orchestra/)
|
||||
|
||||
### VDI live migration
|
||||
|
||||
Thanks to Xen Storage Motion, it's easy to move a VM disk from a storage to another, while the VM is on! This feature can help you to migrate from your local storage to a SAN, or just upgrade your SAN without any downtime.
|
||||
|
||||
To do that: go inside your running VM, then edit the Disk panel. You can change the SR of any disk, then save. This will trigger the storage motion.
|
||||
|
||||
|
||||
[
|
||||
](https://xen-orchestra.com/blog/moving-vdi-in-live/)
|
||||
|
||||
#### Offline VDI migration
|
||||
|
||||
Despite it's not currently supported in XenServer, we managed to do it in Xen Orchestra. It's exactly the same process than for a running VM. Read this article for more details: https://xen-orchestra.com/blog/moving-a-vdi-offline-in-xenserver/
|
||||
|
||||
|
||||
### VM recovery
|
||||
|
||||
|
||||
|
||||
This button will allow you to boot directly on the CD drive, ignoring your current disks. Note that it works for all virtualization modes: HVM or PV.
|
||||
|
||||
### Host emergency shutdown
|
||||
|
||||
In the host view, you have a "Emergency shutdown" button:
|
||||
|
||||
|
||||
|
||||
This will:
|
||||
|
||||
1. Suspend all your running VM on your host
|
||||
2. Shutdown it
|
||||
|
||||
This is particularly useful for power outage on a limited UPS battery time.
|
||||
|
||||
> Suspending VMs will avoid any data loss, even if they are stored in RAM!
|
||||
|
||||
### Adjusting resources in live
|
||||
|
||||
You can edit your VM RAM or CPUs in live, like you edit a VM name or description. But there is some XenServer limitations and configuration not exposed directly in Xen Orchestra:
|
||||
|
||||
* each VM has a vCPU maximum number. This value can't be change while the VM is running. You can reduce the number of vCPUs, but can't assign more than max. In XO, while your VM is halted, allow 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 apply for the RAM.
|
||||
|
||||
You can learn more about XenServer resource management here: https://wiki.xenserver.org/XCP_FAQ_Dynamic_Memory_Control
|
||||
|
||||
### Auto power VM
|
||||
|
||||
Activate "Auto Power" on a VM will also configure the pool accordingly. [Read our blog post for further detail](/blog/auto-start-vm-on-xenserver-boot/).
|
||||
|
||||
|
||||
|
||||
### Docker management
|
||||
|
||||
> Please [read the dedicated section](docker_support.md) to install a Docker Ready VM.
|
||||
|
||||
Thanks to the plugin developed [recently](http://xenserver.org/partners/docker.html?id=159) as a "preview" by Citrix in XenServer, we started to work something to expose those data in Xen Orchestra.
|
||||
|
||||
First thing first, we now detect which VMs are "Docker ready", meaning connected to XenServer and its plugin to send more info.
|
||||
|
||||
This is visible in the home page of XO, VM with a small ship blue logo:
|
||||
|
||||
|
||||
|
||||
By clicking on this VM, you'll have some new stuff visible, first the Docker version:
|
||||
|
||||
|
||||
|
||||
Also, a new panel is now displaying the containers on the VM:
|
||||
|
||||
|
||||
|
||||
You can Stop, Start, Pause, Resume or Restart a Docker container from there.
|
||||
|
||||
### VM CPU priority
|
||||
|
||||
You can change the CPU Weight in the VM view. Values are:
|
||||
|
||||
* Default
|
||||
* Quarter (1/4)
|
||||
* Half (1/2)
|
||||
* Normal
|
||||
* Double (x2)
|
||||
|
||||
|
||||
|
||||
By default, each VM has a weight of 256.
|
||||
|
||||
If one VM got for example, "Double", it will have double priority for the Xen scheduler. [Read more on the official Citrix XenServer documentation](http://support.citrix.com/article/CTX117960).
|
||||
37
docs/alerts.md
Normal file
37
docs/alerts.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Alerts
|
||||
|
||||
> This feature is currently under active development, and not yet available in the interface.
|
||||
|
||||
Alerts are a way to warn the administrator about various events. The first kind of alerts will be emails and also a dedicated in `xo-web` to display them.
|
||||
|
||||
## Performances alerts
|
||||
|
||||
The administrator will configure alerts based on performance thresholds.
|
||||
|
||||
The configurable metrics are:
|
||||
|
||||
* CPU usage (VM, host)
|
||||
* RAM usage (VM, host)
|
||||
* network bandwidth (VM, host)
|
||||
* load average (host)
|
||||
* disk IO (VM)
|
||||
* total IO (SR, only for XenServer Dundee)
|
||||
|
||||
If any configured values exceed the threshold during a selection period of time, an alert will be sent.
|
||||
|
||||
Those alerts will be also stored to be accessible in the web interface, and also later for the Load balancing feature (helping it to solve those performances problems).
|
||||
|
||||
## Updates alerts
|
||||
|
||||
When your XOA detects new packages, you'll be notified by email.
|
||||
|
||||
## Backup alerts
|
||||
|
||||
Same story for backups: when a backup failed, you'll receive an email.
|
||||
|
||||
You will also choose to be notified only if it fails or even after each backup job.
|
||||
|
||||
Current supported alerts system:
|
||||
|
||||
* Email
|
||||
* XMPP
|
||||
27
docs/architecture.md
Normal file
27
docs/architecture.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Architecture
|
||||
|
||||
Xen Orchestra (XO) is a software built with a server and clients, such as the web client, `xo-web`, but also a CLI capable client, called `xo-cli`.
|
||||
|
||||
> XO is totally agent-less: it means that you don't have to install any program on your hosts to get it working!
|
||||
|
||||
## XOA
|
||||
|
||||
*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 in a minute.
|
||||
|
||||
Your XOA is connected to all your hosts, or on the pool master only if you are using Pools in XenServer:
|
||||
|
||||
|
||||
|
||||
## Xen Orchestra (XO)
|
||||
|
||||
|
||||
|
||||
Xen Orchestra itself is built as a modular solution. Each part has its role:
|
||||
- the core is "[xo-server](https://github.com/vatesfr/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 in "[xo-web](https://github.com/vatesfr/xo-web)": you are running it directly in your browser. The connection with "xo-server" is done via *WebSockets*.
|
||||
- "[xo-cli](https://github.com/vatesfr/xo-cli)" is a module allowing to send commands directly from the command line.
|
||||
|
||||
|
||||
We already have other modules around it (like the LDAP plugin for example). It allows to use this modular architecture to add further parts later. It's completely flexible, allowing us to adapt Xen Orchestra in every existing work-flow.
|
||||
18
docs/authentication.md
Normal file
18
docs/authentication.md
Normal file
@@ -0,0 +1,18 @@
|
||||
# User authentication
|
||||
|
||||
|
||||
Xen Orchestra support various type of user authentication, internal or even external thanks to the usage of [Passport library](http://passportjs.org/).
|
||||
|
||||
There is 2 types of XO users:
|
||||
|
||||
* admins, with all rights on all connected resources
|
||||
* users, with no right by default
|
||||
|
||||
All users will land on the "flat" view, which display no hierarchy, only all their visible objects (or no object if they are not configured).
|
||||
|
||||
|
||||
ACLs will thus apply only on "users".
|
||||
|
||||
> Any account created by an external authentication process (LDAP, SSO...) will be a **user** without any permission.
|
||||
|
||||
Also, you don't have to create an external user by yourself: it will be created automatically in Xen Orchestra after its first connection.
|
||||
5
docs/auto_scalability.md
Normal file
5
docs/auto_scalability.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Auto scalability
|
||||
|
||||
> This plugin will be developed for the end of 2015.
|
||||
|
||||
The concept here is to detect when your VMs needs more RAM or vCPUs, and act accordingly (to a maximum given by the administrator).
|
||||
95
docs/backups.md
Normal file
95
docs/backups.md
Normal file
@@ -0,0 +1,95 @@
|
||||
# Backups
|
||||
|
||||
This section is dedicated to any existing means to rollback or backup your VMs in Xen Orchestra.
|
||||
|
||||
There is different way to protect your VMs:
|
||||
|
||||
* [full backups](full_backups.md)
|
||||
* [snapshots](rolling_snapshots.md)
|
||||
* [delta backups](delta_backups.md) (best of both previous ones)
|
||||
* [disaster recovery](disaster_recovery.md)
|
||||
* [continuous replication](continuous_replication.md)
|
||||
|
||||
## Overview
|
||||
|
||||
This is the welcome panel on the backup view. It recaps all existing scheduled jobs. This is also where the backup logs are displayed.
|
||||
|
||||
|
||||
|
||||
## Logs
|
||||
|
||||
All the scheduled operations (backup, snapshots and even DR) are displayed in the main backup view.
|
||||
|
||||
A successful backup task will be displayed in green, a faulty one in red. You can click on the arrow to see each entry detail:
|
||||
|
||||
|
||||
|
||||
You also have a filter to search anything related to these logs.
|
||||
|
||||
## Email notifications
|
||||
|
||||
> This feature is available since 4.10
|
||||
|
||||
You can now **be notified by emails** after the backup task is finished (scheduled "full backup", "snapshots" or "disaster recovery").
|
||||
|
||||
To configure it, 2 steps in the plugin section (in "Settings"). First, add a list of recipient(s) for the notifications (in the plugin "backup-reports"):
|
||||
|
||||
|
||||
|
||||
Then, parameter the SMTP server:
|
||||
|
||||
|
||||
|
||||
That's it: your next scheduled jobs will be recap in a email. It will look like this:
|
||||
|
||||
```
|
||||
Global status: Success
|
||||
|
||||
Start time: Fri Nov 27 2015 10:54:00 GMT+0100
|
||||
End time: Fri Nov 27 2015 10:54:04 GMT+0100
|
||||
Duration: a few seconds
|
||||
Successful backed up VM number: 1
|
||||
Failed backed up VM: 0
|
||||
VM : miniVM
|
||||
|
||||
UUID: 4b85a038-6fd1-30f0-75c6-8440121d8faa
|
||||
Status: Success
|
||||
Start time: Fri Nov 27 2015 10:54:00 GMT+0100
|
||||
End time: Fri Nov 27 2015 10:54:04 GMT+0100
|
||||
Duration: a few seconds
|
||||
|
||||
```
|
||||
|
||||
If you don't find the plugins, check you have these two in your `xo-server` configuration:
|
||||
|
||||
```
|
||||
plugins:
|
||||
backup-reports:
|
||||
transport-email:
|
||||
```
|
||||
|
||||
## XMPP nofications
|
||||
|
||||
> This feature is available since 4.11
|
||||
|
||||
You can now **be notified via XMPP** after the backup task is finished (scheduled "full backup", "snapshots" or "disaster recovery").
|
||||
|
||||
To configure it, 2 steps in the plugin section (in "Settings"). First, add a list of recipient(s) for the notifications (in the plugin "backup-reports" and for XMPP):
|
||||
|
||||
|
||||
|
||||
Then, parameter the XMPP server:
|
||||
|
||||
|
||||
|
||||
That's it: your next scheduled jobs will be recap in a message:
|
||||
|
||||
|
||||
|
||||
If you don't find the plugins, check you have these two in your `xo-server` configuration:
|
||||
|
||||
```
|
||||
plugins:
|
||||
backup-reports:
|
||||
transport-xmpp:
|
||||
```
|
||||
48
docs/backups_and_disaster_recovery.md
Normal file
48
docs/backups_and_disaster_recovery.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# Backups and Disaster Recovery
|
||||
|
||||
This section is dedicated to any existing means to rollback or backup your VMs in Xen Orchestra.
|
||||
|
||||
## Full backups
|
||||
|
||||
You can schedule full backups of your VMs, by exporting them in the local XOA file-system, or directly in a NFS share. "Depth" parameter allow to modify the retention (removing the oldest one).
|
||||
|
||||
|
||||
|
||||
[Read more here](https://xen-orchestra.com/blog/backup-your-xenserver-vms-with-xen-orchestra/).
|
||||
|
||||
Full backups are space consuming! But they allow a very simple restoration without anything to think of (the file will contain all the VM disks and information.
|
||||
|
||||
### Restore backups
|
||||
|
||||
All your scheduled backup are acccessible in the "Restore" view in backup section of Xen Orchestra.
|
||||
|
||||
1. Select your mountpoint
|
||||
2. Choose the file you want to restore
|
||||
3. Select the host/pool you want to restore it
|
||||
|
||||
|
||||
|
||||
|
||||
### 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)
|
||||
|
||||
If you have compression on your NFS share (or destination file-system like ZFS), you can disable compression in Xen Orchestra.
|
||||
|
||||
Here is a network usage graph with 2 identical backup, the first one without compression:
|
||||
|
||||
|
||||
|
||||
## Scheduled snapshots
|
||||
|
||||
This feature is close to Backups, but it creates a snapshot when planned to do so. It also handles the retention (to remove the oldest snapshot).
|
||||
|
||||
**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).
|
||||
10
docs/built-in.md
Normal file
10
docs/built-in.md
Normal file
@@ -0,0 +1,10 @@
|
||||
# Built-in
|
||||
|
||||
This method is the default one. Creating a user is very simple:
|
||||
|
||||
1. Go into the Settings view, select "Users"
|
||||
2. You can create a *user* or an *admin*, with his password (or generate one)
|
||||
|
||||
|
||||
|
||||
By default, a *user* won't have any permission. At the opposite, an *admin* will have every rights.
|
||||
63
docs/cloudinit.md
Normal file
63
docs/cloudinit.md
Normal file
@@ -0,0 +1,63 @@
|
||||
# CloudInit
|
||||
|
||||
> CloudInit support is available from 4.11 release
|
||||
|
||||
Cloud-init is a program "that handles 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 hostname
|
||||
* add ssh keys
|
||||
* grow automatically the file system
|
||||
* create users
|
||||
* and a lot more!
|
||||
|
||||
This tool is pretty standard and used everywhere. A lot of existing cloud templates are using it.
|
||||
|
||||
So it means customizing very easily your VM when you create it from a compatible template. It brings you closer to the "instance" principle, like in Amazon cloud or OpenStack.
|
||||
|
||||
## Requirement
|
||||
|
||||
You only need to use a template of a VM with CloudInit installed inside it. [Check this blog post to learn how to install CloudInit](https://xen-orchestra.com/blog/centos-cloud-template-for-xenserver/).
|
||||
|
||||
## Usage
|
||||
|
||||
First, select your compatible template (CloudInit ready) and name it:
|
||||
|
||||
|
||||
|
||||
Then, activate the config drive and put your SSH key. Or you can also use a custom CloudInit configuration:
|
||||
|
||||
|
||||
|
||||
> CloudInit configuration examples are [available here](http://cloudinit.readthedocs.org/en/latest/topics/examples.html).
|
||||
|
||||
You can extend the disk size (**in this case, the template disk was 8 GiB originally**):
|
||||
|
||||
|
||||
|
||||
Finally, create the VM:
|
||||
|
||||
|
||||
|
||||
Now start the VM and SSH on its IP:
|
||||
|
||||
* **the system got the right VM hostname** (from VM name)
|
||||
* you don't have to use a password to access it (thanks to your SSH key):
|
||||
|
||||
```
|
||||
$ ssh centos@192.168.100.226
|
||||
[centos@tmp-app1 ~]$
|
||||
```
|
||||
|
||||
The default `cloud-init` configuration could allow you to be to be a sudoer directly:
|
||||
|
||||
```
|
||||
[centos@tmp-app1 ~]$ sudo -s
|
||||
[root@tmp-app1 centos]#
|
||||
```
|
||||
|
||||
Check the root file system size: indeed, **it was automatically grown** to what you need:
|
||||
|
||||
```
|
||||
[centos@tmp-app1 ~]$ df -h
|
||||
/dev/xvda1 20G 1,2G 18G 6% /
|
||||
```
|
||||
13
docs/code_of_conduct.md
Normal file
13
docs/code_of_conduct.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# Contributor Code of Conduct
|
||||
|
||||
As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
|
||||
|
||||
We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, age, or religion.
|
||||
|
||||
Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant](http:contributor-covenant.org), version 1.0.0, available at [http://contributor-covenant.org/version/1/0/0/](http://contributor-covenant.org/version/1/0/0/)
|
||||
97
docs/configuration.md
Normal file
97
docs/configuration.md
Normal file
@@ -0,0 +1,97 @@
|
||||
# Configuration
|
||||
|
||||
Once Xen Orchestra is installed, you can configure some parameters in the configuration file. Let's see how to do that.
|
||||
|
||||
## Configuration
|
||||
|
||||
The configuration file is in `/etc/xo-server/config.yaml`.
|
||||
|
||||
**WARNING: YAML is very strict with indentation: use spaces, not tabs.**
|
||||
|
||||
### User to run XO-server as
|
||||
|
||||
By default, XO-server is running as 'root'. You can change that by uncommenting these lines and choose whatever user/group you want:
|
||||
|
||||
```yaml
|
||||
user: 'nobody'
|
||||
group: 'nogroup'
|
||||
```
|
||||
|
||||
**Warning!** A non-privileged user:
|
||||
|
||||
* can't bind to a port < 1024
|
||||
* can't mount NFS shares
|
||||
|
||||
### HTTP listen address and port
|
||||
|
||||
By default, XO-server listens to all addresses (0.0.0.0) and runs on port 80. You can change this if you want in the `# Basic HTTP` section:
|
||||
|
||||
```yaml
|
||||
host: '0.0.0.0'
|
||||
port: 80
|
||||
```
|
||||
|
||||
### HTTPS
|
||||
|
||||
XO-server can also run in HTTPS (both HTTP and HTTPS can cohabit) - just modify what's needed in the `# Basic HTTPS` section, this time with certificates/keys you want and their path:
|
||||
|
||||
```yaml
|
||||
host: '0.0.0.0'
|
||||
port: 443
|
||||
certificate: './certificate.pem'
|
||||
key: './key.pem'
|
||||
```
|
||||
|
||||
> If a chain of certificates authorities is needed, you may bundle them directly in the certificate. Note: the order of certificates does matter, your certificate should come first followed by the certificate of the above certificate authority up to the root.
|
||||
|
||||
#### HTTPS redirection
|
||||
|
||||
If you want to redirect everything to HTTPS, you can modify the configuration like this:
|
||||
|
||||
```
|
||||
# If set to true, all HTTP traffic will be redirected to the first HTTPs configuration.
|
||||
|
||||
redirectToHttps: true
|
||||
```
|
||||
|
||||
This should be written just before the `mount` option, inside the `http:` block.
|
||||
|
||||
### Link to XO-web
|
||||
|
||||
You shouldn't have to change this. It's the path were "xo-web" files are served by "xo-server.
|
||||
|
||||
```yaml
|
||||
mounts:
|
||||
'/':
|
||||
- '../xo-web/dist/'
|
||||
```
|
||||
|
||||
### Redis server
|
||||
|
||||
By default, XO-server will try to contact Redis server on `localhost`, with the port `6379`. But you can define anything else you want:
|
||||
|
||||
```yaml
|
||||
uri: 'tcp://db:password@hostname:port'
|
||||
```
|
||||
|
||||
### Proxy for XenServer updates and patches
|
||||
|
||||
To check if your hosts are up-to-date, we need to access `http://updates.xensource.com/XenServer/updates.xml`.
|
||||
|
||||
And to download the patches, access to `http://support.citrix.com/supportkc/filedownload?`.
|
||||
|
||||
To do that behind a corporate proxy, just add the `httpProxy` variable to fit in your current proxy configuration.
|
||||
|
||||
You can add this at the end of your config file:
|
||||
|
||||
```yaml
|
||||
# HTTP proxy configuration used by xo-server to fetch resources on the Internet.
|
||||
#
|
||||
# See: https://github.com/TooTallNate/node-proxy-agent#maps-proxy-protocols-to-httpagent-implementations
|
||||
|
||||
httpProxy: 'http://jsmith:qwerty@proxy.lan:3128'
|
||||
```
|
||||
|
||||
### Log file
|
||||
|
||||
On XOA, the log file for XO-server is in `/var/log/syslog`. It contains all the server information returned and can be a real help when you have trouble.
|
||||
76
docs/continuous_replication.md
Normal file
76
docs/continuous_replication.md
Normal file
@@ -0,0 +1,76 @@
|
||||
# Continuous Replication
|
||||
|
||||
> This feature is released since 4.12
|
||||
|
||||
> WARNING: it works only on XenServer 6.5 or later
|
||||
|
||||
> WARNING 2: this feature is very new, use it with caution until 4.13
|
||||
|
||||
This feature allow continuous replication system for your XenServer VMs without any storage vendor lock-in. You can now replicate a VM every xx minutes/hours on a any storage repository. It could be on a distant XenServer host or just another local storage.
|
||||
|
||||
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
|
||||
|
||||
If you lose your main pool, you can start the copy on the other side, with very recent data.
|
||||
|
||||
|
||||
|
||||
> Warning: that's normal you can't boot the copied VM directly: we protected it. The normal workflow is to make a clone and to work on it.
|
||||
|
||||
## Configure it
|
||||
|
||||
As you'll see, this is trivial to configure. Inside the "Backup" section, select "Continuous Replication":
|
||||
|
||||
|
||||
|
||||
Then:
|
||||
|
||||
1. Select VMs you want to protect
|
||||
1. Schedule the replication interval
|
||||
1. Select the destination storage (could be any storage connected to any XenServer host!)
|
||||
|
||||
|
||||
|
||||
> In this case, we'll replicate 2 VMs to "NFS" SR which is a pool called "Other Pool". Replication will happen every 20 minutes.
|
||||
|
||||
That's it! Your VMs are protected and replicated as requested.
|
||||
|
||||
To protect the replication, we removed the possibility to boot your copied VM directly, because if you do that, it will break the next delta. The solution is to clone it if you need it (a clone is really quick). You can do whatever you want with this clone!
|
||||
|
||||
## Initial seed
|
||||
|
||||
If you can't transfer the first backup through your network, you can make a seed locally. In order to do this, follow this procedure (until we made it accessible directly in XO):
|
||||
|
||||
|
||||
### Preparation
|
||||
|
||||
1. create a cont. rep job to a non-distant SR (even the SR where is currently the VM). Do NOT enable the job at the creation.
|
||||
1. start manually the first replication (only the first)
|
||||
1. when finished, export the replicated VM (via XOA or any other mean, doesn't matter until you got your XVA file)
|
||||
1. import the replicated VM on destination
|
||||
1. you can remove your local replicated copy
|
||||
|
||||
### Modifications
|
||||
|
||||
In your source host:
|
||||
|
||||
1. Get the UUID of the remote destination SR where your VM was imported
|
||||
1. On the source host: `xe vm-param-list uuid=<SourceVM_UUID> | grep other-config`.
|
||||
* You should see somewhere in other-config: `xo:base_delta:<SR_UUID>: <VM_snapshot_UUID>;`
|
||||
* Remove this entry with `xe vm-param-remove uuid=<OriginalVM_UUID> param-name=other-config param-key=xo:base_delta:<SR_UUID>`
|
||||
* Recreate the correct param: `xe vm-param-set uuid=<OriginalVM_UUID> other-config:xo:base_delta:<destination_SR_UUID>=<VM_snapshot_UUID>`
|
||||
|
||||
In XO:
|
||||
|
||||
1. Edit the replication job and select the new destination SR
|
||||
|
||||
### Enable
|
||||
|
||||
Run manually a first time to check if everything is OK. Then, enable the job. **Now, only the delta's are sent, your initial seed saved you a LOT of time.**
|
||||
91
docs/contributing.md
Normal file
91
docs/contributing.md
Normal file
@@ -0,0 +1,91 @@
|
||||
# Contributing
|
||||
|
||||
XO is an Open Source project released under the [AGPL v3](http://www.gnu.org/licenses/agpl-3.0-standalone.html) license, contributions are therefore very welcome.
|
||||
|
||||
## Bug reports
|
||||
|
||||
You can [open bug reports here](https://github.com/vatesfr/xo-web/issues) (issues, enhancements, ideas etc.).
|
||||
|
||||
## Documentation / Code
|
||||
|
||||
Using GitHub fork/pull-request feature, you may send us some fixes or enhancements.
|
||||
|
||||
Please, do explain:
|
||||
* what you are fixing (issue number if available);
|
||||
* how you did it.
|
||||
|
||||
### Pull requests
|
||||
|
||||
The best way to propose a change on the documentation or the code is
|
||||
to create a [GitHub pull request](https://help.github.com/articles/using-pull-requests/).
|
||||
|
||||
> Your pull request should always been against the `next-release`
|
||||
> branch and not against `stable` which is the stable branch!
|
||||
|
||||
|
||||
1. Create a branch for your work
|
||||
2. Create a pull request for this branch against the `next-release` branch
|
||||
3. Push into the branch until the pull request is ready to merge
|
||||
4. Avoid unnecessary merges: keep you branch up to date by regularly rebasing `git rebase origin/next-release`
|
||||
5. When ready to merge, clean up the history (reorder commits, squash some of them together, rephrase messages): `git rebase -i origin/next-release`
|
||||
|
||||
### Issue triage
|
||||
|
||||
#### Labels
|
||||
|
||||
**Type**
|
||||
|
||||
- bug
|
||||
- cleanup: should be taken care of to avoid technical debt
|
||||
- enhancement
|
||||
- meta: points to other issues and is used to manage long term goals (similar but orthogonal to milestones)
|
||||
- question
|
||||
|
||||
> All issues MUST have one of this label!
|
||||
|
||||
**Difficulty**
|
||||
|
||||
> This helps new people to contribute.
|
||||
|
||||
1. easy
|
||||
2. medium
|
||||
|
||||
**Component**
|
||||
|
||||
- backup
|
||||
- GUI
|
||||
- upstream: not a XO issue → link to the upstream issue and monitor progress
|
||||
|
||||
**Severity**
|
||||
|
||||
1. low: will be fixed when possible
|
||||
2. medium
|
||||
3. high: should be fixed for the next release
|
||||
4. critical: should be fixed ASAP and a patch release is done once fixed
|
||||
|
||||
> A new version MUST NOT be released with a `high` or `critical`
|
||||
> issue.
|
||||
|
||||
**Status**
|
||||
|
||||
For all issues:
|
||||
|
||||
- duplicate: issue is a duplicate → SHOULD be closed
|
||||
- in progress: issue has been assigned and some work is going on
|
||||
|
||||
> For now there is also the `fixed in next-release` label which
|
||||
> indicates this issue is resolved in `next-release` and will be
|
||||
> closed when merged on `stable`.
|
||||
>
|
||||
> This label will no longer be necessary once the branch
|
||||
> reorganization (#69).
|
||||
|
||||
For bugs:
|
||||
|
||||
- confirmed: bug is confirmed → SHOULD be assigned to someone
|
||||
- invalid: bug cannot be confirmed → SHOULD be closed
|
||||
|
||||
For enhancements:
|
||||
|
||||
- draft: proposal is not finished and work should not be started yet
|
||||
- wontfix: not a real enhancement → SHOULD be closed
|
||||
50
docs/delta_backups.md
Normal file
50
docs/delta_backups.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# Continuous Delta backups
|
||||
|
||||
> This feature is released since 4.11 and "Continuous" feature since 4.12
|
||||
|
||||
> WARNING: it works only on XenServer 6.5 or later
|
||||
|
||||
You can export only the delta 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
|
||||
|
||||
Full backups can be represented like this:
|
||||
|
||||
|
||||
|
||||
It means huge files for each backups. Delta backups will only export the difference between the previous backup:
|
||||
|
||||
|
||||
|
||||
Basically, you'll create "key" backups (full backup) and use delta from those. It's the same principle for [MPEG compression and key frame](https://en.wikipedia.org/wiki/Key_frame#Video_compression).
|
||||
|
||||
You can imagine to make a full backup during a weekend, and 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
|
||||
|
||||
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).
|
||||
|
||||
Even if you lost your whole SR or VM, you can use a Full backup to restore it completely, then apply any existing delta on top!
|
||||
|
||||
You can even imagine to use this to backup more often! Because delta will be smaller, and will be **always delta's**.
|
||||
|
||||
### Continuous
|
||||
|
||||
They are called continuous because you'll **never export a full backup** after the first one. We'll merge the oldest delta inside the full:
|
||||
|
||||
|
||||
|
||||
This way we can go "forward" and remove this oldest VHD after the merge:
|
||||
|
||||
|
||||
|
||||
## Create Delta backup
|
||||
|
||||
Just go inside your "Backup" view, and select Delta Backup:
|
||||
|
||||
|
||||
|
||||
Then, create in like a normal backup.
|
||||
27
docs/directpurchase.md
Normal file
27
docs/directpurchase.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Direct purchase
|
||||
|
||||
This is the simplest case: you buy XOA with your registered email account on `xen-orchestra.com`.
|
||||
|
||||
You can choose the edition you want in two places:
|
||||
|
||||
* [the pricing page](https://xen-orchestra.com/#!/pricing)
|
||||
* [your account/member zone](https://xen-orchestra.com/#!/member)
|
||||
|
||||
|
||||
> You need to be logged to make a purchase. If you don't have any account, please [register here](https://xen-orchestra.com/#!/signup).
|
||||
|
||||
From your account zone, click on the Edition you want:
|
||||
|
||||
|
||||
|
||||
Then you need to fill your information:
|
||||
|
||||
|
||||
|
||||
The default payment method is by **credit card**. But you can also choose the "wire transfer" tab (with the "banknote/bank icon):
|
||||
|
||||
|
||||
|
||||
## Wire transfer process
|
||||
|
||||
If you selected wire transfer, you need to upload a transfer proof before we can unlock your XOA. If you don't, you'll have to wait for funds to be actually transferred in our account.
|
||||
43
docs/disaster_recovery.md
Normal file
43
docs/disaster_recovery.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# Disaster recovery
|
||||
|
||||
> DR is available since 4.9
|
||||
|
||||
Disaster Recovery (DR) regroup all the means to recover after losing hosts or storage repositories.
|
||||
|
||||
In this documentation, we'll only see the technical aspect of DR, which is a small part of this vast topic.
|
||||
|
||||
## Best practices
|
||||
|
||||
We strongly encourage you to read some literature on this very topic. Basically, you should be able to recover a major disaster with appropriate amount of time and minimal acceptable data loss.
|
||||
|
||||
To avoid a potentially very long import process (restoring all your backup VMs), we created a specific feature. This is possible thanks to the XO capability to [stream export and import on the same time](https://xen-orchestra.com/blog/vm-streaming-export-in-xenserver/).
|
||||
|
||||
**The goal is to have your DR VMs ready to boot on a dedicated host. This is also a mean to check if you export was fine (if the VM boots).**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Schedule a DR task
|
||||
|
||||
Planning a DR task is very similar to plan a backup or a snapshot. The only difference is that you choose a destination pool.
|
||||
|
||||
|
||||
|
||||
**Warning**: you should have a default SR configured on your targeted pool.
|
||||
|
||||
You DR VMs will be visible "on the other side" as soon the task is done.
|
||||
|
||||
### Retention
|
||||
|
||||
Retention, or **depth**, will apply with the VM name. **If you change the VM name for any reason, it won't be rotated anymore.** This way, you can play with your DR VM without fearing to lose it.
|
||||
|
||||
Also, by default, the DR VM will have a "Disaster Recovery" tag.
|
||||
|
||||
> **Size warning**: high retention number will lead to huge space occupation on your SR.
|
||||
|
||||
## Network conflicts
|
||||
|
||||
If you boot a copy of your production VM, be careful: if they share the same static IP, you'll have troubles.
|
||||
|
||||
A good way to avoid this kind of problems is to remove the network interface and check if the export is correctly done.
|
||||
177
docs/docker_support.md
Normal file
177
docs/docker_support.md
Normal file
@@ -0,0 +1,177 @@
|
||||
# Docker support
|
||||
|
||||
> This feature is available since 4.10
|
||||
|
||||
Basic container lifecycle is documented [in the Administration section](https://xen-orchestra.com/docs/administration.html#docker-management).
|
||||
|
||||
This category is dedicated on creating VM with Docker support.
|
||||
|
||||
## Prerequisite
|
||||
|
||||
* XenServer 6.5
|
||||
* 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
|
||||
|
||||
This first step is needed until Docker is supported nativly in the XenServer API (XAPI).
|
||||
|
||||
> The plugin should be installed in every hosts, even if they are on the same pool.
|
||||
|
||||
1. SSH on your XenServer
|
||||
1. Download the plugin: `wget http://downloadns.citrix.com.edgesuite.net/10343/XenServer-6.5.0-SP1-xscontainer.iso`
|
||||
1. Install it: `xe-install-supplemental-pack XenServer-6.5.0-SP1-xscontainer.iso`
|
||||
|
||||
That's it! You are ready for enjoying Docker support!
|
||||
|
||||
## Docker managed VMs
|
||||
|
||||
There is two ways to use the newest exposed Docker features:
|
||||
|
||||
* install a CoreOS VM
|
||||
* transform an existing VM in supported Docker VM
|
||||
|
||||
### CoreOS
|
||||
|
||||
[CoreOS](https://coreos.com/) is a Linux distribution with bundled software, like `etcd`, `rkt`, `fleet` etc. The ISO install CD is also using `CloudInit` (which is the interesting thing here).
|
||||
|
||||
|
||||
|
||||
#### Create the VM
|
||||
|
||||
First thing first, create a new VM as usual:
|
||||
|
||||
|
||||
|
||||
Then, select the "CoreOS" template in the list and name it as you want:
|
||||
|
||||
|
||||
|
||||
Select the [CoreOS ISO](http://stable.release.core-os.net/amd64-usr/current/coreos_production_iso_image.iso) as source for the installation:
|
||||
|
||||
|
||||
|
||||
You will also notice Cloud Config panel:
|
||||
|
||||
|
||||
|
||||
You'll have to uncomment the line:
|
||||
|
||||
`# - ssh-rsa <Your public key>`
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
Your VM is now ready. Nothing else to do. You can see it thanks to the ship logo in the main view:
|
||||
|
||||
|
||||
|
||||
But also in the VM view, you'll have a Docker panel:
|
||||
|
||||
|
||||
|
||||
It's empty, for sure, because you don't have any Docker container running. So now, let's boot the VM, and create some Docker containers!
|
||||
|
||||
You should be able to access the VM with the user `core` and your SSH key (so no password to write!). Oh and the good news: because Xen tools are installed automatically, you already have the IP address displayed in Xen Orchetra:
|
||||
|
||||
|
||||
|
||||
So in our example (use the `core` user):
|
||||
|
||||
```
|
||||
me@mypc $ ssh core@192.168.100.209
|
||||
|
||||
The authenticity of host '192.168.100.209 (192.168.100.209)' can't be established.
|
||||
ED25519 key fingerprint is SHA256:NDOQgOqUm3J2ZsBEMNFCpXE1lTsu4DKqKN6H7YcxS3k.
|
||||
Are you sure you want to continue connecting (yes/no)? yes
|
||||
Warning: Permanently added '192.168.100.209' (ED25519) to the list of known hosts.
|
||||
Last login: Sun Nov 22 21:00:05 2015
|
||||
CoreOS stable (607.0.0)
|
||||
Update Strategy: No Reboots
|
||||
|
||||
core@core1 ~ $
|
||||
```
|
||||
|
||||
You are now connected! Let's make some tests before installing it on the disks.
|
||||
|
||||
```
|
||||
core@core1 ~ $ docker run --name hello -d busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
|
||||
Unable to find image 'busybox:latest' locally
|
||||
Pulling repository busybox
|
||||
17583c7dd0da: Download complete
|
||||
d1592a710ac3: Download complete
|
||||
Status: Downloaded newer image for busybox:latest
|
||||
150bc05a84971489b2dd5dc99fe0169cdbd23599d6fac55a6a8756a3c6f52853
|
||||
|
||||
```
|
||||
|
||||
Guess what? Check in Xen Orchestra, in the VM view:
|
||||
|
||||
|
||||
|
||||
You can now "cycle" this container: stop, pause or reboot it!
|
||||
|
||||
#### CoreOS installation
|
||||
|
||||
Now it works, you can make a persistent installation of your CoreOS VM. In the same SSH terminal used before, just type:
|
||||
|
||||
```
|
||||
core@core1 ~ $ sudo coreos-install -d /dev/xvda -o xen -C stable
|
||||
```
|
||||
|
||||
You should have this output:
|
||||
|
||||
```
|
||||
Downloading the signature for http://stable.release.core-os.net/amd64-usr/607.0.0/coreos_production_xen_image.bin.bz2...
|
||||
...
|
||||
Downloading, writing and verifying coreos_production_xen_image.bin.bz2...
|
||||
Success! CoreOS stable 607.0.0 (xen) is installed on /dev/xvda
|
||||
```
|
||||
|
||||
You can reboot the VM and even eject the CoreOS ISO: it will boot as a normal VM now!
|
||||
|
||||
### How it works
|
||||
|
||||
During the VM creation, the XSContainer plugin will create an extra disk: "Automatic Config Drive", with a size of 2MB. This is where the necessary configuration you edited previously (with the SSH key) is passed to the CoreOS VM! In fact, it uses `CloudInit`.
|
||||
|
||||
#### What is CloudInit?
|
||||
|
||||
`CloudInit` is a software created to simplify VM provisioning for Cloud instances: it was originally developed for the Amazon Cloud, but works with all major Cloud ready systems, like OpenStack for example.
|
||||
|
||||
Basically, it reads configuration during the boot, allowing:
|
||||
|
||||
* SSH keys management for newly created VM/instances
|
||||
* Root disk filesystem growing
|
||||
* User/group management
|
||||
* Arbitrary commands 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 it.
|
||||
|
||||
### Existing VMs
|
||||
|
||||
You can also use the XSContainer plugin to "transform" an existing VM into a "Docker" managed one.
|
||||
|
||||
You need to have this installed inside the VM:
|
||||
|
||||
* Docker
|
||||
* openssh-server
|
||||
* ncat
|
||||
|
||||
For Debian/Ubuntu like distro: `apt-get install docker.io openssh-server nmap`. For RHEL and derived (CentOS...): `yum install docker openssh-server nmap-ncat`.
|
||||
|
||||
To use Docker as non-root, please add the user you want inside the "Docker" group.
|
||||
|
||||
Now, you need to access to your host (Dom0) and use the following command:
|
||||
|
||||
```
|
||||
xscontainer-prepare-vm -v <VM_UUID> -u <username>
|
||||
```
|
||||
|
||||
> Because "prepare-vm" is not exposed outside the Dom0 (yet?), we can't use Xen Orchestra to give you a one-click solution so far.
|
||||
56
docs/editions.md
Normal file
56
docs/editions.md
Normal file
@@ -0,0 +1,56 @@
|
||||
# Editions
|
||||
|
||||
There is 4 **editions** of Xen Orchestra Appliance (XOA):
|
||||
|
||||
* Free
|
||||
* Starter
|
||||
* Enterprise
|
||||
* Premium
|
||||
|
||||
**Also, you can try all features in the Premium Edition for free (without any commitment) for 15 days by registering on the trial. [Read here on how to do it](trial.md).**
|
||||
|
||||
### Free
|
||||
|
||||
This is a basic edition, allowing you to do administrator tasks on a virtualized infrastructure. It's "like" XenCenter. You can:
|
||||
|
||||
* Create VMs, SRs etc.
|
||||
* Access to web consoles
|
||||
* Edit resources (VM, pools etc.)
|
||||
* Make snapshots
|
||||
* Migrate VMs
|
||||
|
||||
That's more or less features what you can see in the [administration page](administration.md).
|
||||
|
||||
### Starter
|
||||
|
||||
Starter Edition is intended to system administrators who want to make more with their current XenServer infrastructure. This version is also bundled with our pro support!
|
||||
|
||||
You got, in extra from the Free Edition:
|
||||
|
||||
* [Scheduled backups](full_backups.md)
|
||||
* [Scheduled snapshots](rolling_snapshots.md)
|
||||
* Patch detection and application in one click
|
||||
* XenServer Docker management via XenServer plugin
|
||||
|
||||
You'll also have access to our ticket system to report issue and be helped in less than 72h.
|
||||
|
||||
### Enterprise
|
||||
|
||||
Enterprise Edition allows you to access a lot more features than Starter:
|
||||
|
||||
* Disaster Recovery
|
||||
* Continuous Delta Backup
|
||||
* Live stats
|
||||
* ACLs + LDAP/SSO
|
||||
|
||||
In addition, you'll have faster support to answer your issues/questions.
|
||||
|
||||
### Premium
|
||||
|
||||
Premium is the highest edition, with all features included without any limitations. This means:
|
||||
|
||||
* Dataviz
|
||||
* Infrastructure health check
|
||||
* Job Manager
|
||||
* Continuous Replication
|
||||
* Self Service
|
||||
21
docs/features.md
Normal file
21
docs/features.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# Features
|
||||
|
||||
All the following features are exposed through the web client, XO-Web, which is using a [responsive design](https://xen-orchestra.com/blog/xen-orchestra-responsive-design/).
|
||||
|
||||
We 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)
|
||||
* [Auto scalability](auto_scalability.html)
|
||||
* [Forecaster](forecaster.html)
|
||||
|
||||
|
||||
19
docs/forecaster.md
Normal file
19
docs/forecaster.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# Forecaster
|
||||
|
||||
> This feature is planned for 2016.
|
||||
|
||||
Thanks to [machine-learning](https://en.wikipedia.org/wiki/Machine_learning), we should be able to analyze previous events (load evolution, RAM usage, etc.) and to forecast what would come next.
|
||||
|
||||
It could leads to:
|
||||
|
||||
* forecast report and alerts inside advanced reports
|
||||
* taking automatic actions before bottlenecks happened
|
||||
* match the resources needed for a predicted load
|
||||
* green IT! By cutting useless nodes in quiet moment and boot them just before the load rise
|
||||
|
||||
## Example
|
||||
|
||||
The system detects that every Monday, you got a huge CPU spike on some VMs. It could:
|
||||
|
||||
* report you this information
|
||||
* scale up those VMs just before those spikes, and scale them down after
|
||||
188
docs/from_the_sources.md
Normal file
188
docs/from_the_sources.md
Normal file
@@ -0,0 +1,188 @@
|
||||
# From the sources
|
||||
|
||||
**WARNING**: we don't make support for this manual installation. We cannot guarantee anything if used in production. Use it at your own risks.
|
||||
|
||||
**WARNING 2**: **It's impossible to predict the result of a build for any Node and NPM versions**. Please consider to use XOA before trying to play with the manual build, which can be difficult if you are not used to NodeJS and NPM.
|
||||
|
||||
> Please take time to read it carefully.
|
||||
|
||||
This installation is validated against a fresh Debian 8 (Jessie) 64 bits. It should be almost the same on others dpkg systems. For RPMs based OS, it should be close, because most of our dependencies came from NPM and not the OS itself.
|
||||
|
||||
As you may have seen, in other parts of the documentation, XO is composed of two parts: [XO-Server](https://github.com/vatesfr/xo-server/) and [XO-Web](https://github.com/vatesfr/xo-web/). They can be installed separately, even on different machines, but for the sake of simplicity we will set them up together.
|
||||
|
||||
## Packages and Pre-requisites
|
||||
|
||||
### NodeJS
|
||||
|
||||
XO needs Node.js. You can install it:
|
||||
- by [following this procedure](https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager).
|
||||
- on Wheezy, the build from source was tested and working well.
|
||||
- by using *n*, documented just below.
|
||||
|
||||
We'll use `n` because it's powerful and flexible. First, you need `curl`. Then, install it as root:
|
||||
|
||||
```bash
|
||||
curl -o /usr/local/bin/n https://raw.githubusercontent.com/visionmedia/n/master/bin/n
|
||||
chmod +x /usr/local/bin/n
|
||||
n lts
|
||||
```
|
||||
|
||||
> Please use the LTS version of Node
|
||||
|
||||
We'll consider at this point that you've got a working node on your box. E.g:
|
||||
|
||||
```
|
||||
$ node -v
|
||||
v4.2.4
|
||||
```
|
||||
|
||||
Be sure to have a recent version of `npm` by using `npm i -g npm`:
|
||||
|
||||
```
|
||||
$ npm -v
|
||||
3.5.3
|
||||
```
|
||||
|
||||
### Packages
|
||||
|
||||
XO needs those packages to be built and installed. Redis is used as a database by XO.
|
||||
|
||||
```
|
||||
apt-get install build-essential redis-server libpng-dev git python-minimal
|
||||
```
|
||||
|
||||
## Fetching the Code
|
||||
|
||||
You may either download them [here](https://github.com/vatesfr/xo-server/archive/stable.zip) and [here](https://github.com/vatesfr/xo-web/archive/stable.zip) or use `git` with these repositories from `http://github.com/vatesfr/xo-server` and `http://github.com/vatesfr/xo-web`:
|
||||
|
||||
```
|
||||
git clone -b stable http://github.com/vatesfr/xo-server
|
||||
git clone -b stable http://github.com/vatesfr/xo-web
|
||||
```
|
||||
|
||||
## Installing dependencies
|
||||
|
||||
### XO-Server
|
||||
|
||||
Once you have it, use `npm`, as the non-root user owning the fetched code, to install the other dependencies: go into XO-Server directory and launch the following command:
|
||||
|
||||
```
|
||||
npm install && npm run build
|
||||
```
|
||||
|
||||
Then, you have to create a config file for XO-Server:
|
||||
|
||||
```
|
||||
cp sample.config.yaml .xo-server.yaml
|
||||
```
|
||||
|
||||
Edit and uncomment it to have the right path to deliver XO-Web, because XO-Server embeds an HTTP server (we assume that XO-Server and XO-Web are on the same directory). It's near the end of the file:
|
||||
|
||||
```yaml
|
||||
mounts: '/': '../xo-web/dist/'
|
||||
```
|
||||
> Note this `dist` folder will be created in the next step (see the XO-Web section)
|
||||
|
||||
WARNING: YAML is very strict with indentation: use spaces for it, not tabs.
|
||||
|
||||
In this config file, you can also change default ports (80 and 443) for XO-Server.
|
||||
|
||||
You can try to start XO-Server to see if it works. You should have something like that:
|
||||
|
||||
```
|
||||
$ npm start
|
||||
WebServer listening on localhost:80
|
||||
[INFO] Default user: "admin@admin.net" with password "admin"
|
||||
```
|
||||
|
||||
### XO-Web
|
||||
|
||||
First, we'll also install dependencies:
|
||||
|
||||
```
|
||||
$ npm install
|
||||
```
|
||||
|
||||
You can now install `bower` dependencies and build the application:
|
||||
|
||||
```
|
||||
$ npm run build
|
||||
```
|
||||
|
||||
## Running XO
|
||||
|
||||
The sole part you have to launch is XO-Server which is quite easy to do, just launch the `xo-server` script, which is in the root of XO-Server's directory:
|
||||
|
||||
```
|
||||
$ npm start
|
||||
```
|
||||
That's it! Go on your browser to the XO-Server IP address, and it works! :)
|
||||
|
||||
## Misc
|
||||
|
||||
- You can also consider using [forever](https://github.com/nodejitsu/forever) to have always the process running.
|
||||
|
||||
```
|
||||
$ npm install -g forever
|
||||
$ forever start bin/xo-server
|
||||
```
|
||||
|
||||
- Our stable branch is *stable* and the beta branch is *next-release*. You can change it if you want to test our latest features (on both XO-Server and XO-Web, do NOT mix them):
|
||||
|
||||
```
|
||||
$ git checkout next-release
|
||||
```
|
||||
- If you want to update your current version, do this on both repositories:
|
||||
|
||||
```
|
||||
$ git pull --ff-only
|
||||
$ npm install
|
||||
$ npm run build
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If you have problem during the buiding phase in `xo-web`, follow these steps:
|
||||
|
||||
1. `rm -rf node_modules`
|
||||
1. `npm install`
|
||||
1. `npm run build`
|
||||
|
||||
Same principle for `xo-server`:
|
||||
|
||||
1. `rm -rf node_modules`
|
||||
1. `npm install`
|
||||
|
||||
## FreeBSD
|
||||
|
||||
If you are using FreeBSD, you need to install these packages:
|
||||
|
||||
```
|
||||
pkg install gmake redis python git npm node autoconf
|
||||
```
|
||||
|
||||
You can update `npm` itself right now with a `npm update -g`
|
||||
|
||||
A few of the npm packages look for system binaries as part of their installation, and if missing will try to build it themselves. Installing these will save some time and allow for easier upgrades later:
|
||||
|
||||
```
|
||||
pkg install jpeg-turbo optipng gifsicle
|
||||
```
|
||||
|
||||
Because FreeBSD is shipped with CLANG and not GCC, you need to do this:
|
||||
|
||||
```
|
||||
ln -s /usr/bin/clang++ /usr/local/bin/g++
|
||||
```
|
||||
|
||||
To enable redis on boot, add this in your `/etc/rc.conf`:
|
||||
|
||||
```
|
||||
redis_enable="YES"
|
||||
```
|
||||
|
||||
Don't forget to start redis if you don't reboot now:
|
||||
|
||||
```
|
||||
service redis start
|
||||
```
|
||||
94
docs/full_backups.md
Normal file
94
docs/full_backups.md
Normal file
@@ -0,0 +1,94 @@
|
||||
# Full backups
|
||||
|
||||
> Full backups are released since 4.3
|
||||
|
||||
You can schedule full backups of your VMs, by exporting them in the local XOA file-system, or directly in a NFS share. "Depth" parameter allow to modify the retention (removing the oldest one).
|
||||
|
||||
[](https://xen-orchestra.com/blog/backup-your-xenserver-vms-with-xen-orchestra/)
|
||||
|
||||
Full backups are space consuming! But they allow a very simple restoration without anything to think of (the file will contain all the VM disks and information).
|
||||
|
||||
## Remote stores
|
||||
|
||||
This where you can create your stores, places where your backups will be exported.
|
||||
|
||||
|
||||
|
||||
Supported stores:
|
||||
|
||||
* local stores (any folder in XOA filesystem)
|
||||
* NFS
|
||||
* SMB (CIFS)
|
||||
|
||||
### SMB
|
||||
|
||||
Just read twice the UI when you add a SMB store. If you have:
|
||||
|
||||
* `192.168.1.99` as SMB host
|
||||
* `Backups` as folder
|
||||
* no subfolder
|
||||
|
||||
You'll have to fill it like this:
|
||||
|
||||
|
||||
|
||||
**PATH TO BACKUP is only needed if you have subfolders in your share.**
|
||||
|
||||
### Other stores
|
||||
|
||||
If you need to mount an unsupported store, you could always do it manually:
|
||||
|
||||
1. mount your store inside XOA manually, e.g in `/media/myStore`
|
||||
2. in the web interface, select a "local" store and point it to your `/media/myStore` folder.
|
||||
|
||||
Any Debian Linux mount point could be supported this way, until we add further options directly in the web interface.
|
||||
|
||||
## Restore backups
|
||||
|
||||
All your scheduled backup are acccessible in the "Restore" view in backup section of Xen Orchestra.
|
||||
|
||||
1. Select your mountpoint
|
||||
2. Choose the file you want to restore
|
||||
3. Select the host/pool you want to restore it
|
||||
|
||||
|
||||
|
||||
|
||||
## About 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)
|
||||
|
||||
If you have compression on your NFS share (or destination file-system like ZFS), you can disable compression in Xen Orchestra.
|
||||
|
||||
Here is a network usage graph with 2 identical backup, the first one without compression:
|
||||
|
||||
|
||||
|
||||
## Add a disk for local backups
|
||||
|
||||
If you want to use XOA to store all your backups, you need to attach a large disk to it. This can be done in live.
|
||||
|
||||
First, after your disk is attached to XOA, you'll have to find the new disk name with `fdisk -l`. It's probably `xvdb`.
|
||||
|
||||
Then, create a filesystem on it:
|
||||
|
||||
```
|
||||
mkfs.ext4 /dev/xvdb
|
||||
|
||||
```
|
||||
|
||||
If you already have backups done, you can move them to the new disk. The orignal backup folder is in `/var/lib/xoa-backups`.
|
||||
|
||||
To get the mount point persistent in XOA, edit the `/etc/fstab` file, and add:
|
||||
|
||||
```
|
||||
/dev/xvdb /var/lib/xoa-backups ext4 defaults 0 0
|
||||
```
|
||||
|
||||
This way, without modifying your previous scheduled snapshot, they will be written in this local mountpoint!
|
||||
19
docs/github.md
Normal file
19
docs/github.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# GitHub
|
||||
|
||||
This plugin allows GitHub users to authenticate to Xen-Orchestra.
|
||||
|
||||
The first time a user signs in, XO will create a new XO user with the same identifier, without any permission.
|
||||
|
||||
First you need to configure a new app in your GitHub account:
|
||||
|
||||
|
||||
|
||||
When you got your `clientID` and your `clientSecret`, you can configure them in the GitHub Plugin inside "Settings/Plugins" view of Xen Orchestra.
|
||||
|
||||
Be sure to activate the plugin after you save the configuration (button on top). When it's done, you'll see a link in the log in view, this is where you'll go to authenticate:
|
||||
|
||||
|
||||
|
||||
## Debugging
|
||||
|
||||
If you can't log in with your GitHub settings, please check the logs of `xo-server` while you attempt to connect. It will give you hints about the error encountered. You can do that with a `tail -f /var/log/syslog -n 100` on your XOA.
|
||||
41
docs/google.md
Normal file
41
docs/google.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# Google
|
||||
|
||||
This plugin allows Google users to authenticate to Xen-Orchestra.
|
||||
|
||||
The first time a user signs in, XO will create a new XO user with the same identifier, without any permission.
|
||||
|
||||
|
||||
## Creating the Google project
|
||||
|
||||
[Create a new project](https://console.developers.google.com/project):
|
||||
|
||||
|
||||
|
||||
Enable the Google+ API:
|
||||
|
||||
|
||||
|
||||
Add OAuth 2.0 credentials:
|
||||
|
||||
|
||||
|
||||
|
||||
## Configure the XO plugin
|
||||
|
||||
In Settings, then Plugins, expand the Google plugin detail and provide:
|
||||
|
||||
* a `clientID` e.g `326211154583-nt2s112d3t7f4f1hh49oo9164nivvbnu.apps.googleusercontent.com`
|
||||
* a `clientSecret`, e.g `HTDb8I4jXiLRMaRL15qCffQ`
|
||||
* the `callbackURL`, e.g `http://xo.company.net/signin/google/callback`
|
||||
|
||||
|
||||
|
||||
Be sure to activate the plugin after you save the configuration (button on top).
|
||||
|
||||
You can now connect with your Google account in the log in page:
|
||||
|
||||
![Google log in]()
|
||||
|
||||
## Debugging
|
||||
|
||||
If you can't log in with your Google settings, please check the logs of `xo-server` while you attempt to connect. It will give you hints about the error encountered. You can do that with a `tail -f /var/log/syslog -n 100` on your XOA.
|
||||
15
docs/health.md
Normal file
15
docs/health.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Health
|
||||
|
||||
This view will help you to find any bottleneck or to compare the metrics of your infrastructure.
|
||||
|
||||
### Heatmap
|
||||
|
||||
A heatmap allows its reader to understand when your VMs or hosts are stressed. Values are relative, thus it's easy to detect trends or spikes.
|
||||
|
||||
[](https://xen-orchestra.com/blog/xen-orchestra-4-4/#heatmapforinfrastructurehealth).
|
||||
|
||||
### Event correlation
|
||||
|
||||
This is the place to compare metrics on comparable objects (VMs to VMs, hosts to hosts).
|
||||
|
||||
[](https://xen-orchestra.com/blog/xen-orchestra-4-6#eventcorrelation).
|
||||
5
docs/installation.md
Normal file
5
docs/installation.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Installation
|
||||
|
||||
There are two ways to install Xen Orchestra. If you are just a user and not a developer, please consider using the pre-built appliance, as this is the easier way (XOA).
|
||||
|
||||
Be advised that our default user and password for a fresh install are **admin@admin.net** and **admin**. Remember to change the default password immediately after installation.
|
||||
9
docs/invoices.md
Normal file
9
docs/invoices.md
Normal file
@@ -0,0 +1,9 @@
|
||||
# Invoices
|
||||
|
||||
You can find all your invoices in your member zone: https://xen-orchestra.com/#!/member
|
||||
|
||||
Get in the "Invoices" tab:
|
||||
|
||||
|
||||
|
||||
You can download your invoice in PDF format, by clicking in the "Export" row, on the invoice name with the PDF extension.
|
||||
22
docs/ldap.md
Normal file
22
docs/ldap.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# LDAP
|
||||
|
||||
XO currently support connection to LDAP directories, like *Open LDAP* or *Active Directory*.
|
||||
|
||||
To configure your LDAP, go need to go in the *Plugins* section in the "Settings" view. Then configure it:
|
||||
|
||||
|
||||
|
||||
Don't forget to save the configuration, and also check if the plugin is activated (green button on top).
|
||||
|
||||
## Filters
|
||||
|
||||
LDAP Filters allow you to match properly your user. It's not an easy task to always find the right filter, and it's entirely depending of your LDAP configuration. Still, here is a list of common filters:
|
||||
|
||||
* `'(uid={{name}})'` is usually the default filter for *Open LDAP*
|
||||
* `'(cn={{name}})'`, `'(sAMAccountName={{name}})'`, `'(sAMAccountName={{name}}@<domain>)'` or even `'(userPrincipalName={{name}})'` are widely used for *Active Directory*. Please check with your AD Admin to find the right one.
|
||||
|
||||
After finishing the configuration, you can try to log in with your LDAP username and password. Finally, right after your initial successful log in, your account will be visible in the user list of Xen Orchestra.
|
||||
|
||||
## Debugging
|
||||
|
||||
If you can't log in with your LDAP settings, please check the logs of `xo-server` while you attempt to connect. It will give you hints about the error encountered. You can do that with a `tail -f /var/log/syslog -n 100` on your XOA.
|
||||
71
docs/load_balancing.md
Normal file
71
docs/load_balancing.md
Normal file
@@ -0,0 +1,71 @@
|
||||
# Load balancing
|
||||
|
||||
> Load balancing is a feature coming for Q2 2016.
|
||||
|
||||
The goal here is to **distribute the VMs load** in the best way possible on your servers.
|
||||
|
||||
Because Xen Orchestra is connected to [multiple pools](xo-server.md) and XenServer supports [live storage motion](https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/storage-xenmotion-live-storage-migration-with-citrix-xenserver.pdf?accessmode=direct), we can make load balancing on a **whole XenServer infrastructure** (even between remote Data Centers).
|
||||
|
||||
A load balancing policy is called a "**plan**".
|
||||
|
||||
## Configure a plan
|
||||
|
||||
In this coming new view, you'll be able to configure a new load balancing plan, or to edit an existing one.
|
||||
|
||||
A plan has:
|
||||
|
||||
* a name
|
||||
* pool(s) where to apply the policy
|
||||
* a mode (see paragraph below)
|
||||
* a behavior (aggressive, normal, low)
|
||||
|
||||
### Plan modes
|
||||
|
||||
There is 3 modes possible:
|
||||
|
||||
* performance
|
||||
* density
|
||||
* mixed
|
||||
|
||||
#### Performance
|
||||
|
||||
VMs are placed to use all possible resources. This means balance the load to give the best overall performance possible. This tends to use all hosts available to spread the load.
|
||||
|
||||
#### Density
|
||||
|
||||
This time, the objective is to use less hosts as possible, and to concentrate your VMs. In this mode, you can choose to shutdown unused (and compatible) hosts.
|
||||
|
||||
#### Mixed
|
||||
|
||||
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
|
||||
|
||||
In this case, you'll have best of both when needed (energy saving during the night and performance during the day).
|
||||
|
||||
### Threshold
|
||||
|
||||
In a plan, you can configure various thresholds:
|
||||
|
||||
* 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%.
|
||||
|
||||
For the free memory, it will be triggered if there is **less** free RAM than the threshold.
|
||||
|
||||
## More
|
||||
|
||||
The issue is [opened here](https://github.com/vatesfr/xo-web/issues/423).
|
||||
|
||||
|
||||
|
||||
* `xo-analysis` get stats from `xo-server` and build reports/alerts
|
||||
* `xo-director` get reports/alerts
|
||||
* `xo-director` migrate VMs from various hosts (and even stop "useless" hosts)
|
||||
|
||||
|
||||
## External resources
|
||||
|
||||
Citrix WLB Admin guide: http://docs.citrix.com/content/dam/docs/en-us/xenserver/xenserver-60/XenServer-6.0.0-wlb-userguide.pdf
|
||||
26
docs/logs.md
Normal file
26
docs/logs.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Logs
|
||||
|
||||
This section will explain how to check the XOA logs, and be able to detect issues.
|
||||
|
||||
## CLI
|
||||
|
||||
All XOA logs are stored in `/var/log/syslog`.
|
||||
|
||||
To filter only on what you need, you can use `journalctl`. Let's see some example to filter only logs for `xo-server`:
|
||||
|
||||
```
|
||||
$ journalctl -u xo-server -f -n 50
|
||||
```
|
||||
|
||||
This will return the 50 last lines and tail the file. If you have an error message in your application, start this command and try to reproduce the issue. You'll see clearly what's the problem.
|
||||
|
||||
You can also filter for the updater program:
|
||||
|
||||
```
|
||||
$ journalctl -u xoa-updater -f -n 50
|
||||
```
|
||||
|
||||
|
||||
## From the web interface
|
||||
|
||||
> This feature is under development.
|
||||
17
docs/others.md
Normal file
17
docs/others.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# 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, get a look there:
|
||||
|
||||
* [LDAP plugin](https://github.com/vatesfr/xo-server-auth-ldap)
|
||||
* [GitHub authentication](https://github.com/vatesfr/xo-server-auth-github)
|
||||
|
||||
XO's API can be explored through the `xo-cli` client (please refer to the previous section for details).
|
||||
|
||||
In the future, we'll add modules for:
|
||||
|
||||
* performance analysis
|
||||
* reporting
|
||||
* load management
|
||||
* various authentication providers
|
||||
17
docs/plugins.md
Normal file
17
docs/plugins.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Plugins
|
||||
|
||||
> Since 4.11, installed plugins are automatically displayed
|
||||
|
||||
Xen Orchestra plugins allow to extend features without rewriting the core of the application.
|
||||
|
||||
You can see your installed plugins in "Settings" then "Plugins" page:
|
||||
|
||||
|
||||
|
||||
Every 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
|
||||
15
docs/purchase.md
Normal file
15
docs/purchase.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Purchase
|
||||
|
||||
You can buy XOA in multiple way, depending of you need. Click on the following links to have 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)
|
||||
|
||||
## XOA Editions
|
||||
|
||||
To find which XOA Edition fits your needs, please read the [dedicated page about it](editions.md).
|
||||
|
||||
## Invoices
|
||||
|
||||
Invoices are available in PDF format. [Details here](invoices.md).
|
||||
3
docs/recipes.md
Normal file
3
docs/recipes.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# Recipes
|
||||
|
||||
Here is some configuration example to leverage possibilities with Xen Orchestra.
|
||||
28
docs/reseller.md
Normal file
28
docs/reseller.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Reseller
|
||||
|
||||
The reseller/partner program allows you to buy XOAs and to assign them to your final client email.
|
||||
|
||||
> For reselling XOA to your clients, you'll have 15% discount on each purchase!
|
||||
|
||||
## Apply to the program
|
||||
|
||||
You need to be registered first. Then go on [the partner page here](https://xen-orchestra.com/#!/partner) and click on the "Register button":
|
||||
|
||||
|
||||
|
||||
Now, you just have to wait for us to accept your request. As soon it's done, you access to your partner zone, [at the same partner page](https://xen-orchestra.com/#!/partner).
|
||||
|
||||
## Purchase XOAs
|
||||
|
||||
Now you could see the reseller interface, you can follow those steps:
|
||||
|
||||
1. choose the edition you want to purchase for your client
|
||||
2. a new line is now displayed on the bottom
|
||||
3. on this new line, upload your wire transfer proof
|
||||
4. assign/bind the plan to your final client email
|
||||
|
||||
You'll have all the invoices in your account.
|
||||
|
||||
## From your client perspective
|
||||
|
||||
Your client can use the email assigned to register its appliance, and unlock the Edition you purchased.
|
||||
24
docs/resources_delegation.md
Normal file
24
docs/resources_delegation.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Resources delegation
|
||||
|
||||
This chapter is about how to delegate resources (VM, hosts) 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
|
||||
|
||||
> Remember: admins can do everything, thus permissions don't apply on them. It's only for *users*.
|
||||
|
||||
## Groups
|
||||
|
||||
Groups are a set of users. You can use groups to apply permissions/ACLs on a whole set of users, instead of repeating superfluous operations on multiple users separately.
|
||||
|
||||
Groups can be created and managed in the "Groups" view inside "Settings" menu.
|
||||
|
||||
1. Create a group by giving it a name
|
||||
2. Edit this group and add users in it
|
||||
|
||||
Any group can be edited as you like after its creation.
|
||||
|
||||
|
||||
35
docs/reverse_proxy.md
Normal file
35
docs/reverse_proxy.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# Reverse proxy
|
||||
|
||||
## Apache
|
||||
|
||||
As XO-web and XO-server communicates with *WebSockets*, you need to have the `mod_proxy_wstunnel` in Apache (please [check the Apache documentation](http://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html) about it). It's available for Apache 2.4.5 and later.
|
||||
|
||||
|
||||
Please use this configuration in this order or it will not work:
|
||||
|
||||
```apache
|
||||
ProxyPass /[<path>]/api ws://<xo-server ip>:<xo-server port>/api
|
||||
ProxyPass /[<path>] http://<xo-server ip>:<xo-server port>/
|
||||
|
||||
ProxyPassReverse /[<path>] /
|
||||
```
|
||||
|
||||
|
||||
## NGINX
|
||||
|
||||
Just configure your VirtualHost as usual (or your default site), with a section `location` like this one:
|
||||
|
||||
|
||||
```nginx
|
||||
location /[<path>] {
|
||||
proxy_pass http://<XOA ip address>[:<port>]/;
|
||||
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Connection "upgrade";
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
|
||||
proxy_redirect default;
|
||||
}
|
||||
```
|
||||
|
||||
That's all!
|
||||
19
docs/roadmap.md
Normal file
19
docs/roadmap.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# Roadmap
|
||||
|
||||
Please consider it as an indicative roadmap, things can change.
|
||||
|
||||
Item are expressed in a (roughly) decreasing priority order.
|
||||
|
||||
## Features
|
||||
|
||||
- [Interface redesign](https://xen-orchestra.com/blog/announcing-xen-orchestra-5-x/) (in progress)
|
||||
- [Load balancing](load_balancing.md) (in progress)
|
||||
- [Alerts](alerts.md)
|
||||
- [Auto scalability](auto_scalability.md)
|
||||
- [Forecaster](forecaster.md)
|
||||
|
||||
|
||||
## Fixes
|
||||
|
||||
- Better browser scalability for huge infrastructures
|
||||
- [Resolve known bugs](https://github.com/vatesfr/xo/blob/master/doc/known_bugs/README.md)
|
||||
17
docs/rolling_snapshots.md
Normal file
17
docs/rolling_snapshots.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Rolling snapshots
|
||||
|
||||
> Rolling snapshots are released since 4.2
|
||||
|
||||
This feature is close to Backups, but it creates a snapshot when planned to do so. It also handles the retention (to remove the oldest snapshot). This feature is very convenient to rollback to a previous state.
|
||||
|
||||
**Warning**: snapshots are not backups. All snapshots are on the same Storage 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).
|
||||
|
||||
> Advice: due to space usage, rolling snapshots should be avoided for large VMs on non-thin provisioned storages.
|
||||
|
||||
Example:
|
||||
|
||||
* schedule a nightly snapshot for a group of VM, let's say at 4:30 in the morning. With a max snapshot at 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 let you a month max of revert
|
||||
* and so forth!
|
||||
23
docs/saml.md
Normal file
23
docs/saml.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# SAML
|
||||
|
||||
> SAML authentication plugin for XO-Server
|
||||
|
||||
This plugin allows SAML users to authenticate to Xen-Orchestra.
|
||||
|
||||
The first time a user signs in, XO will create a new XO user with the same identifier.
|
||||
|
||||
## Configuration
|
||||
|
||||
In the "Settings" then "Plugins" view, expand the SAML plugin configuration. Then provide the needed fields:
|
||||
|
||||
|
||||
|
||||
Save the configuration and then activate the plugin (button on top).
|
||||
|
||||
> Important: When registering your instance to your identity provider,
|
||||
> you must configure its callback URL to
|
||||
> `http://xo.example.net/signin/saml/callback`!
|
||||
|
||||
## Debugging
|
||||
|
||||
If you can't log in with your SAML settings, please check the logs of `xo-server` while you attempt to connect. It will give you hints about the error encountered. You can do that with a `tail -f /var/log/syslog -n 100` on your XOA.
|
||||
54
docs/scheduler.md
Normal file
54
docs/scheduler.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# Job manager
|
||||
|
||||
> Job manager is released since 4.10
|
||||
|
||||
The key idea is to be able to schedule any action (migrate, reboot etc.), like for backups, snapshots or DR.
|
||||
|
||||
In the main menu, go inside the "Job Manager" section:
|
||||
|
||||
|
||||
|
||||
You can now **schedule all actions** on your hosts, VMs, or ACLs. It's configured in 2 steps:
|
||||
|
||||
1. Create a job
|
||||
1. Schedule it!
|
||||
|
||||
Real example, step by step: **Creating a job called "security reboot"** (in this case, restart "nfs" and "Core1" VMs):
|
||||
|
||||
|
||||
|
||||
Note that you can execute this job **now** by clicking on the orange play button (to test it for instance):
|
||||
|
||||
|
||||
|
||||
**Schedule the job** (every Sunday at 5:00 AM):
|
||||
|
||||
|
||||
|
||||
And this is it! The job is listed in the Overview:
|
||||
|
||||
|
||||
|
||||
Possibilities are infinite! You can plan a LOT of things (any actions on a VM, like migrate, start, clone, suspend etc. Same thing apply on a host).
|
||||
|
||||
## Examples
|
||||
|
||||
### Save on your electric bill
|
||||
|
||||
* plan a live migration on your VMs at 11:00PM on a less powerful host, to shutdown the big one
|
||||
* start the big server at 6:00AM and migrate back VMs 15 minutes later
|
||||
|
||||
### Scale when needed
|
||||
|
||||
* schedule the boot of extra-VMs during your usual activity spikes (horizontal scaling)
|
||||
* also plan 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
|
||||
|
||||
* 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 week end)
|
||||
* restore them Monday at 6:00AM
|
||||
74
docs/self_service.md
Normal file
74
docs/self_service.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# Self Service
|
||||
|
||||
The self-service feature is the possibility for users to create new VMs. That's different from delegating existing resources to them, and it leads to a lot of side-effects.
|
||||
|
||||
> This feature is not yet available yet. However, it should be released very soon.
|
||||
|
||||
## Set of resources
|
||||
|
||||
To create a new set of resources, go inside the "Self Service" section in the main menu:
|
||||
|
||||
|
||||
|
||||
### Create a set
|
||||
|
||||
> Only an admin can create a set of resources
|
||||
|
||||
To allow people creating 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 need first to decide which resources will be used.
|
||||
|
||||
In this example below, we'll create a set called **"sandbox"** with:
|
||||
|
||||
* "devs" group could access 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 could use
|
||||
* "SSD NFS" is the only SR where they can create VMs
|
||||
* "Pool-wide network with eth0" is the only available network for them
|
||||
|
||||
|
||||
|
||||
As you can see, only compatible hosts are shown and could be used for this resource set (here, hosts in another pools aren't). This way, you can be sure to have resource free for other task than self-service.
|
||||
|
||||
> Don't forget to add an ISO SR to allow your users to install VMs with CD if necessary
|
||||
|
||||
#### Quotas
|
||||
|
||||
Then, you can define quotas on this set:
|
||||
|
||||
* max vCPUs
|
||||
* max RAM
|
||||
* max disk usage
|
||||
|
||||
When you click on create, you can see the resource set and remove or edit it:
|
||||
|
||||
|
||||
|
||||
## Usage (user side)
|
||||
|
||||
As soon a user is inside a resource set, it displays a new button in its main view: the gree icon with the "plus" sign:
|
||||
|
||||
|
||||
|
||||
Now, the user can create a VM with only the resources given in the set:
|
||||
|
||||
|
||||
|
||||
And the recap before creation:
|
||||
|
||||
|
||||
|
||||
If the "Create" button is disabled, it means the user requested more resources than available.
|
||||
|
||||
Finally, if a user is inside many sets, they can be switched in the top right of the screen.
|
||||
|
||||
|
||||
## Toward the Cloud
|
||||
|
||||
Self-service is a major step in the Cloud. Combine it with our [Cloudinit compatible VM creation](cloudinit.md) for a full experience:
|
||||
|
||||
* create a Cloud ready template
|
||||
* create a set and put Cloud templates inside
|
||||
* delegate this set to a group of users
|
||||
|
||||
Now, your authorized users can create VMs with their SSH keys, grow template disks if needed. Everything inside a "sandbox" (the set) you defined earlier!
|
||||
|
||||
|
||||
30
docs/through_purchase_department.md
Normal file
30
docs/through_purchase_department.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Through purchase department
|
||||
|
||||
If you can't purchase for your own account, because you need to go through a dedicated purchase department in your company, this is the process you need to follow.
|
||||
|
||||
In means, there will be:
|
||||
|
||||
* a "billing contact" (in general, the purchaser email). This account will have access to invoices. And this is the account which make the purchase.
|
||||
* a "technical contact", the email of the system administrator using the solution and making support requests.
|
||||
|
||||
|
||||
## As "billing contact"
|
||||
|
||||
When you created an account as a purchaser (eg: "purchase.dept@example.com"), you need to go inside the member zone:
|
||||
|
||||
|
||||
|
||||
Now, **click on the Purchaser tab**:
|
||||
|
||||
|
||||
|
||||
Your request will be sent to us, and we'll unlock you the purchaser feature.
|
||||
|
||||
As soon it's unlocked (you will be notified), return to the "Purchaser" tab, you should see a different interface.
|
||||
|
||||
|
||||
Now, you need to select which Edition to purchase, and **then assign the email of the technical contact** (e.g: "it@example.com").
|
||||
|
||||
## As "technical contact"
|
||||
|
||||
If you already registered your XOA, you can now update and get all XOA features unlocked from the purchase. That's all!
|
||||
19
docs/trial.md
Normal file
19
docs/trial.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# Trial
|
||||
|
||||
The trial is valid for 15 days. You'll have a **fully featured XOA** in Premium state!
|
||||
|
||||
> We don't have other edition for trial, but you can compare features on [our pricing page](https://xen-orchestra.com/#!/pricing).
|
||||
|
||||
## Activate the trial
|
||||
|
||||
In your current Free XOA, go register it in the "Settings/Update" view.
|
||||
|
||||
**To register, please use your email/password from your previous registration on xen-orchestra.com**:
|
||||
|
||||
|
||||
|
||||
There, you can click on "Start Trial":
|
||||
|
||||
|
||||
|
||||
Remember to "Check for updates" after requesting the trial, to be sure you'll download the **Premium Edition** for 15 days!
|
||||
19
docs/trial_activation.md
Normal file
19
docs/trial_activation.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# Trial activation
|
||||
|
||||
Trial will allow you to test all available features in XOA, for 15 days.
|
||||
|
||||
The procedure is really simple:
|
||||
|
||||
* register and download a Free Edition [on our website](https://xen-orchestra.com/#/member)
|
||||
* [deploy the virtual appliance](xoa.md)
|
||||
* request a Trial in the "Settings" and "Update" view
|
||||
|
||||
The trial panel in "Settings"/"Update":
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
As soon you clicked on "Start trial", you'll have a new update available, which will unlock all the features.
|
||||
|
||||
At the end of the trial, you'll be rollback to the Free version.
|
||||
86
docs/troubleshooting.md
Normal file
86
docs/troubleshooting.md
Normal file
@@ -0,0 +1,86 @@
|
||||
# Troubleshooting
|
||||
|
||||
This page recap the possible actions to realize if you have any problems with your XOA.
|
||||
|
||||
## XOA configuration
|
||||
|
||||
XOA is a virtual appliance running Debian and Xen Orchestra. If you have any problem, the first thing to do is to check the network configuration.
|
||||
|
||||
The easiest step is to check if you can ping our servers:
|
||||
|
||||
```
|
||||
$ ping xen-orchestra.com
|
||||
|
||||
PING xen-orchestra.com (*******) 56(84) bytes of data.
|
||||
64 bytes from xen-orchestra.com (*******): icmp_seq=1 ttl=53 time=11.0 ms
|
||||
64 bytes from xen-orchestra.com (*******): icmp_seq=2 ttl=53 time=11.0 ms
|
||||
```
|
||||
|
||||
If you have something completely different than that, or error messages, lost packets etc., it means you have probably a network problem. Check the following sections on network and DNS configuration.
|
||||
|
||||
### IP configuration
|
||||
|
||||
You can see your current network configuration with a `ifconfig eth0`. If you have a firewall, please check that you allow the XOA's IP.
|
||||
|
||||
You can modify the IP configuration in `/etc/network/interfaces`.
|
||||
|
||||
[Follow the official Debian documentation about that]( https://wiki.debian.org/NetworkConfiguration#Configuring_the_interface_manually).
|
||||
|
||||
|
||||
### DNS configuration
|
||||
|
||||
The DNS servers are configured in `/etc/resolv.conf`. If you have problems with DNS resolution, please modify the IPs of those servers to fit your current network configuration.
|
||||
|
||||
[Check the official Debian documentation to configure it](https://wiki.debian.org/NetworkConfiguration#The_resolv.conf_configuration_file).
|
||||
|
||||
### Disk space
|
||||
|
||||
You can run `df -h` to check if you don't have space disk issue. If you want to backup your VMs in XOA, [take a look here](https://xen-orchestra.com/docs/full_backups.html#add-a-disk-for-local-backups).
|
||||
|
||||
### Behind a transparent proxy
|
||||
|
||||
If your are behind a transparent proxy, you'll probably have issues with the updater (SSL/TLS issues).
|
||||
|
||||
First, run the following commands:
|
||||
|
||||
```
|
||||
$ echo NODE_TLS_REJECT_UNAUTHORIZED=0 >> /etc/xo-appliance/env
|
||||
$ npm config -g set strict-ssl=false
|
||||
```
|
||||
|
||||
Then, restart the updater with `systemctl restart xoa-updater`.
|
||||
|
||||
## XO configuration
|
||||
|
||||
The system logs are visible thanks to this command:
|
||||
|
||||
```
|
||||
$ tail -f /var/log/syslog
|
||||
```
|
||||
|
||||
You can read more about logs [in the dedicated chapter](logs.md).
|
||||
|
||||
### Reset XO configuration
|
||||
|
||||
If you have problems with your `xo-server` configuration, you can reset the database. **This operation will delete all your configured users and servers**:
|
||||
|
||||
1. `redis-cli`
|
||||
2. `FLUSHALL`
|
||||
3. `systemctl restart xo-server.service`
|
||||
|
||||
You can now log in with `admin@admin.net` and `admin` password.
|
||||
|
||||
### Redownload and rebuild all the packages
|
||||
|
||||
If a package disappear due to a build problem or a human error, you can redownload them using the updater:
|
||||
|
||||
1. `rm /var/lib/xoa-updater/update.json`
|
||||
2. `xoa-updater --upgrade`
|
||||
|
||||
> We'll have a `xoa-updater --force-reinstall` option soon, to do this automatically
|
||||
|
||||
## Empty page after login
|
||||
|
||||
This is happening when your anti-virus or firewall is blocking websocket protocol. This is what we use to communicate between `xo-server` and `xo-web` (see the [architecture page](architecture.md)).
|
||||
|
||||
The solution is to use **HTTPS**. In this way, websockets will be encapsulated in the secured protocol, avoiding interception from your firewalls or anti-virus system.
|
||||
106
docs/updater.md
Normal file
106
docs/updater.md
Normal file
@@ -0,0 +1,106 @@
|
||||
# Updater
|
||||
|
||||
The updater is the central piece to get your XOA on the latest bits of Xen Orchestra.
|
||||
|
||||
It allows also to transform your current version in any others (Trial, Starter, Enterprise or Premium) **without downloading a new XOA**.
|
||||
|
||||
> By design, the updater is only available in XOA. If you are using the XO from the sources, you'll have to use `git` commands and rebuild to keep up.
|
||||
|
||||
## Requierements
|
||||
|
||||
In order to work, the updater needs to access to xen-orchestra.com (port 443).
|
||||
|
||||
## Usage
|
||||
|
||||
The updater is configurable directly in the web interface, or via the CLI.
|
||||
|
||||
### From the web interface
|
||||
|
||||
By default for a new XOA, you'll have this icon in the top right:
|
||||
|
||||
|
||||
|
||||
It means your appliance is not registered. Click on this icon and follow the next step.
|
||||
|
||||
#### Register
|
||||
|
||||
Updates and trial will be available as soon as you registered your appliance. To register, use your https://xen-orchestra.com credentials you gave to download it previously (your email and your password):
|
||||
|
||||
|
||||
|
||||
#### Check for new versions
|
||||
|
||||
The updater will check for new versions periodically. Nevertheless, if you want to start a manual check, you can do it by clicking on the "Check for updates" icon.
|
||||
|
||||
#### Upgrade
|
||||
|
||||
If a new version is found, you'll have an upgrade button displayed:
|
||||
|
||||
|
||||
|
||||
**In case where the updater is updated itself, you should have to refresh manually the status panel!**
|
||||
|
||||
This could be done by clicking on the refresh white icon:
|
||||
|
||||
|
||||
|
||||
#### Proxy configuration
|
||||
|
||||
If you are behind a proxy, you can edit your proxy settings in this panel:
|
||||
|
||||
|
||||
|
||||
### From the CLI
|
||||
|
||||
If you interface is not accessible, or you just prefer to use CLIs commands, it's totally possible to do all the operations. You need to access your XOA by SSH (remember the default credentials: root/xoa. Change them ASAP).
|
||||
|
||||
#### Register
|
||||
|
||||
```
|
||||
# xoa-updater --register
|
||||
Successfully connected to xoa-updater-service
|
||||
|
||||
Please enter your xen-orchestra.com identifiers to register your XOA:
|
||||
? Email: myemail@example.net
|
||||
? Password: *****
|
||||
|
||||
ℹ Your Xen Orchestra Appliance has been succesfully registered
|
||||
```
|
||||
|
||||
#### Check for new versions
|
||||
|
||||
```
|
||||
# xoa-updater
|
||||
Successfully connected to xoa-updater-service
|
||||
Checking new versions...ok ✔
|
||||
New versions available:
|
||||
xo-server 4.8.1
|
||||
|
||||
ℹ xoa-updater may be run again to upgrade packages
|
||||
|
||||
```
|
||||
|
||||
#### Upgrade
|
||||
|
||||
```
|
||||
# xoa-updater --upgrade
|
||||
Successfully connected to xoa-updater-service
|
||||
Checking new versions...ok ✔
|
||||
New versions available:
|
||||
xo-server 4.8.1
|
||||
[...]
|
||||
Downloading packages...
|
||||
Installing new packages...
|
||||
|
||||
✔ Your XOA has been successfully updated.
|
||||
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Connect to your XOA in SSH then:
|
||||
|
||||
* 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)
|
||||
22
docs/visualizations.md
Normal file
22
docs/visualizations.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# Visualizations
|
||||
|
||||
> Visualization are available since 4.4
|
||||
|
||||
Visualizations help you to understand your own XenServer infrastructure, to correlate event and detect bottlenecks.
|
||||
|
||||
### Dashboard
|
||||
|
||||
The dashboard is a view gathering information on all your connected pools/hosts.
|
||||
|
||||
[](https://xen-orchestra.com/blog/xen-orchestra-4-4/#dashboard).
|
||||
|
||||
> You can also update all your hosts (install missing patches) from this place.
|
||||
|
||||
### Sunburst
|
||||
|
||||
A sunburst visualization helps a lot to detect proportions in a hierarchical environment. Two cases with XenServer:
|
||||
|
||||
* VM disk usage in storage repositories
|
||||
* VM RAM usage in hosts
|
||||
|
||||
[](https://xen-orchestra.com/blog/xen-orchestra-4-4/#sunburstvisualizationforvdiandramusage).
|
||||
47
docs/xo-cli.md
Normal file
47
docs/xo-cli.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# xo-cli
|
||||
|
||||
After [a request from someone on our Github repository](https://github.com/vatesfr/xo-server/issues/23), we decided to add the possibility to do some actions with CLI. Just few hours after the request, [we created XO-cli](https://github.com/vatesfr/xo-cli). It's a real example of the Xen Orchestra modularity, and how we can be flexible.
|
||||
|
||||
Thanks to introspection, XO-cli will detect all the available features exposed in XO-server API.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
xo-cli --register [<XO-Server URL>] [<username>] [<password>]
|
||||
Registers the XO instance to use.
|
||||
|
||||
xo-cli --list-commands [--json]
|
||||
Returns the list of available commands on the current XO instance.
|
||||
|
||||
xo-cli --list-objects [<property>=<value>]...
|
||||
Returns a list of XO objects.
|
||||
|
||||
xo-cli <command> [<name>=<value>]...
|
||||
Executes a command on the current XO instance.
|
||||
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
List all running VMs on your entire infrastructure, filtering on their name:
|
||||
|
||||
```
|
||||
$ xo-cli --list-objects type=VM power_state=Running | grep name_label
|
||||
|
||||
"name_label": "test tools",
|
||||
"name_label": "nfs",
|
||||
"name_label": "Salt Master",
|
||||
|
||||
```
|
||||
|
||||
You can list all the exposed XO-server API methods:
|
||||
|
||||
```
|
||||
$ xo-cli --list-commands
|
||||
|
||||
...
|
||||
vm.export vm=<string> [compress=<boolean>] [onlyMetadata=<boolean>]
|
||||
vm.import host=<string>
|
||||
...
|
||||
|
||||
```
|
||||
87
docs/xo-server.md
Normal file
87
docs/xo-server.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# 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.
|
||||
|
||||
### Daemon mode
|
||||
|
||||
As a daemon, XO-server is always up. In this way, it can listen and record every event occurring on your whole Xen infrastructure. Connections are always open and it can cache informations before serve it to another client (CLI, Web or anything else).
|
||||
|
||||
### Central point
|
||||
|
||||
Contrary to XenCenter, each Xen Orchestra's client is connected to one XO-Server, and not all the Xen servers. With a traditional architecture:
|
||||
|
||||
|
||||
|
||||
You can see how we avoid a lost of resources and bandwidth waste with a central point:
|
||||
|
||||
|
||||
|
||||
### Events
|
||||
|
||||
Legacy interfaces use the "pull" model, requesting data every "x" seconds:
|
||||
|
||||
|
||||
|
||||
It's **not scalable** and slow.
|
||||
|
||||
With XO < 3.4, we used events in this way:
|
||||
|
||||
|
||||
|
||||
But interface was still lagging behind the server. With XO 3.4, we got a full event system, allowing instant display of what's happening on your infrastructure:
|
||||
|
||||
|
||||
|
||||
### A proxy for your hosts
|
||||
|
||||
XO-Server will act as a proxy for all your clients. It opens a lot of possibilities!
|
||||
|
||||
#### Console proxy
|
||||
|
||||
A good example is the console: you can now expose your consoles even if your clients are outside the network!
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### VM streaming
|
||||
|
||||
Another possibility is to stream a VM from a host to another.
|
||||
|
||||
To do that previously, you needed to export your VM somewhere, then re-import it:
|
||||
|
||||
|
||||
|
||||
Thanks to our architecture, it's now far better:
|
||||
|
||||
|
||||
|
||||
|
||||
#### Patching on the fly
|
||||
|
||||
To install a patch manually, you need a lot of steps: find, download, extract and apply the patch, sequentially.
|
||||
|
||||
"xo-server" can do all these steps once:
|
||||
|
||||
1. downloading automatically the patch on Citrix servers
|
||||
2. unzip it and uploading it on the fly to your host
|
||||
3. apply it as soon it's done
|
||||
|
||||
|
||||
### Pluggable
|
||||
|
||||
It's really easy to plug other modules to XO-server, and extend or adapt the solution to your needs (see XO-web and XO-cli for real examples).
|
||||
|
||||
#### ACLs
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### API
|
||||
|
||||
An API is available to communicate directly with XO-Server. This part will be explained later.
|
||||
|
||||
### NodeJS under the hood
|
||||
|
||||
[NodeJS](https://en.wikipedia.org/wiki/Nodejs) is a software platform for scalable server-side and networking applications. It's famous for its efficiency, scalability and its asynchronous capabilities. Exactly what we need! Thus, XO-server is written in JavaScript.
|
||||
13
docs/xo-web.md
Normal file
13
docs/xo-web.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# xo-web
|
||||
|
||||
This is probably the first thing you'll see of Xen Orchestra. It's the Web interface, allowing to interact with your virtual infrastructure. As a module for XO-web, it facilitates the everyday Xen administrator work, but also provide a solution to delegate some part of your infrastructure to other people.
|
||||
|
||||
|
||||
|
||||
[Read the features section](https://vates.gitbooks.io/xen-orchestra/content/features.html) to discover what you can do in XO-web.
|
||||
|
||||
### JavaScript
|
||||
|
||||
We are also using JavaScript for XO-web: we stay consistent from the back-end to the front-end with one main language. [AngularJS](https://en.wikipedia.org/wiki/Angularjs) and [Twitter Bootstrap](https://en.wikipedia.org/wiki/Bootstrap_%28front-end_framework%29) are also powerful allies to our everyday development.
|
||||
|
||||
|
||||
69
docs/xoa.md
Normal file
69
docs/xoa.md
Normal file
@@ -0,0 +1,69 @@
|
||||
# XOA
|
||||
|
||||
The fastest way to install Xen Orchestra is to use our Appliance. You can [download it from here](https://xen-orchestra.com/) (fill the form and click on "Try Now"). Basically, it's 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
|
||||
|
||||
## Specifications
|
||||
|
||||
By default, this VM is configured with:
|
||||
|
||||
* 2 vCPUs
|
||||
* 2GB or RAM
|
||||
* 8GB of disk
|
||||
|
||||
For usage on huge infrastructure (more than 500+ VMs), feel free to raise the RAM.
|
||||
|
||||
## Deployment
|
||||
|
||||
Once you've got the XVA file, you can import it with `xe vm-import filename=xoa_version_number.xva` or via XenCenter.
|
||||
|
||||
After the VM is imported, you just need to start it with a `xe vm-start vm=XOA` or with XenCenter.
|
||||
|
||||
XOA is in **DHCP** by default, so if you need to configure the IP, you need to edit `/etc/network/interfaces` as explained in the [Debian documentation](https://wiki.debian.org/NetworkConfiguration#Configuring_the_interface_manually). You can access the VM console through XenCenter or using VNC through a SSH tunnel.
|
||||
|
||||
Xen Orchestra is now accessible in your browser on ` http://your-vm-ip` or in HTTPS on the same URL.
|
||||
|
||||
> If you are using a static IP configuration, take care of the `/etc/resolv.conf` file to fit your DNS settings.
|
||||
|
||||
### Downloading with wget
|
||||
|
||||
If you want to download your XOA with `wget`, you need to provide your cookie generated on https://xen-orchestra.com. See [this documentation](http://askubuntu.com/questions/161778/how-do-i-use-wget-curl-to-download-from-a-site-i-am-logged-into) for further details.
|
||||
|
||||
## Default admin account
|
||||
|
||||
Default user is **admin@admin.net** with **admin** as a password.
|
||||
|
||||
> **SECURITY NOTICE**: create a new admin account and remove this one.
|
||||
|
||||
In any case, if you lose your password, you can reset the database and get the default credentials back.
|
||||
|
||||
## SSH credentials
|
||||
|
||||
By default, system/SSH user and password are **root**/**xoa**. Be smart and change the root password as soon as possible!
|
||||
|
||||
## Timezone
|
||||
|
||||
You can verify if your time is correctly set with the `date` command. To set XOA to your current timezone, use `dpkg-reconfigure tzdata`.
|
||||
|
||||
## Restart the service
|
||||
|
||||
You can restart Xen Orchestra by going in XOA on SSH (or console) and type `systemctl restart xo-server.service`.
|
||||
|
||||
To check the status of `xo-server`, use `systemctl status xo-server.service`, it should display something like that:
|
||||
|
||||
```
|
||||
xo-server.service - XO Server
|
||||
Loaded: loaded (/etc/systemd/system/xo-server.service; enabled)
|
||||
Active: active (running) since Thu 2014-08-14 10:59:46 BST; 21min ago
|
||||
Main PID: 394 (node)
|
||||
CGroup: /system.slice/xo-server.service
|
||||
└─394 node /usr/local/bin/xo-server
|
||||
|
||||
Aug 14 10:59:46 xoa systemd[1]: Starting XO Server...
|
||||
Aug 14 10:59:46 xoa systemd[1]: Started XO Server.
|
||||
Aug 14 10:59:48 xoa xo-server[394]: WebServer listening on http://0.0.0.0:80
|
||||
```
|
||||
Reference in New Issue
Block a user