[pve-devel] [PATCH pve-docs v2 1/4] Consistency of passthrough/pass-through

[Noel Ullreich <n.ullreich@proxmox.com>]

Fix consistency issues as well as grammatical mistakes with the spelling
of passthough/pass-through/pass through in the pve docs

Signed-off-by: Noel Ullreich <n.ullreich@proxmox.com>
---
 qm.adoc             | 8 ++++----
 qm.conf.5-opts.adoc | 8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/qm.adoc b/qm.adoc
index b3c3034..ca1dfa2 100644
--- a/qm.adoc
+++ b/qm.adoc
@@ -809,8 +809,8 @@ on the host the VM is currently residing.
 
 The second type of passthrough is SPICE USB passthrough. This is useful
 if you use a SPICE client which supports it. If you add a SPICE USB port
-to your VM, you can passthrough a USB device from where your SPICE client is,
-directly to the VM (for example an input device or hardware dongle).
+to your VM, you can passt a USB device from your SPICE client through
+to the VM directly (for example an input device or hardware dongle).
 
 It is also possible to map devices on a cluster level, so that they can be
 properly used with HA and hardware changes are detected and non root users
@@ -1257,7 +1257,7 @@ Online Migration
 ~~~~~~~~~~~~~~~~
 
 If your VM is running and no locally bound resources are configured (such as
-passed-through devices), you can initiate a live migration with the `--online`
+devices that are passed through), you can initiate a live migration with the `--online`
 flag in the `qm migration` command evocation. The web-interface defaults to
 live migration when the VM is running.
 
@@ -1308,7 +1308,7 @@ Offline Migration
 If you have local resources, you can still migrate your VMs offline as long as
 all disk are on storage defined on both hosts.
 Migration then copies the disks to the target host over the network, as with
-online migration. Note that any hardware pass-through configuration may need to
+online migration. Note that any hardware passthrough configuration may need to
 be adapted to the device location on the target host.
 
 // TODO: mention hardware map IDs as better way to solve that, once available
diff --git a/qm.conf.5-opts.adoc b/qm.conf.5-opts.adoc
index 2259b0a..d827262 100644
--- a/qm.conf.5-opts.adoc
+++ b/qm.conf.5-opts.adoc
@@ -74,9 +74,9 @@ Boot on floppy (a), hard disk (c), CD-ROM (d), or network (n). Deprecated, use '
 
 The guest will attempt to boot from devices in the order they appear here.
 +
-Disks, optical drives and passed-through storage USB devices will be directly
-booted from, NICs will load PXE, and PCIe devices will either behave like disks
-(e.g. NVMe) or load an option ROM (e.g. RAID controller, hardware NIC).
+Disks, optical drives and storage USB devices that are passed through will be
+directly booted from, NICs will load PXE, and PCIe devices will either behave
+like disks (e.g. NVMe) or load an option ROM (e.g. RAID controller, hardware NIC).
 +
 Note that only devices in this list will be marked as bootable and thus loaded
 by the guest firmware (BIOS/UEFI). If you require multiple disks for booting
@@ -222,7 +222,7 @@ Override PCI device ID visible to guest
 
 `host`=`<HOSTPCIID[;HOSTPCIID2...]>` ;;
 
-Host PCI device pass through. The PCI ID of a host's PCI device or a list
+Pass through host PCI device. The PCI ID of a host's PCI device or a list
 of PCI virtual functions of the host. HOSTPCIID syntax is:
 +
 'bus:dev.func' (hexadecimal numbers)
-- 
2.39.2