[pve-devel] SPAM: [PATCH docs] fix typos in various adoc files
Dylan Whyte
d.whyte at proxmox.com
Thu Apr 29 12:57:56 CEST 2021
Hi,
Just a few small suggestions. Looking at some of the surrounding lines,
certain sections could probably do with a proper fix up, but I'll look
at that another day.
Reviewed-by: Dylan Whyte <d.whyte at proxmox.com>
On 4/29/21 11:46 AM, Oguz Bektas wrote:
> did quick proof reading for common misspellings or errors.
>
> some of the changes (like favourite vs. favorite or virtualization v.
> virtualisation) are because of US v. UK english
>
> Signed-off-by: Oguz Bektas <o.bektas at proxmox.com>
> ---
> certificate-management.adoc | 2 +-
> local-zfs.adoc | 6 +++---
> pve-firewall.adoc | 2 +-
> pveceph.adoc | 8 ++++----
> pveproxy.adoc | 2 +-
> pveum.adoc | 10 +++++-----
> qm-cloud-init.adoc | 10 +++++-----
> qm-pci-passthrough.adoc | 4 ++--
> qm.adoc | 20 ++++++++++----------
> translation.adoc | 2 +-
> vzdump.adoc | 2 +-
> 11 files changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/certificate-management.adoc b/certificate-management.adoc
> index 065433d..4fd2a8a 100644
> --- a/certificate-management.adoc
> +++ b/certificate-management.adoc
> @@ -313,7 +313,7 @@ root at proxmox:~# pvenode acme plugin config example_plugin
> └────────┴──────────────────────────────────────────┘
> ----
>
> -At last you can configure the domain you want to get certitficates for and
> +At last you can configure the domain you want to get certificates for and
> place the certificate order for it:
>
> ----
> diff --git a/local-zfs.adoc b/local-zfs.adoc
> index f024889..affd6fe 100644
> --- a/local-zfs.adoc
> +++ b/local-zfs.adoc
> @@ -249,7 +249,7 @@ Bootloader
>
> {pve} uses xref:sysboot_proxmox_boot_tool[`proxmox-boot-tool`] to manage the
> bootloader configuration.
> -See the chapter on xref:sysboot[{pve} host bootladers] for details.
> +See the chapter on xref:sysboot[{pve} host bootloaders] for details.
>
>
> ZFS Administration
> @@ -439,7 +439,7 @@ and you can install it using `apt-get`:
> ----
>
> To activate the daemon it is necessary to edit `/etc/zfs/zed.d/zed.rc` with your
> -favourite editor, and uncomment the `ZED_EMAIL_ADDR` setting:
> +favorite editor, and uncomment the `ZED_EMAIL_ADDR` setting:
>
> --------
> ZED_EMAIL_ADDR="root"
> @@ -515,7 +515,7 @@ to an external Storage.
>
> We strongly recommend to use enough memory, so that you normally do not
> run into low memory situations. Should you need or want to add swap, it is
> -preferred to create a partition on a physical disk and use it as swapdevice.
> +preferred to create a partition on a physical disk and use it as swap device.
s/as swap/as a swap/
> You can leave some space free for this purpose in the advanced options of the
> installer. Additionally, you can lower the
> ``swappiness'' value. A good value for servers is 10:
> diff --git a/pve-firewall.adoc b/pve-firewall.adoc
> index 648f8cb..faf580c 100644
> --- a/pve-firewall.adoc
> +++ b/pve-firewall.adoc
> @@ -475,7 +475,7 @@ Logging of firewall rules
> -------------------------
>
> By default, all logging of traffic filtered by the firewall rules is disabled.
> -To enable logging, the `loglevel` for incommig and/or outgoing traffic has to be
> +To enable logging, the `loglevel` for incoming and/or outgoing traffic has to be
> set in *Firewall* -> *Options*. This can be done for the host as well as for the
> VM/CT firewall individually. By this, logging of {PVE}'s standard firewall rules
> is enabled and the output can be observed in *Firewall* -> *Log*.
> diff --git a/pveceph.adoc b/pveceph.adoc
> index a45004a..04fce9a 100644
> --- a/pveceph.adoc
> +++ b/pveceph.adoc
> @@ -92,7 +92,7 @@ machines and containers, you must also account for having enough memory
> available for Ceph to provide excellent and stable performance.
>
> As a rule of thumb, for roughly **1 TiB of data, 1 GiB of memory** will be used
> -by an OSD. Especially during recovery, rebalancing or backfilling.
> +by an OSD. Especially during recovery, re-balancing or backfilling.
>
> The daemon itself will use additional memory. The Bluestore backend of the
> daemon requires by default **3-5 GiB of memory** (adjustable). In contrast, the
> @@ -121,7 +121,7 @@ might take long. It is recommended that you use SSDs instead of HDDs in small
> setups to reduce recovery time, minimizing the likelihood of a subsequent
> failure event during recovery.
>
> -In general SSDs will provide more IOPs than spinning disks. With this in mind,
> +In general SSDs will provide more IOPS than spinning disks. With this in mind,
s/general SSDs/general, SSDs/
> in addition to the higher cost, it may make sense to implement a
> xref:pve_ceph_device_classes[class based] separation of pools. Another way to
> speed up OSDs is to use a faster disk as a journal or
> @@ -623,7 +623,7 @@ NOTE: Further information can be found in the Ceph documentation, under the
> section CRUSH map footnote:[CRUSH map {cephdocs-url}/rados/operations/crush-map/].
>
> This map can be altered to reflect different replication hierarchies. The object
> -replicas can be separated (eg. failure domains), while maintaining the desired
> +replicas can be separated (e.g., failure domains), while maintaining the desired
> distribution.
>
> A common configuration is to use different classes of disks for different Ceph
> @@ -672,7 +672,7 @@ ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class
> |<rule-name>|name of the rule, to connect with a pool (seen in GUI & CLI)
> |<root>|which crush root it should belong to (default ceph root "default")
> |<failure-domain>|at which failure-domain the objects should be distributed (usually host)
> -|<class>|what type of OSD backing store to use (eg. nvme, ssd, hdd)
> +|<class>|what type of OSD backing store to use (e.g., nvme, ssd, hdd)
> |===
>
> Once the rule is in the CRUSH map, you can tell a pool to use the ruleset.
> diff --git a/pveproxy.adoc b/pveproxy.adoc
> index a7538b0..dea8267 100644
> --- a/pveproxy.adoc
> +++ b/pveproxy.adoc
> @@ -112,7 +112,7 @@ You can define the cipher list in `/etc/default/pveproxy`, for example
> Above is the default. See the ciphers(1) man page from the openssl
> package for a list of all available options.
>
> -Additionally you can define that the client choses the used cipher in
> +Additionally you can define that the client chooses the used cipher in
I would rephrase the line to:
"Additionally, you can set the client to choose the cipher used in"
> `/etc/default/pveproxy` (default is the first cipher in the list available to
> both client and `pveproxy`):
>
> diff --git a/pveum.adoc b/pveum.adoc
> index 1f7c69f..7f34ae4 100644
> --- a/pveum.adoc
> +++ b/pveum.adoc
> @@ -171,7 +171,7 @@ description: This is the first test user.
> The 'Base Domain Name' would be `ou=People,dc=ldap-test,dc=com` and the user
> attribute would be `uid`.
> +
> -If {pve} needs to authenticate (bind) to the ldap server before being
> +If {pve} needs to authenticate (bind) to the LDAP server before being
> able to query and authenticate users, a bind domain name can be
> configured via the `bind_dn` property in `/etc/pve/domains.cfg`. Its
> password then has to be stored in `/etc/pve/priv/ldap/<realmname>.pw`
> @@ -181,13 +181,13 @@ single line containing the raw password.
> To verify certificates, you need to to set `capath`. You can set it either
> directly to the CA certificate of your LDAP server, or to the system path
> containing all trusted CA certificates (`/etc/ssl/certs`).
> -Additionally, you need to set the `verify` option, which can also be doen over
> +Additionally, you need to set the `verify` option, which can also be done over
> the web interface.
>
> Microsoft Active Directory::
>
> A server and authentication domain need to be specified. Like with
> -ldap an optional fallback server, optional port, and SSL
> +LDAP an optional fallback server, optional port, and SSL
s/LDAP an/LDAP, an/
s/fallback server, optional port/fallback server, port/
> encryption can be configured.
>
> [[pveum_ldap_sync]]
> @@ -409,7 +409,7 @@ of predefined roles which satisfies most needs.
> * `PVETemplateUser`: view and clone templates
> * `PVEUserAdmin`: user administration
> * `PVEVMAdmin`: fully administer VMs
> -* `PVEVMUser`: view, backup, config CDROM, VM console, VM power management
> +* `PVEVMUser`: view, backup, config CD-ROM, VM console, VM power management
>
> You can see the whole set of predefined roles on the GUI.
>
> @@ -464,7 +464,7 @@ Virtual machine related privileges::
> * `VM.Audit`: view VM config
> * `VM.Clone`: clone/copy a VM
> * `VM.Config.Disk`: add/modify/delete Disks
> -* `VM.Config.CDROM`: eject/change CDROM
> +* `VM.Config.CDROM`: eject/change CD-ROM
> * `VM.Config.CPU`: modify CPU settings
> * `VM.Config.Memory`: modify Memory settings
> * `VM.Config.Network`: add/modify/delete Network devices
> diff --git a/qm-cloud-init.adoc b/qm-cloud-init.adoc
> index 895db9f..7fc86ea 100644
> --- a/qm-cloud-init.adoc
> +++ b/qm-cloud-init.adoc
> @@ -5,7 +5,7 @@ ifdef::wiki[]
> :pve-toplevel:
> endif::wiki[]
>
> -http://cloudinit.readthedocs.io[Cloud-Init] is the defacto
> +http://cloudinit.readthedocs.io[Cloud-Init] is the de facto
> multi-distribution package that handles early initialization of a
> virtual machine instance. Using Cloud-Init, configuration of network
> devices and ssh keys on the hypervisor side is possible. When the VM
> @@ -32,7 +32,7 @@ needs to store an encrypted version of that password inside the
> Cloud-Init data.
>
> {pve} generates an ISO image to pass the Cloud-Init data to the VM. For
> -that purpose all Cloud-Init VMs need to have an assigned CDROM drive.
> +that purpose all Cloud-Init VMs need to have an assigned CD-ROM drive.
s/purpose all/purpose, all/
> Also many Cloud-Init images assume to have a serial console, so it is
> recommended to add a serial console and use it as display for those VMs.
>
> @@ -70,11 +70,11 @@ qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-1
> NOTE: Ubuntu Cloud-Init images require the `virtio-scsi-pci`
> controller type for SCSI drives.
>
> -.Add Cloud-Init CDROM drive
> +.Add Cloud-Init CD-ROM drive
>
> [thumbnail="screenshot/gui-cloudinit-hardware.png"]
>
> -The next step is to configure a CDROM drive which will be used to pass
> +The next step is to configure a CD-ROM drive which will be used to pass
s/drive which/drive, which/
> the Cloud-Init data to the VM.
>
> ----
> @@ -84,7 +84,7 @@ qm set 9000 --ide2 local-lvm:cloudinit
> To be able to boot directly from the Cloud-Init image, set the
> `bootdisk` parameter to `scsi0`, and restrict BIOS to boot from disk
> only. This will speed up booting, because VM BIOS skips the testing for
> -a bootable CDROM.
> +a bootable CD-ROM.
>
> ----
> qm set 9000 --boot c --bootdisk scsi0
> diff --git a/qm-pci-passthrough.adoc b/qm-pci-passthrough.adoc
> index abb9075..1f2fd88 100644
> --- a/qm-pci-passthrough.adoc
> +++ b/qm-pci-passthrough.adoc
> @@ -309,7 +309,7 @@ Mediated Devices (vGPU, GVT-g)
>
> Mediated devices are another method to reuse features and performance from
> physical hardware for virtualized hardware. These are found most common in
> -virtualized GPU setups such as Intels GVT-g and Nvidias vGPUs used in their
> +virtualized GPU setups such as Intel's GVT-g and NVIDIA's vGPUs used in their
> GRID technology.
>
> With this, a physical Card is able to create virtual cards, similar to SR-IOV.
> @@ -324,7 +324,7 @@ In general your card's driver must support that feature, otherwise it will
> not work. So please refer to your vendor for compatible drivers and how to
> configure them.
>
> -Intels drivers for GVT-g are integrated in the Kernel and should work
> +Intel's drivers for GVT-g are integrated in the Kernel and should work
> with 5th, 6th and 7th generation Intel Core Processors, as well as E3 v4, E3
> v5 and E3 v6 Xeon Processors.
>
> diff --git a/qm.adoc b/qm.adoc
> index a1d2f3d..61c8e27 100644
> --- a/qm.adoc
> +++ b/qm.adoc
> @@ -38,7 +38,7 @@ emulated computer which sees them as if they were real devices.
> A guest operating system running in the emulated computer accesses these
> devices, and runs as it were running on real hardware. For instance you can pass
s/as it were/as if it were/
s/For instance you/For instance, you/
> an iso image as a parameter to Qemu, and the OS running in the emulated computer
> -will see a real CDROM inserted in a CD drive.
> +will see a real CD-ROM inserted in a CD drive.
s/inserted in/inserted into/
>
> Qemu can emulate a great variety of hardware from ARM to Sparc, but {pve} is
> only concerned with 32 and 64 bits PC clone emulation, since it represents the
> @@ -49,8 +49,8 @@ architecture.
>
> NOTE: You may sometimes encounter the term _KVM_ (Kernel-based Virtual Machine).
> It means that Qemu is running with the support of the virtualization processor
> -extensions, via the Linux kvm module. In the context of {pve} _Qemu_ and
> -_KVM_ can be used interchangeably as Qemu in {pve} will always try to load the kvm
> +extensions, via the Linux KVM module. In the context of {pve} _Qemu_ and
s/{pve} _Qemu_/{pve}, _Qemu_/
> +_KVM_ can be used interchangeably as Qemu in {pve} will always try to load the KVM
s/interchangeably as/interchangeably, as/
> module.
>
> Qemu inside {pve} runs as a root process, since this is required to access block
> @@ -61,7 +61,7 @@ Emulated devices and paravirtualized devices
> --------------------------------------------
>
> The PC hardware emulated by Qemu includes a mainboard, network controllers,
> -scsi, ide and sata controllers, serial ports (the complete list can be seen in
> +SCSI, IDE and SATA controllers, serial ports (the complete list can be seen in
> the `kvm(1)` man page) all of them emulated in software. All these devices
> are the exact software equivalent of existing hardware devices, and if the OS
> running in the guest has the proper drivers it will use the devices as if it
> @@ -138,7 +138,7 @@ snapshots) more intelligently.
>
> {pve} allows to boot VMs with different firmware and machine types, namely
> xref:qm_bios_and_uefi[SeaBIOS and OVMF]. In most cases you want to switch from
> -the default SeabBIOS to OVMF only if you plan to use
> +the default SeaBIOS to OVMF only if you plan to use
> xref:qm_pci_passthrough[PCIe pass through]. A VMs 'Machine Type' defines the
> 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
> @@ -271,10 +271,10 @@ However some software licenses depend on the number of sockets a machine has,
> in that case it makes sense to set the number of sockets to what the license
> allows you.
>
> -Increasing the number of virtual cpus (cores and sockets) will usually provide a
> +Increasing the number of virtual CPUs (cores and sockets) will usually provide a
> performance improvement though that is heavily dependent on the use of the VM.
> -Multithreaded applications will of course benefit from a large number of
> -virtual cpus, as for each virtual cpu you add, Qemu will create a new thread of
> +Multi-threaded applications will of course benefit from a large number of
> +virtual CPUs, as for each virtual cpu you add, Qemu will create a new thread of
> execution on the host system. If you're not sure about the workload of your VM,
> it is usually a safe bet to set the number of *Total cores* to 2.
>
> @@ -282,7 +282,7 @@ NOTE: It is perfectly safe if the _overall_ number of cores of all your VMs
> is greater than the number of cores on the server (e.g., 4 VMs with each 4
> cores on a machine with only 8 cores). In that case the host system will
> balance the Qemu execution threads between your server cores, just like if you
> -were running a standard multithreaded application. However, {pve} will prevent
> +were running a standard multi-threaded application. However, {pve} will prevent
> you from starting VMs with more virtual CPU cores than physically available, as
> this will only bring the performance down due to the cost of context switches.
>
> @@ -492,7 +492,7 @@ vCPU hot-plug
> ^^^^^^^^^^^^^
>
> Modern operating systems introduced the capability to hot-plug and, to a
> -certain extent, hot-unplug CPUs in a running systems. Virtualisation allows us
> +certain extent, hot-unplug CPUs in a running systems. Virtualization allows us
s/running systems/running system/
> to avoid a lot of the (physical) problems real hardware can cause in such
> scenarios.
> Still, this is a rather new and complicated feature, so its use should be
> diff --git a/translation.adoc b/translation.adoc
> index f925d0a..b0b8945 100644
> --- a/translation.adoc
> +++ b/translation.adoc
> @@ -76,7 +76,7 @@ perl packages installed on your system. For Debian/Ubuntu:
> Sending the Translation
> ~~~~~~~~~~~~~~~~~~~~~~~
> You can send the finished translation (`.po` file) to the Proxmox team at the address
> -office(at)proxmox.com, along with a signed contributor licence agreement.
> +office(at)proxmox.com, along with a signed contributor license agreement.
> Alternatively, if you have some developer experience, you can send it as a
> patch to the {pve} development mailing list. See
> {webwiki-url}Developer_Documentation[Developer Documentation].
> diff --git a/vzdump.adoc b/vzdump.adoc
> index 0937fe2..3d9c1f9 100644
> --- a/vzdump.adoc
> +++ b/vzdump.adoc
> @@ -449,7 +449,7 @@ but will match relative to any subdirectory. For example:
>
> # vzdump 777 --exclude-path bar
>
> -excludes any file or directoy named `/bar`, `/var/bar`, `/var/foo/bar`, and
> +excludes any file or directory named `/bar`, `/var/bar`, `/var/foo/bar`, and
> so on, but not `/bar2`.
>
> Configuration files are also stored inside the backup archive
More information about the pve-devel
mailing list