Editorial changes

spelling, grammer, typos and other editorial changes

pve-storage-dir.adoc

@@ -14,16 +14,16 @@ can use any file system supported by Linux.
 
 This backend assumes that the underlying directory is POSIX
 compatible, but nothing else. This implies that you cannot create
-snapshots at the storage level. But there exists a woraround for VM
+snapshots at the storage level. But there exists a workaround for VM
 images using the `qcow2` file format, because that format supports
 snapshots internally.
 
-TIP: Some storage types does not support `O_DIRECT`, so you can't use
+TIP: Some storage types do not support `O_DIRECT`, so you can't use
 cache mode `none` with such storages. Simply use cache mode
 `writeback` instead.
 
 We use a predefined directory layout to store different content types
-into different sub-directories. This layout is use by all file level
+into different sub-directories. This layout is used by all file level
 storage backends.
 
 .Directory layout
@@ -69,8 +69,8 @@ This specifies the owner VM.
 
 `<NAME>`::
 
-This scan be an arbitrary name (`ascii`) without white spaces. The
+This can be an arbitrary name (`ascii`) without white spaces. The
-backend uses `disk[N]` as default, where `[N]` is replaced by an
+backend uses `disk-[N]` as default, where `[N]` is replaced by an
 integer to make the name unique.
 
 `<FORMAT>`::
@@ -78,19 +78,19 @@ integer to make the name unique.
 Species the image format (`raw|qcow2|vmdk`).
 
 When you create a VM template, all VM images are renamed to indicate
-that they are now read-only, and can be uses as base image for clones:
+that they are now read-only, and can be uses as a base image for clones:
 
  base-<VMID>-<NAME>.<FORMAT>
 
 NOTE: Such base images are used to generate cloned images. So it is
-important that those files are read-only, and never gets modified. The
+important that those files are read-only, and never get modified. The
-backend changes access mode to `0444`, and sets the immutable flag
+backend changes the access mode to `0444`, and sets the immutable flag
 (`chattr +i`) if the storage supports that.
 
 Storage Features
 ~~~~~~~~~~~~~~~~
 
-As mentioned above, most file systems does not support snapshots out
+As mentioned above, most file systems do not support snapshots out
 of the box. To workaround that problem, this backend is able to use
 `qcow2` internal snapshot capabilities.
 

pveam.adoc

@@ -24,7 +24,7 @@ Container Images
 include::attributes.txt[]
 endif::manvolnum[]
 
-Command line tool to manage comtainer images. See 'man pct' for usage
+Command line tool to manage container images. See 'man pct' for usage
 examples.
 
 ifdef::manvolnum[]

pvesm.adoc

