fix some typos

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

diff --git a/output-format.adoc b/output-format.adoc
index 3dcfa3811076442484efcf3a75a2c7948722b6b0..b3eb3c4d4a0b69739c366c6aeecaefd827213d0d 100644 (file)
--- a/output-format.adoc
+++ b/output-format.adoc
@@ -13,7 +13,7 @@ to draw nice borders around tables. It additionally transforms some
 values into human-readable text, for example:
 
 - Unix epoch is displayed as ISO 8601 date string.
-- Durations are displayed as week/day/hour/miniute/secound count, i.e `1d 5h`.
+- Durations are displayed as week/day/hour/minute/second count, i.e `1d 5h`.
 - Byte sizes value include units (`B`, `KiB`, `MiB`, `GiB`, `TiB`, `PiB`).
 - Fractions are display as percentage, i.e. 1.0 is displayed as 100%.
 

diff --git a/pve-firewall-macros.adoc b/pve-firewall-macros.adoc
index e971a984dff0428a12970fb2b23f5b4cb4fe835b..1dce91398cfa8d94340ba0170dc11c9f3daeebb1 100644 (file)
--- a/pve-firewall-macros.adoc
+++ b/pve-firewall-macros.adoc
@@ -56,7 +56,7 @@
 |===========================================================
 
 [horizontal]
-'Ceph':: Ceph Storage Cluster traffic (Ceph Monitors, OSD & MDS Deamons)
+'Ceph':: Ceph Storage Cluster traffic (Ceph Monitors, OSD & MDS Daemons)
 
 [width="100%",options="header"]
 |===========================================================

diff --git a/pve-firewall.adoc b/pve-firewall.adoc
index 2bcdf6e0c93e95d7c421598e2e3b1188d215c5e7..0bf108f68aa6eecf3c9b7f32ce9f62628edd9506 100644 (file)
--- a/pve-firewall.adoc
+++ b/pve-firewall.adoc
@@ -465,7 +465,7 @@ VM/CT incoming/outgoing DROP/REJECT
 This drops or rejects all the traffic to the VMs, with some exceptions for
 DHCP, NDP, Router Advertisement, MAC and IP filtering depending on the set
 configuration.  The same rules for dropping/rejecting packets are inherited
-from the datacenter, while the exceptions for accepted incomming/outgoing
+from the datacenter, while the exceptions for accepted incoming/outgoing
 traffic of the host do not apply.
 
 Again, you can use xref:pve_firewall_iptables_inspect[iptables-save (see above)]

diff --git a/pve-installation.adoc b/pve-installation.adoc
index c116908209e432b1716c7b6fa2cacd43bfb7f8b6..cb95610858a5dfa373d28267a68982a402b2d882 100644 (file)
--- a/pve-installation.adoc
+++ b/pve-installation.adoc
@@ -224,7 +224,7 @@ Advanced ZFS Configuration Options
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The installer creates the ZFS pool `rpool`. No swap space is created but you can
 reserve some unpartitioned space on the install disks for swap. You can also
-create a swap zvol after the installation, altough this can lead to problems.
+create a swap zvol after the installation, although this can lead to problems.
 (see <<zfs_swap,ZFS swap notes>>).
 
 `ashift`::
@@ -250,7 +250,7 @@ semantics, and why this does not replace redundancy on disk-level.
 `hdsize`::
 
 Defines the total hard disk size to be used. This is useful to save free space
