checked for common misspellings. some of the changes (like favourite vs.
favorite or virtualization vs. virtualisation) are because of US vs. UK english
Reviewed-by: Dylan Whyte <d.whyte@proxmox.com>
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
└────────┴──────────────────────────────────────────┘
----
-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:
----
{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
----
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"
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 a swap device.
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:
-------------------------
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*.
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
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,
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
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
|<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.
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 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`):
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`
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
-encryption can be configured.
+A server and authentication domain need to be specified. Like with LDAP, an
+optional fallback server, port, and SSL encryption can be configured.
[[pveum_ldap_sync]]
Syncing LDAP-based realms
* `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.
* `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
: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
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.
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.
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
the Cloud-Init data to the VM.
----
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
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.
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.
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
-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.
+devices, and runs as if it were running on real hardware. For instance, you can pass
+an ISO image as a parameter to Qemu, and the OS running in the emulated computer
+will see a real CD-ROM inserted into a CD drive.
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
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
+_KVM_ can be used interchangeably, as Qemu in {pve} will always try to load the KVM
module.
Qemu inside {pve} runs as a root process, since this is required to access block
--------------------------------------------
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
{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
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.
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.
^^^^^^^^^^^^^
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 system. Virtualization allows us
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
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].
# 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
projects / pve-docs.git / commitdiff