@@ -110,12 +110,12 @@ Each storage pool has a `<type>`, and is uniquely identified by its `<STORAGE_ID
 ----
 
 NOTE: There is one special local storage pool named `local`. It refers to
-directory '/var/lib/vz' and is automatically generated at installation
+the directory '/var/lib/vz' and is automatically generated at installation
 time.
 
 The `<type>: <STORAGE_ID>` line starts the pool definition, which is then
-followed by a list of properties. Most properties have values, but some of them comes
+followed by a list of properties. Most properties have values, but some of
-with reasonable default. In that case you can omit the value.
+them come with reasonable default. In that case you can omit the value.
 
 .Default storage configuration ('/etc/pve/storage.cfg')
 ====
@@ -128,7 +128,7 @@ with reasonable default. In that case you can omit the value.
 Common Storage Properties
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A few storage properties are common among differenty storage types. 
+A few storage properties are common among different storage types.
 
 nodes::
 
@@ -140,7 +140,7 @@ content::
 
 A storage can support several content types, for example virtual disk
 images, cdrom iso images, container templates or container root
-directories. Not all storage types supports all content types. One can set
+directories. Not all storage types support all content types. One can set
 this property to select for what this storage is used for.
 
 images:::
@@ -149,7 +149,7 @@ KVM-Qemu VM images.
 
 rootdir:::
 
-Allow to store Container data.
+Allow to store container data.
 
 vztmpl:::
 
@@ -181,16 +181,16 @@ Default image format (`raw|qcow2|vmdk`)
 
 
 WARNING: It is not advisable to use the same storage pool on different
-{pve} clusters. Some storage operation needs exclusive access to the
+{pve} clusters. Some storage operation need exclusive access to the
 storage, so proper locking is required. While this is implemented
-within an cluster, it does not work between different clusters.
+within a cluster, it does not work between different clusters.
 
 
 Volumes
 -------
 
 We use a special notation to address storage data. When you allocate
-data from a storage pool, it returns such volume identifier. A volume
+data from a storage pool, it returns such a volume identifier. A volume
 is identified by the `<STORAGE_ID>`, followed by a storage type
 dependent volume name, separated by colon. A valid `<VOLUME_ID>` looks
 like:
@@ -215,15 +215,15 @@ volume is owned by a VM or Container. For example volume
 `local:230/example-image.raw` is owned by VM 230. Most storage
 backends encodes this ownership information into the volume name.
 
-When you remove a VM or Container, the system also remove all
+When you remove a VM or Container, the system also removes all
 associated volumes which are owned by that VM or Container.
 
 
 Using the Command Line Interface
 --------------------------------
 
-I think it is required to understand the concept behind storage pools
+It is recommended to familiarize yourself with the concept behind storage
-and volume identifier, but in real life, you are not forced to do any
+pools and volume identifiers, but in real life, you are not forced to do any
 of those low level operations on the command line. Normally,
 allocation and removal of volumes is done by the VM and Container
 management tools.

qm.adoc

@@ -40,18 +40,18 @@ All configuration files consists of lines in the form
 
 See 'man vm.conf' for a complete list of options.
 
-Configuration files are stored inside the Proxmox configuration file
+Configuration files are stored inside the Proxmox cluster file
 system, and can be access at '/etc/pve/qemu-server/<VMID>.conf'.
 
-The default for option `keyboard` is read from
+The default for the `keyboard` option is read from
 '/etc/pve/datacenter.conf'.
 
 Locks
 -----
 
-Online migration and backups ('vzdump') set a lock to prevent
+Online migrations and backups ('vzdump') set a lock to prevent incompatible
-unintentional action on such VMs. Sometimes you need remove such lock
+concurrent actions on the affected VMs. Sometimes you need to remove such a
-manually (power failure).
+lock manually (e.g., after a power failure).
 
  qm unlock <vmid>
 

vzdump.adoc

@@ -25,7 +25,7 @@ Backup and Restore
 include::attributes.txt[]
 endif::manvolnum[]
 
-'vzdump' is an utility to make consistent snapshots of running virtual
+'vzdump' is a utility to make consistent snapshots of running virtual
 machines (VMs). It basically creates an archive of the VM private
 area, which also includes the VM configuration files. 'vzdump'
 currently supports LXC containers and QemuServer VMs.
@@ -38,10 +38,10 @@ Stop the VM during backup. This results in a very long downtime.
 
 `suspend` mode::
 
-For containers, this mode uses rsync to copy the VM to a temporary
+For containers, this mode uses rsync to copy the VM data to a temporary
 location (see option `--tmpdir`). Then the VM is suspended and a second
-rsync copies changed files. After that, the VM is started (resume)
+rsync copies changed files. After that, the VM is started (resumed)
-again. This results in a minimal downtime, but needs additional space
+again. This results in minimal downtime, but needs additional space
 to hold the VM copy.
 
 For QemuServer, this mode will suspend the VM, start
@@ -54,7 +54,7 @@ underlying storage. A snapshot will be made of the container volume,
 and the snapshot content will be archived in a tar file.
 
 For QemuServer, this mode will do a live backup similar to the
-`snaphost` mode, but without suspending/resuming the VM.
+`suspend` mode, but without suspending/resuming the VM.
 
 A technical overview of the Proxmox VE live backup for QemuServer can
 be found online
@@ -63,14 +63,14 @@ https://git.proxmox.com/?p=pve-qemu-kvm.git;a=blob;f=backup.txt[here],
 Backup File Names
 -----------------
 
-Newer version of vzdump encodes the virtual machine type and the
+Newer versions of vzdump encode the virtual machine type and the
 backup time into the filename, for example
 
  vzdump-lxc-105-2009_10_09-11_04_43.tar
 
-That way it is possible to store several backup into the same
+That way it is possible to store several backup in the same
 directory. The parameter `maxfiles` can be used to specify the
-maximal number of backups to keep.
+maximum number of backups to keep.
 
 Restore
 -------
@@ -78,7 +78,7 @@ Restore
 The resulting archive files can be restored with the following programs.
 
 
-`pct restore`:: Containers restore utility
+`pct restore`:: Container restore utility
 
 `qmrestore`:: QemuServer restore utility
 
@@ -139,7 +139,7 @@ configuration files to the default dump directory (usually
 
  # vzdump 777
 
-Use rsync and suspend/resume to create an snapshot (minimal downtime).
+Use rsync and suspend/resume to create a snapshot (minimal downtime).
 
  # vzdump 777 --mode suspend