NuKVM/xen-orchestra
3
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Text improvements (#123)

Browse Source 
* fixed some typos and made some small improvement to make the text more readable.
This commit is contained in:
ETL
2018-03-20 16:46:32 -04:00
committed by Olivier Lambert
parent f5d6407ec9
commit 96f4896c84
17 changed files with 59 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/backups.md
View File

@@ -1,8 +1,8 @@
# Backups
This section is dedicated to any existing means to rollback or backup your VMs in Xen Orchestra.
This section is dedicated to all existing means to rollback or backup your VMs in Xen Orchestra.
There is different way to protect your VMs:
There are different ways to protect your VMs:
* [full backups](full_backups.md) [*Starter Edition*]
* [rolling snapshots](rolling_snapshots.md) [*Starter Edition*]
@@ -11,9 +11,9 @@ There is different way to protect your VMs:
* [continuous replication](continuous_replication.md) [*Premium Edition*]
* [file level restore](file_level_restore.md) [*Premium Edition*]
> Don't forget to take a look on the [backup troubleshooting](backup_troubleshooting.md) section. You can also take a look on the [backup reports](backup_reports.md) section for configuring notification.
> Don't forget to take a look at the [backup troubleshooting](backup_troubleshooting.md) section. You can also take a look at the [backup reports](backup_reports.md) section for configuring notifications.
There is also a way to select automatically VMs to backup: **[smart backup](smart_backup.md)** [*Enterprise Edition*]
There is also a way to automatically select the VMs to backup: **[smart backup](smart_backup.md)** [*Enterprise Edition*]
## Overview
@@ -47,7 +47,7 @@ The tooltip confirms this:
> Remotes are places where your *backup* and *delta backup* files will be stored.
To add a *remote*, go in **Settings/Remotes** menu.
To add a *remote*, go in the **Settings/Remotes** menu.
Supported stores:
@@ -60,7 +60,7 @@ Supported stores:
### NFS
On your NFS server, authorize XOA's IP and permissions for subfolders. That's all!
On your NFS server, authorize XOA's IP address and permissions for subfolders. That's all!
### SMB
@@ -93,29 +93,29 @@ Any Debian Linux mount point could be supported this way, until we add further o
## Restore backups
All your scheduled backup are acccessible in the "Restore" view in backup section of Xen Orchestra.
All your scheduled backups are acccessible in the "Restore" view in the backup section of Xen Orchestra.
1. Select your remote and click on the eye icon to see available VMs
1. Select your remote and click on the eye icon to see the VMs available
2. Choose the backup you want to restore
3. Select SR where you want to restore it
3. Select the SR where you want to restore it
> Note: You can restore your backup even on a brand new XenServer and on a brand new hardware.
## About backup compression
By default, *Backup* are compressed (using GZIP, done in XenServer side). There is no absolute rule but in general not compressed backup are faster.
By default, *Backups* are compressed (using GZIP, done on XenServer side). There is no absolute rule but in general not compressed backups are faster.
XenServer uses Gzip compression, which is:
* slow
* space efficient
* consume less bandwidth (if your NFS share is far)
* consumes 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.
## 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.
If you want to use XOA to store all your backups, you need to attach a large disk to it. This can be done 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`.
@@ -126,9 +126,9 @@ 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`.
If you already have backups done, you can move them to the new disk. The orignal backups folder is in `/var/lib/xoa-backups`.
To get the mount point persistent in XOA, edit the `/etc/fstab` file, and add:
To make the mount point persistent in XOA, edit the `/etc/fstab` file, and add:
```
/dev/xvdb /var/lib/xoa-backups ext4 defaults 0 0

14
docs/continuous_replication.md
View File

@@ -2,7 +2,7 @@
> WARNING: it works only on XenServer 6.5 or later
This feature allow continuous replication system for your XenServer VMs **without any storage vendor lock-in**. You can 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 is a continuous replication system for your XenServer VMs **without any storage vendor lock-in**. You can replicate a VM every *X* minutes/hours to any storage repository. It could be to a distant XenServer host or just another local storage.
This feature covers multiple objectives:
@@ -18,31 +18,31 @@ If you lose your main pool, you can start the copy on the other side, with very
![](https://xen-orchestra.com/blog/content/images/2016/01/replication.png)
> 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.
> Warning: it is normal that 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/new" section, select "Continuous Replication".
As you'll see, it is trivial to configure. Inside the "Backup/new" section, select "Continuous Replication".
Then:
1. Select VMs you want to protect
1. Select the VMs you want to protect
1. Schedule the replication interval
1. Select the destination storage (could be any storage connected to any XenServer host!)
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!
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 then do whatever you want with this clone!
## Manual initial seed
> This is **only** if you need to make the initial copy without making the whole transfer through your network. Otherwise, **you don't need that**.
**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):
**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 make 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. create a cont. rep job to a non-distant SR (even the SR where the VM currently is). 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

2
docs/delta_backups.md
View File

@@ -45,4 +45,4 @@ Just go inside your "Backup" view, and select Delta Backup. Then, it's like a no
During a delta backup job, you can avoid saving all disks of the VM. To do that, it's trivial: just edit the VM disk name and add `[NOBAK]` before the current name, eg: `data-disk` will become `[NOBAK] data-disk` (with a space or not after, doesn't matter).
For every following backup, this disk will be now ignored.
The disks marked with `[NOBACK]` will be now ignored in all following backups.

6
docs/disaster_recovery.md
View File

@@ -1,14 +1,14 @@
# Disaster recovery
Disaster Recovery (DR) regroup all the means to recover after losing hosts or storage repositories.
Disaster Recovery (DR) regroups 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.
We strongly encourage you to read some literature on this very topic. Basically, you should be able to recover from a major disaster within 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/).
To avoid a potentially very long import process (restoring all your backup VMs), we created a specific feature, made 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).**

2
docs/full_backups.md
View File

@@ -1,6 +1,6 @@
# Full backups
You can schedule full backups of your VMs, by exporting them in the local XOA file-system, or directly in a NFS or SMB share. "rentention" parameter allow to modify the retention (removing the oldest one).
You can schedule full backups of your VMs, by exporting them to the local XOA file-system, or directly to an NFS or SMB share. The "rentention" parameter allows you to modify the retention (removing the oldest one).
[![](./assets/backupexample.png)](https://xen-orchestra.com/blog/backup-your-xenserver-vms-with-xen-orchestra/)

2
docs/logs.md
View File

@@ -16,7 +16,7 @@ To filter only on what you need, you can use `journalctl`. Let's see some exampl
$ 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.
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 the problem is.
You can also filter for the updater program:

2
docs/patching.md
View File

@@ -1,6 +1,6 @@
# Patching
Patching a host manually could be time consuming (and boring). That's why we provide a high level feature downloading and applying all missing patches automatically.
Patching a host manually could be time consuming (and boring). That's why we provide the high level feature of downloading and applying all missing patches automatically.
## XOA smart patching system

4
docs/rolling_snapshots.md
View File

@@ -13,5 +13,5 @@ This feature is close to Backups, but it creates a snapshot when planned to do s
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!
* schedule a snapshot every week, but precisely Sunday at 11 PM, with 4 snapshots max. This will give you a month max of revert
* and so forth!

8
docs/smart_backup.md
View File

@@ -1,13 +1,13 @@
# Smart backup
There is two ways to select which VMs will be backup:
There are two ways to select which VMs will be backed up:
1. Multiple VM selector
1. Smart backup
Picking VMs manually can be a limitation if you environment is moving fast (ie having new VMs you need to backup often). Because you needed to edit the previous job and add it.
Picking VMs manually can be a limitation if you environment is moving fast (i.e. having new VMs you need to backup often), Because you needed to edit the previous job and add it.
But thanks to *smart backup*, you have now more flexibility: you won't select specific VMs, but VMs status/tag/placement **at the time backup job will be executed**. Let's see some examples!
But thanks to *smart backup*, you now have more flexibility: you won't select specific VMs, but VMs status/tag/placement **at the time backup job will be executed**. Let's see some examples!
## Backup all VMs on a pool
@@ -36,4 +36,4 @@ Now if you do this:
![](https://xen-orchestra.com/blog/content/images/2016/08/xo5smartbackup2.png)
It means any VMs on "Lab Pool" with the "prod" tag will be backup.
It means any VMs on "Lab Pool" with the "prod" tag will be backed up.

4
docs/troubleshooting.md
View File

@@ -1,12 +1,12 @@
# Troubleshooting
This page recap the possible actions to realize if you have any problems with your XOA.
This page recap the possible actions to perform if you have any problems with your XOA.
## XOA deploy error
> Auto deploy failed. - No SR specified and Pool default SR is null
It means you didn't have any default SR set on your pool you are importing XOA. To set a default SR, you must first find the SR UUID you want, with `xe sr-list`. When you got the UUID, you can set the default SR like this: `xe pool-param-set default-SR=<SR_UUID>`. When it's done, re-enter the deploy script command and it will work!
It means you don't have a default SR set on the pool you are importing XOA to. To set a default SR, you must first find the SR UUID you want, with `xe sr-list`. When you got the UUID, you can set the default SR with: `xe pool-param-set default-SR=<SR_UUID>`. When this is done, re-enter the deploy script command and it will work!
## XOA unreachable after boot

6
docs/updater.md
View File

@@ -6,9 +6,9 @@ It allows also to transform your current version in any others (Trial, Starter,
> 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
## Requirements
In order to work, the updater needs to access to xen-orchestra.com (port 443).
In order to work, the updater needs access to `xen-orchestra.com` (port 443).
## Usage
@@ -102,7 +102,7 @@ Installing new packages...
If your updater is down, you can restart it with `systemctl restart xoa-updater`.
If you can't fetch updates, make some checks from your XOA:
If you can't fetch updates, perform some checks from your XOA:
* you should be able to successfully `ping xen-orchestra.com`
* if not, check your `/etc/resolv.conf` file and modify it if necessary (give a correct DNS server)

10
docs/vm_creation.md
View File

@@ -36,7 +36,7 @@ Those values can be changed anytime after your VM is created.
#### Multiple VMs
You can create multiple VMs at one here, if you toggle the option. The `{name}` pattern is the "Name" field of the VM. By default, it will start with number 1 and so on. You can change this via the "First index" label.
You can create multiple VMs at once by toggling the *Multiple VMs* option. The `{name}` pattern is the "Name" field of the VM. By default, it will start with number 1 and so on. You can change this via the "First index" field.
Click on refresh icon to take the change into account:
@@ -48,11 +48,11 @@ This is where you are configuring VM performances: number of vCPUs, RAM, CPU wei
#### CPU weight and cap
CPU weight default number is `256`. It means that it will be scheduler by Xen like any other VMs on the host where it runs. If you raise it, eg with `512`, CPUs on this VM will be scheduled twice more than another one. If you diminish it, with `64` for example, it will be schedule 4 times less.
CPU weight default number is `256` which means it will be scheduled by Xen like any other VMs on the host where it runs. If you raise it, eg with `512`, CPUs on this VM will be scheduled twice more than another one. If you diminish it, with `64` for example, it will be schedule 4 times less.
What about cap? It's the maximum amount of CPUs a VM can consume. It's using a 100 base (1 vCPU: 100). Default is 0 and means no upper cap.
What about cap? It's the maximum amount of CPUs a VM can consume, using a 100 base (1 vCPU: 100). Default is 0 and means no upper cap.
> Should I mess with these settings? In general: nope. It's only when you are sure of what are you doing. More can be found here: https://wiki.xen.org/wiki/Credit_Scheduler
> Should I mess with these settings? In general: nope. Change this only if you are sure of what are you doing. More can be found here: https://wiki.xen.org/wiki/Credit_Scheduler
### Install settings
@@ -76,7 +76,7 @@ Please refer to the [XenServer CloudInit section](cloudinit.md) for more.
### Interfaces
This is the network part of the VM configuration: in general, MAC field is kept empty (autogenerated from XenServer). We also select the management network by default: you can change it reflecting your own network configuration.
This is the network part of the VM configuration: in general, MAC field is kept empty (autogenerated from XenServer). We also select the management network by default, but you can change it to reflect your own network configuration.
### Disks

4
docs/vm_import_export.md
View File

@@ -2,13 +2,13 @@
Xen Orchestra can import and export VM in XVA format (XenServer format) or import OVA files (OVF1 format).
> we are supporting OVA import from VirtualBox. Feel free to report issues with OVA from other virtualization platform.
> We are supporting OVA import from VirtualBox. Feel free to report issues with OVA from other virtualization platform.
## Import
### XVA files
To import a XVA file, just go in New/Import menu:
To import a XVA file, just go to the New/Import menu:
![](./assets/xoa5import.png)

2
docs/vm_management.md
View File

@@ -2,7 +2,7 @@
## Live Edition
Any object with a dotted underline can be editer on mouse click: VM title, description, CPU and memory.
Any object with a dotted underline can be edited on mouse click: VM title, description, CPU and memory.
![](./assets/xo5editvm.png)

14
docs/xo-server.md
View File

@@ -4,7 +4,7 @@ XO-Server is the core of Xen Orchestra. Its central role opens a lot of possibil
### 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).
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 serving it to another client (CLI, Web or anything else).
### Central point
@@ -12,7 +12,7 @@ Contrary to XenCenter, each Xen Orchestra's client is connected to one XO-Server
![](./assets/without-xo.jpg)
You can see how we avoid a lost of resources and bandwidth waste with a central point:
You can see how we avoid a lot of resources and bandwidth waste with a central point:
![](./assets/with-xo.jpg)
@@ -24,17 +24,17 @@ 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:
With XO < 3.4, we used events in the following way:
![](./assets/semievent.jpg)
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:
But the interface was still lagging behind the server. With XO 3.4, we now have a full event system, allowing instant display of what is happening on your infrastructure:
![](./assets/fullevent.jpg)
### A proxy for your hosts
XO-Server will act as a proxy for all your clients. It opens a lot of possibilities!
XO-Server will act as a proxy for all your clients. This opens a lot of possibilities!
#### Console proxy
@@ -64,8 +64,8 @@ To install a patch manually, you need a lot of steps: find, download, extract an
"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
2. unzipping it and uploading it on the fly to your host
3. applying it as soon it's done
### Pluggable

2
docs/xo-web.md
View File

@@ -1,6 +1,6 @@
# 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.
This is probably the first thing you'll see of Xen Orchestra. The Web interface allows 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.
![](https://xen-orchestra.com/blog/content/images/2015/05/tablet3-1.JPG)

8
docs/xoa.md
View File

@@ -36,7 +36,7 @@ SSH on your XenServer, and execute this:
bash -c "$(curl -s http://xoa.io/deploy)"
```
And follow instructions:
And follow the instructions:
* Your IP configuration will be requested: it's in **DHCP by default**, otherwise you can enter a fixed IP address (eg `192.168.0.10`)
* If DHCP is selected, the script will continue automatically. Otherwise, a netmask, gateway and DNS should be provided.
@@ -50,7 +50,7 @@ After the VM is imported, you just need to start it with a `xe vm-start vm="XOA
## Registration
**The first thing** you need to do with your XOA, is to register. [Read the documentation page dedicated to the updater/register inferface](updater.md).
**The first thing** you need to do with your XOA, is to register. [Read the documentation on the page dedicated to the updater/register inferface](updater.md).
### First console connection
@@ -59,7 +59,7 @@ If you connect in SSH or via console, the default credentials are:
* user: xoa
* password: xoa
During your first connection, the system will ask to:
During your first connection, the system will ask you to:
* enter again the current password (`xoa`)
* enter your new password
@@ -128,7 +128,7 @@ Administrator. It usually boils down to these three things:
### Network configuration
XOA is in **DHCP** by default, so if you need to configure the IP, please run the command `xoa network static`. It will ask you network details:
XOA is in **DHCP** by default, so if you need to configure the IP address, please run the command `xoa network static`. It will ask you network details:
```
$ xoa network static