-on the hard disk(s) for further partitioning (for exmaple to create a
+on the hard disk(s) for further partitioning (for example to create a
 swap-partition). `hdsize` is only honored for bootable disks, that is only the
 first disk or mirror for RAID0, RAID1 or RAID10, and all disks in RAID-Z[123].
 

diff --git a/pveceph.adoc b/pveceph.adoc
index 8b86d62f596767f35ca8b8164cfcda5aa4bc8f11..b3bbadfda7f5bd817195f029d8fbfc5aad87e0bd 100644 (file)
--- a/pveceph.adoc
+++ b/pveceph.adoc
@@ -101,7 +101,7 @@ services on the same network and may even break the {pve} cluster stack.
 
 Further, estimate your bandwidth needs. While one HDD might not saturate a 1 Gb
 link, multiple HDD OSDs per node can, and modern NVMe SSDs will even saturate
-10 Gbps of bandwidth quickly. Deploying a network capable of even more bandwith
+10 Gbps of bandwidth quickly. Deploying a network capable of even more bandwidth
 will ensure that it isn't your bottleneck and won't be anytime soon, 25, 40 or
 even 100 GBps are possible.
 
@@ -378,7 +378,7 @@ pveceph osd create /dev/sd[X] -db_dev /dev/sd[Y] -wal_dev /dev/sd[Z]
 ----
 
 You can directly choose the size for those with the '-db_size' and '-wal_size'
-paremeters respectively. If they are not given the following values (in order)
+parameters respectively. If they are not given the following values (in order)
 will be used:
 
 * bluestore_block_{db,wal}_size from ceph configuration...

diff --git a/pvecm.adoc b/pvecm.adoc
index 72e7c024c954ecc93ddf9b39f4f73aba724ffbcc..4bf2f592a9572614f76cb930c8d03cebe3b3da1d 100644 (file)
--- a/pvecm.adoc
+++ b/pvecm.adoc
@@ -730,7 +730,7 @@ resolve to can be changed without touching corosync or the node it runs on -
 which may lead to a situation where an address is changed without thinking
 about implications for corosync.
 
-A seperate, static hostname specifically for corosync is recommended, if
+A separate, static hostname specifically for corosync is recommended, if
 hostnames are preferred. Also, make sure that every node in the cluster can
 resolve all hostnames correctly.
 
@@ -739,7 +739,7 @@ entry. Only the resolved IP is then saved to the configuration.
 
 Nodes that joined the cluster on earlier versions likely still use their
 unresolved hostname in `corosync.conf`. It might be a good idea to replace
-them with IPs or a seperate hostname, as mentioned above.
+them with IPs or a separate hostname, as mentioned above.
 
 
 [[pvecm_redundancy]]
@@ -758,7 +758,7 @@ physical network connection.
 
 Links are used according to a priority setting. You can configure this priority
 by setting 'knet_link_priority' in the corresponding interface section in
-`corosync.conf`, or, preferrably, using the 'priority' parameter when creating
+`corosync.conf`, or, preferably, using the 'priority' parameter when creating
 your cluster with `pvecm`:
 
 ----
@@ -888,7 +888,7 @@ example 2+1 nodes).
 QDevice Technical Overview
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The Corosync Quroum Device (QDevice) is a daemon which runs on each cluster
+The Corosync Quorum Device (QDevice) is a daemon which runs on each cluster
 node. It provides a configured number of votes to the clusters quorum
 subsystem based on an external running third-party arbitrator's decision.
 Its primary use is to allow a cluster to sustain more node failures than

diff --git a/qm-cloud-init.adoc b/qm-cloud-init.adoc
index 97954791a0bcce41f184d35d5e432687fd19023e..895db9ff197eb1e1e3ac74e8d1cb013d9b9b82b9 100644 (file)
--- a/qm-cloud-init.adoc
+++ b/qm-cloud-init.adoc
@@ -126,7 +126,7 @@ qm set 123 --ipconfig0 ip=10.0.10.123/24,gw=10.0.10.1
 ----
 
 You can also configure all the Cloud-Init options using a single command
-only. We have simply splitted the above example to separate the
+only. We have simply split the above example to separate the
 commands for reducing the line length. Also make sure to adopt the IP
 setup for your specific environment.
 

diff --git a/qm.adoc b/qm.adoc
index f0d63afa07f055c780523ad042918be0dbb9cca2..0b699e24b0b440eb6f31b5922883f2b79092994b 100644 (file)
--- a/qm.adoc
+++ b/qm.adoc
@@ -144,7 +144,7 @@ hardware layout of the VM's virtual motherboard. You can choose between the
 default https://en.wikipedia.org/wiki/Intel_440FX[Intel 440FX] or the
 https://ark.intel.com/content/www/us/en/ark/products/31918/intel-82q35-graphics-and-memory-controller.html[Q35]
 chipset, which also provides a virtual PCIe bus, and thus may be desired if
-one want's to pass through PCIe hardware.
+one wants to pass through PCIe hardware.
 
 [[qm_hard_disk]]
 Hard Disk