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

grammar updates v11 (#133)

Browse Source 
* Clarification, update links, organize

* add nfs warning, fix debian version

* add ENOSPC troubleshooting

* add more enospc detail

* add note on editing username

* Documentation typo/grammar cleanup part 9

* grammar cleanup v10

* grammar editing v10

* grammar updates v11
This commit is contained in:
Jon Sands 2018-05-17 16:38:00 -04:00 committed by Olivier Lambert
parent 65cd32125b
commit 2e74f87ae0
6 changed files with 91 additions and 86 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
docs/backups.md
View File

@ -1,15 +1,15 @@
# Backups
This section is dedicated to all existing means to rollback or backup your VMs in Xen Orchestra.
This section is dedicated to all existing methods of rolling back or backing up your VMs in Xen Orchestra.
There are different ways to protect your VMs:
There are several ways to protect your VMs:
* [full backups](full_backups.md) [*Starter Edition*]
* [rolling snapshots](rolling_snapshots.md) [*Starter Edition*]
* [delta backups](delta_backups.md) (best of both previous ones) [*Enterprise Edition*]
* [disaster recovery](disaster_recovery.md) [*Enterprise Edition*]
* [continuous replication](continuous_replication.md) [*Premium Edition*]
* [file level restore](file_level_restore.md) [*Premium Edition*]
* [Full Backups](full_backups.md) [*Starter Edition*]
* [Rolling Snapshots](rolling_snapshots.md) [*Starter Edition*]
* [Delta Backups](delta_backups.md) (best of both previous ones) [*Enterprise Edition*]
* [Disaster Recovery](disaster_recovery.md) [*Enterprise Edition*]
* [Continuous Replication](continuous_replication.md) [*Premium Edition*]
* [File Level Restore](file_level_restore.md) [*Premium Edition*]
> Don't forget to take a look at the [backup troubleshooting](backup_troubleshooting.md) section. You can also take a look at the [backup reports](backup_reports.md) section for configuring notifications.
@ -17,25 +17,25 @@ There is also a way to automatically select the VMs to backup: **[smart backup](
## 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.
This is the welcome panel for the backup view. It recaps all existing scheduled jobs. This is also where the backup logs are displayed.
## Logs
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:
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.
> Logs are not "live" tasks. If you restart XOA during a backup, the log associated with the job will stay in orange (in progress), because it wasn't finished. It will stay forever not finished because the job was cut in the middle.
> Logs are not "live" tasks. If you restart XOA during a backup, the log associated with the job will stay in orange (in progress), because it wasn't finished. It will stay forever unfinished because the job was cut in the middle.
## Consistent backup (with quiesce snapshots)
All backup are relying on snapshots. But what about data consistency? By default, Xen Orchestra will try to make a **quiesce snapshot** everytime a snapshot is done (and fallback to normal snapshot if it's not possible).
All backup rely on snapshots. But what about data consistency? By default, Xen Orchestra will try to make a **quiesce snapshot** every time a snapshot is done (and fallback to normal snapshot if it's not possible).
All your Windows VMs can be protected (especially MS SQL or Exchange services) after you have installed Xen tools in your VMs. A quiesce snapshots means the operating system will be notified and the cache will be flushed on disks. This way, your backups will be always consistent.
All your Windows VMs can be protected (especially MS SQL or Exchange services) after you have installed Xen Tools in your VMs. A quiesce snapshots means the operating system will be notified and the cache will be flushed to disks. This way, your backups will always be consistent.
To see if you have quiesced snapshots for a VM, just go into its anapshot tab, the "info" icons means it is a quiesced snapshot:
To see if you have quiesced snapshots for a VM, just go into its snapshot tab, the "info" icon means it is a quiesced snapshot:
![](./assets/quiesced1.png)
@ -47,11 +47,11 @@ The tooltip confirms this:
> Remotes are places where your *backup* and *delta backup* files will be stored.
To add a *remote*, go in the **Settings/Remotes** menu.
To add a *remote*, go to the **Settings/Remotes** menu.
Supported stores:
Supported remote types:
* local (any folder in XOA filesystem)
* Local (any folder in XOA filesystem)
* NFS
* SMB (CIFS)
@ -66,9 +66,9 @@ On your NFS server, authorize XOA's IP address and permissions for subfolders. T
We support SMB storage on *Windows Server 2012 R2*.
> WARNING: In continuous delta backup, SMB is **NOT** recommended (or only for small VMs, eg < 50GB)
> WARNING: For continuous delta backup, SMB is **NOT** recommended (or only for small VMs, eg < 50GB)
Also, read twice the UI when you add a SMB store. If you have:
Also, read the UI twice when you add an SMB store. If you have:
* `192.168.1.99` as SMB host
* `Backups` as folder
@ -82,11 +82,11 @@ You'll have to fill it like this:
### Local
> **This is for advanced users**. Using local XOA filesystem without extra mount/disk will **use the default system disk of XOA**.
> **This is for advanced users**. Using the local XOA filesystem without extra mounts/disks will **use the default system disk of XOA**.
If you need to mount an unsupported store, you could always do it manually:
If you need to mount an unsupported store (FTP for example), you can always do it manually:
1. mount your store inside XOA manually, e.g in `/media/myStore`
1. mount your remote store inside the XOA filesystem 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.
@ -99,23 +99,23 @@ All your scheduled backups are acccessible in the "Restore" view in the backup s
2. Choose the backup you want to restore
3. Select the SR where you want to restore it
> Note: You can restore your backup even on a brand new XenServer and on a brand new hardware.
> Note: You can restore your backup even on a brand new XenServer and on brand new hardware.
## About backup compression
By default, *Backups* are compressed (using GZIP, done on XenServer side). There is no absolute rule but in general not compressed backups are faster.
By default, *Backups* are compressed (using GZIP, done on XenServer side). There is no absolute rule but in general uncompressed backups are faster (but sometimes much larger).
XenServer uses Gzip compression, which is:
* slow
* slow (single threaded)
* space efficient
* consumes less bandwidth (if your NFS share is far)
* consumes less bandwidth (helpful if your NFS share is far away)
If you have compression on your NFS share (or destination file-system like ZFS), you can disable compression in Xen Orchestra.
If you have compression on your NFS share (or destination filesystem like ZFS), you can disable compression in Xen Orchestra.
## Add a disk for local backups
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.
If you want to use XOA to locally 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`.
@ -134,4 +134,4 @@ 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
```
This way, without modifying your previous scheduled snapshot, they will be written in this local mountpoint!
This way, without modifying your previous scheduled snapshot, they will be written to this new local mountpoint!

20
docs/continuous_replication.md
View File

@ -1,8 +1,8 @@
# Continuous Replication
> WARNING: it works only on XenServer 6.5 or later
> WARNING: it works only with XenServer 6.5 or later
This feature is a continuous replication system for your XenServer VMs **without any storage vendor lock-in**. You can replicate a VM every *X* minutes/hours to any storage repository. It could be to a distant XenServer host or just another local storage.
This feature is a continuous replication system for your XenServer VMs **without any storage vendor lock-in**. You can replicate a VM every *X* minutes/hours to any storage repository. It could be to a distant XenServer host or just another local storage target.
This feature covers multiple objectives:
@ -18,7 +18,7 @@ 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: 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.
> Warning: it is normal that you can't boot the copied VM directly: we protect it. The normal workflow is to make a clone and then work on it.
## Configure it
@ -36,17 +36,17 @@ To protect the replication, we removed the possibility to boot your copied VM di
## 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**.
> This is **only** if you need to make the initial copy without making the whole transfer through your network. Otherwise, **you don't need this**.
**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 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
1. you can remove your local replicated copy
1. create a cont. rep job to a non-distant SR (even the SR where the VM currently is). Do NOT enable the job during creation.
1. manually start the first replication (only the first)
1. when finished, export the replicated VM (via XOA or any other means, doesn't matter how you get your XVA file)
1. import the replicated VM on your distant destination
1. you can now remove your local replicated copy
### Modifications
@ -70,4 +70,4 @@ xe vm-param-set blocked-operations:start uuid=<DestinationVM_UUID>
### 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.**
Manually run the job the first time to check if everything is OK. Then, enable the job. **Now, only the deltas are sent, your initial seed saved you a LOT of time if you have a slow network.**

16
docs/delta_backups.md
View File

@ -1,8 +1,8 @@
# Continuous Delta backups
> WARNING: it works only on XenServer 6.5 or later
> WARNING: Delta backups are only available 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.
You can export only the delta (difference) between your current VM disks and a previous snapshot (called here the *reference*). They are called *continuous* because you'll **never export a full backup** after the first one.
## Introduction
@ -14,7 +14,7 @@ It means huge files for each backups. Delta backups will only export the differe
![](https://xen-orchestra.com/blog/content/images/2015/12/delta_final.png)
You can imagine to make your first initial full backup during a weekend, and then only delta backups every night. It combines the flexibility of snapshots and the power of full backups, because:
You can imagine making your first initial full backup during a weekend, and then only delta backups every night. It combines the flexibility of snapshots and the power of full backups, because:
* delta are stored somewhere else than the current VM storage
* they are small
@ -25,11 +25,11 @@ So, if you want to rollback your VM to a previous state, the cost is only one sn
Even if you lost your whole SR or VM, XOA will restore your VM entirely and automatically, at any date of backup.
You can even imagine to use this to backup more often! Because delta will be smaller, and will be **always delta's**.
You can even imagine using this to backup more often! Because deltas will be smaller, and will **always be deltas**.
### 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:
They are called continuous because you'll **never export a full backup** after the first one. We'll merge the oldest delta into the full:
![](https://xen-orchestra.com/blog/content/images/2016/01/deltamergesmall-1.png)
@ -39,10 +39,10 @@ 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, it's like a normal backup.
Just go into your "Backup" view, and select Delta Backup. Then, it's the same as a normal backup.
## Exclude disks
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).
During a delta backup job, you can avoid saving all disks of the VM. To do that is 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, doesn't matter).
The disks marked with `[NOBACK]` will be now ignored in all following backups.
The disks marked with `[NOBAK]` will be now ignored in all following backups.

67
docs/docker_support.md
View File

@ -1,12 +1,12 @@
# Docker support
> This feature is available since 4.10
> This feature is available in XOA 4.10 and above
Basic container lifecycle is documented [in the Administration section](https://xen-orchestra.com/docs/administration.html#docker-management).
The 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.
This category is dedicated to creating a VM with Docker support.
## Prerequisite
## Prerequisites
* XenServer 6.5 or higher
* Plugin installation (see below)
@ -15,49 +15,54 @@ This category is dedicated on creating VM with Docker support.
## Docker plugin installation
This first step is needed until Docker is supported nativly in the XenServer API (XAPI).
This first step is needed until Docker is supported natively in the XenServer API (XAPI).
> The plugin should be installed in every hosts, even if they are on the same pool.
> The plugin should be installed on every host you will be using, even if they are on the same pool.
#### For XenServer 6.5
1. SSH on your XenServer
1. SSH to your XenServer
1. Download the plugin: `wget http://downloadns.citrix.com.edgesuite.net/10343/XenServer-6.5.0-SP1-xscontainer.iso`
1. Install it: `xe-install-supplemental-pack XenServer-6.5.0-SP1-xscontainer.iso`
#### For XenServer 7.0
1. SSH on your XenServer
1. SSH to your XenServer
1. Download the plugin: `wget http://downloadns.citrix.com.edgesuite.net/11621/XenServer-7.0.0-xscontainer.iso`
1. Install it: `xe-install-supplemental-pack XenServer-7.0.0-xscontainer.iso`
#### For XenServer 7.1
1. SSH on your XenServer
1. SSH to your XenServer
1. Download the plugin: `wget http://downloadns.citrix.com.edgesuite.net/11993/XenServer-7.1.0-xscontainer.iso`
1. Install it: `xe-install-supplemental-pack XenServer-7.1.0-xscontainer.iso`
#### For XenServer 7.2
That's it! You are ready for enjoying Docker support!
1. SSH to your XenServer
1. Download the plugin: `wget http://downloadns.citrix.com.edgesuite.net/12641/XenServer-7.2.0-xscontainer.iso`
1. Install it: `xe-install-supplemental-pack XenServer-7.2.0-xscontainer.iso`
That's it! You can now enjoy Docker support!
## Docker managed VMs
There is two ways to use the newest exposed Docker features:
There are two ways to use the newly exposed Docker features:
* install a CoreOS VM
* transform an existing VM in supported Docker VM
* Install a CoreOS VM
* Transform an existing VM into a 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).
[CoreOS](https://coreos.com/) is a Linux distribution with bundled software, like `etcd`, `rkt`, `fleet` etc. The ISO install CD also uses `CloudInit` (which is the interesting thing here).
![](https://xen-orchestra.com/blog/content/images/2015/11/coreos-logo.png)
#### Create the VM
First thing first, [create a new VM as usual](vm_creation.md).
First things first, [create a new VM as usual](vm_creation.md).
Then, select the "CoreOS" template in the list and name it as you want:
Then, select the "CoreOS" template in the list and name it as you wish:
![](./assets/xo5coreos.png)
@ -76,7 +81,7 @@ And replace it with your actual SSH public key:
`- ssh-rsa AAAA....kuGgQ me@mypc`
The rest of the configuration is identical to any other VM. Just click on "Create VM" and you are done. After few seconds, your VM is ready. Nothing else to do!
The rest of the configuration is identical to any other VM. Just click on "Create VM" and you are done. After a few seconds, your VM will be ready. Nothing else to do!
You can see it thanks to the docker logo in the main view:
@ -86,9 +91,9 @@ But also in the VM view, you'll have a container tab:
![](./assets/xo5dockerempty.png)
It's empty obviously, because you don't have any Docker container running. So now, let's boot the VM, and create some Docker containers!
It's empty obviously, because you don't have any Docker containers 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.
You should be able to access the VM with the user `core` and your SSH key (so no password to write!). And good news: because Xen Tools are installed automatically, you already have the IP address displayed in Xen Orchestra.
So in our example (use the `core` user):
@ -106,7 +111,7 @@ Update Strategy: No Reboots
core@core1 ~ $
```
You are now connected! Let's make some tests before installing it on the disks, with a container named "hello" (doing just a small infinite loop):
You are now connected! Let's run some tests before installing it on the disks, with a container named "hello" (just doing a small infinite loop):
```
core@core1 ~ $ docker run --name nginx -d hello /bin/sh -c "while true; do echo Hello World; sleep 1; done"
@ -119,7 +124,7 @@ Status: Downloaded newer image for busybox:latest
```
You can create any number of those!
You can create any number of these!
Guess what? Check in Xen Orchestra, in the VM view:
@ -133,7 +138,7 @@ Don't forget that you can sort the table and even search inside 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:
Now that 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
@ -156,22 +161,22 @@ During the VM creation, the XSContainer plugin will create an extra disk: "Autom
#### 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.
`CloudInit` is 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
* SSH key management for newly created VM/instances
* Root disk filesystem growing
* User/group management
* Arbitrary commands execution (system update, custom scripts etc.)
* Arbitrary command execution (system update, custom scripts etc.)
In our case, it's used by the XSContainer plugin to allow host communication to the Docker daemon running in the VM, thus exposing Docker commands outside it.
In our case, it's used by the XSContainer plugin to allow host communication to the Docker daemon running in the VM, thus exposing Docker commands outside of the VM.
### Existing VMs
You can also use the XSContainer plugin to "transform" an existing VM into a "Docker" managed one.
You can also use the XSContainer plugin to "transform" an existing VM into a "Docker" managed VM.
You need to have this installed inside the VM:
You need to have the following installed inside the VM:
* Docker
* openssh-server
@ -179,12 +184,12 @@ You need to have this installed inside the VM:
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.
To run 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:
Now you need to access 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.
> Because "prepare-vm" is not exposed outside of the Dom0 (yet?), we can't use Xen Orchestra to give you a one-click solution as of now.

4
docs/full_backups.md
View File

@ -1,6 +1,6 @@
# Full backups
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).
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 how many backups are retained (by removing the oldest one).
[![](./assets/backupexample.png)](https://xen-orchestra.com/blog/backup-your-xenserver-vms-with-xen-orchestra/)
@ -8,4 +8,4 @@ Full backups are space consuming! But they allow a very simple restoration witho
## How it works
Full backups are using XenServer VM export capabilities. We are storing and rotating XVA files. It works very well. If you want to use less disk space, take a look at the [delta backups](delta_backups.md) feature.
Full backups use XenServer's VM export capabilities. We store and rotate XVA files. It works very well. If you want to use less disk space, take a look at the [delta backups](delta_backups.md) feature.

12
docs/rolling_snapshots.md
View File

@ -1,10 +1,10 @@
# Rolling snapshots
> Rolling snapshots are released since 4.2
> Rolling snapshots are available since XOA 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.
This feature is similar to Backups, but it creates a snapshot when planned to do so. It also handles the retention (removing the oldest snapshot). This feature is very convenient to rollback to a previous state.
**Warning**: snapshots are not backups. All snapshots are on the same Storage than their original disk. If you lose the original VDI (or the SR), you'll **lose all your snapshots**.
**Warning**: snapshots are not backups. All snapshots are on the same storage as their original disk. If you lose the original VDI (or the SR), you'll **lose all your snapshots**.
[Read more about it](https://xen-orchestra.com/blog/xen-orchestra-4-2/#schedulerollingsnapshots).
@ -12,6 +12,6 @@ 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 give you a month max of revert
* and so forth!
* Schedule a nightly snapshot for a group of VMs, let's say at 4:30 in the morning. With a max snapshot of 7, you'll have a week of revert possibility
* Schedule a snapshot every week, but precisely Sunday at 11 PM, with 4 snapshots max. This will give you a month max of revert
* And so forth!