WIP: Integrate Vale style checker

.github/workflows/vale.yml

@@ -0,0 +1,14 @@
+---
+name: Linting
+on: [push]
+
+jobs:
+  style:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@master
+      - name: Style
+        uses: xcp-ng/vale-styles@v0.1
+        with:
+          files: docs/*

.vale.ini

@@ -0,0 +1,7 @@
+StylesPath = .github/styles/
+MinAlertLevel = suggestion
+
+# Only Markdown files;
+[*.{md}]
+# List of styles to load.
+BasedOnStyles = gitlab, vates

docs/README.md

@@ -32,5 +32,5 @@ About the project itself, please see the [project page](project.md).
 <iframe width="560" height="315" src="https://www.youtube.com/embed/5IinFgGAsRs" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
 :::tip
-No flamewar! There are no miracle solutions, but only solutions adapted to your usage. We truly respect all other virtualization platforms!
+No flame war! There are no miracle solutions, but only solutions adapted to your usage. We truly respect all other virtualization platforms!
 :::

docs/answerfile.md

@@ -89,7 +89,7 @@ Where type is one of:
 
 `source` defines the location of the installation repository or a Supplemental Pack. There may be multiple 'source' elements.
 
-`driver-source` defines the source of a Supplemental Pack containing device drivers to be loaded by  the installer and included after installation of the main repository. It can be 
+`driver-source` defines the source of a Supplemental Pack containing device drivers to be loaded by the installer and included after installation of the main repository.
 
 Repository formats:
 
@@ -328,4 +328,4 @@ Your answer file can also be used to upgrade your machines. Here is an example:
 </installation>
 ```
 
-As you can see, `mode` is set on `upgrade`. Be sure to target the right disk to search for previous existing installations (here `sda`). Do NOT specify `primary-disk` and `guest-disk`!
+As you can see, `mode` is set on `upgrade`. Be sure to target the right disk to search for previous existing installations (here `sda`). Do NOT specify `primary-disk` and `guest-disk`!

docs/architecture.md

@@ -234,7 +234,7 @@ References and interesting links:
 
 ### Xen Grant table
 
-The grant table is a mechanism to share memory between domains: it's essentially used in this part to share data between a PV driver of a `DomU` and the `Dom0`. Each domain has its own grant table and it can give an access to its memory pages to  another domain using Write/Read permissions. Each entry of the table are identified by a `grant reference`, it's a simple integer which indexes into the grant table.
+The grant table is a mechanism to share memory between domains: it's essentially used in this part to share data between a PV driver of a `DomU` and the `Dom0`. Each domain has its own grant table and it can give an access to its memory pages to another domain using Write/Read permissions. Each entry of the table are identified by a `grant reference`, it's a simple integer which indexes into the grant table.
 
 Normally the grant table is used in the kernel space, but it exists a `/dev/xen/gntdev` device used to map granted pages in user space. It's useful to implement Xen backends in userspace for qemu and tapdisk: we can write and read in the blkif ring with this helper.
 

docs/cloud.md

@@ -23,23 +23,23 @@ The self-service feature allows users to create new VMs within a **limited amoun
 
 ## CloudStack
 
-At the outset this writeup is an outcome of this XCP-ng forum [discussion](https://xcp-ng.org/forum/topic/1109/xcp-ng-issues-with-cloudstack-4-11-2-with-iscsi-sr/10). Basically, setting up XCP-Ng using XCP-ng Center is very straightforward but to overlay Cloudstack and get them all to work in unison is the tricky part. To provide more background , consider a 2 node XCP-ng 7.6.0 pool setup with iSCSI target running on a different host with all necessary traffic segregation principles applied (guest, storage and management).
+At the outset this writeup is an outcome of this XCP-ng forum [discussion](https://xcp-ng.org/forum/topic/1109/xcp-ng-issues-with-cloudstack-4-11-2-with-iscsi-sr/10). Basically, setting up XCP-Ng using XCP-ng Center is very straightforward but to overlay CloudStack and get them all to work in unison is the tricky part. To provide more background , consider a 2 node XCP-ng 7.6.0 pool setup with iSCSI target running on a different host with all necessary traffic segregation principles applied (guest, storage and management).
 
 ### Installation Steps (with tips and tricks)
 
-1. Follow along the Cloudstack Management Server installation [steps](http://docs.cloudstack.apache.org/en/4.11.2.0/installguide/hypervisor/xenserver.html#system-requirements-for-xenserver-hosts).
+1. Follow along the CloudStack Management Server installation [steps](http://docs.cloudstack.apache.org/en/4.11.2.0/installguide/hypervisor/xenserver.html#system-requirements-for-xenserver-hosts).
 
-> Tip #1: if you need iSCSI , when you login to Cloudstack Management UI avoid the "Basic setup" and choose the option "I have used CloudStack before" (the button that is less obvious) since with basic for some reasons forces you into NFS.
-But don't proceed  with configuring your Cloudstack Management Server just yet.
+> Tip #1: if you need iSCSI , when you login to CloudStack Management UI avoid the "Basic setup" and choose the option "I have used CloudStack before" (the button that is less obvious) since with basic for some reasons forces you into NFS.
+But don't proceed with configuring your CloudStack Management Server just yet.
 
-2. If you have not setup your iSCSI storage on the XCP-ng pool . Please proceed to do it and ensure that they list in XCP-ng Center or Xen Orchestra and ensure everything looks good. So as listed in the Cloudstack Installation guide, we will be using the "Presetup" option to setup Primary ISCSI storage on Cloudstack.
+2. If you have not setup your iSCSI storage on the XCP-ng pool . Please proceed to do it and ensure that they list in XCP-ng Center or Xen Orchestra and ensure everything looks good. So as listed in the CloudStack Installation guide, we will be using the "Presetup" option to setup Primary ISCSI storage on CloudStack.
 
 3. Now SSH into the Cloudstack Management host, go to the folder (`/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/`) . This folder contains several useful scripts which comes in handy pick the one that says `setup_heartbeat_sr.sh` and copy that over to the Xen Pool master host and ensure you have executable rights on script file .
 
 4. Before you run the script , run the `lvscan` command which scan for presence of LVM on your pool and produce some result if you had made any undesirable edits to `/etc/lvm/lvm.conf` file this step will most likely fail. If it does , make sure you restore the `lvm.conf` to its original state.
 
-5. Now execute the `setup_heartbeat_sr.sh` with the UUID of the iSCSI SR that you had setup in Step #2. Internally does lvcreate with a bunch of params . Which basically creates a hb-volume (heartbeat volume) for the SR.
+5. Now execute the `setup_heartbeat_sr.sh` with the UUID of the iSCSI SR that you had setup in Step #2. Internally does lvcreate with a bunch of parameters. Which basically creates a hb-volume (heartbeat volume) for the SR.
 
 6. After this succeeds proceed to setting up your Cloudstack Management host and your infrastructure and that point of adding your primary storage use the "Presetup" option. You'll see that it works without issues.
 
-> Note: At the time of writing this page: Cloudstack 4.12 and XCP-Ng 7.6.0  where the latest versions of the respective software.
+> Note: At the time of writing this page: Cloudstack 4.12 and XCP-Ng 7.6.0 where the latest versions of the respective software.

docs/compute.md

@@ -37,7 +37,7 @@ and an error in `/var/log/xen/hypervisor.log`
 [2020-08-22 10:09:03] (XEN) [  297.542136] d[IO]: assign (0000:08:00.0) failed (-1)
 ```
 
-This indicates that your device is using [RMRR](https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf).  Intel [IOMMU does not allow DMA to these devices](https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt) and therefore PCI passthrough is not supported.
+This indicates that your device is using [RMRR](https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf). Intel [IOMMU does not allow DMA to these devices](https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt) and therefore PCI passthrough is not supported.
 
 ### 1. Find your devices ID ([B/D/F](https://en.wikipedia.org/wiki/PCI_configuration_space#BDF)) on the PCI bus using one of the following methods:
 
@@ -182,7 +182,7 @@ Due to a proprietary piece of code in XenServer, XCP-ng doesn't have (yet) suppo
 
 ### MxGPU (AMD vGPU)
 
-AMD GPU are trivial using industry standard.  
+AMD GPU are trivial using industry standard.
 Version 2.0 of the mxgpu iso should work on any 8.X version of XCP-ng
 
 1. Enable SR-IOV in the server's BIOS
@@ -196,7 +196,7 @@ Version 2.0 of the mxgpu iso should work on any 8.X version of XCP-ng
 `xe-install-supplemental-pack mxgpu-2.0.0.amd.iso`
 
 6. Reboot the XCP-ng
-7. Assign an MxGPU to the VM from the VM properties page.  Go to the GPU section.  From the Drop down choose how big of a slice of the GPU you want on the VM and click OK
+7. Assign an MxGPU to the VM from the VM properties page. Go to the GPU section. From the Drop down choose how big of a slice of the GPU you want on the VM and click OK
 
 Start the VM and log into the guest OS and load the appropriate guest driver from AMD's Drivers & Support page.