[thumbnail="gui-datacenter-search.png"]
First, it should be noted that we can display screenshots on 'html'
-and 'wiki' pages, and we can include them in printed doumentation. But
-ith is not possible to render them inside manual pages. So screenshot
+and 'wiki' pages, and we can include them in printed documentation. But
+it is not possible to render them inside manual pages. So screenshot
inside manual pages should be optional, i.e. the text should not
depend on the visibility of the screenshot. You can include a
screenshot by setting the 'thumbnail' attribute on a paragraph:
[thumbnail="gui-datacenter-search.png"]
We normally display screenshots as small thumbnail on the right side
-of a paraprah. On printed docomentation, we render the full sized
+of a paragraph. On printed documentation, we render the full sized
graphic just before the paragraph, or between the title and the text
if the paragraph has a title. It is usually a good idea to add a title
to paragraph with screenshots.
{proxmoxGmbh} also offers commercial
http://www.proxmox.com/proxmox-ve/pricing[{pve} Subscription Service
Plans]. System Administrators with a standard subscription plan can access a
-dedicated support portal with guaranteed reponse time, where {pve}
+dedicated support portal with guaranteed response time, where {pve}
developers help them should an issue appear.
Please contact the mailto:office@proxmox.com[Proxmox sales
team] for more information or volume discounts.
include::ha-resources-opts.adoc[]
Here is a real world example with one VM and one container. As you see,
-the syntax of those files is really simple, so it is even posiible to
+the syntax of those files is really simple, so it is even possible to
read or edit those files using your favorite editor:
.Configuration Example (`/etc/pve/ha/resources.cfg`)
For bigger clusters, it makes sense to define a more detailed failover
behavior. For example, you may want to run a set of services on
`node1` if possible. If `node1` is not available, you want to run them
-equally splitted on `node2` and `node3`. If those nodes also fail the
+equally split on `node2` and `node3`. If those nodes also fail the
services should run on `node4`. To achieve this you could set the node
list to:
The LRM tells the CRM that it wants to restart, and waits until the
CRM puts all resources into the `freeze` state (same mechanism is used
-for xref:ha_manager_package_updates[Pakage Updates]). This prevents
+for xref:ha_manager_package_updates[Package Updates]). This prevents
that those resources are moved to other nodes. Instead, the CRM start
the resources after the reboot on the same node.
`max_relocate`: `<integer> (0 - N)` ('default =' `1`)::
-Maximal number of service relocate tries when a service failes to start.
+Maximal number of service relocate tries when a service fails to start.
`max_restart`: `<integer> (0 - N)` ('default =' `1`)::
documentation is written in the easy to use 'asciidoc' document format.
Editing the official documentation requires to clone the git repository at
`git://git.proxmox.com/git/pve-docs.git` and then follow the
-https://git.proxmox.com/?p=pve-docs.git;a=blob_plain;f=README.adoc;hb=HEAD[REAME.adoc] document.
+https://git.proxmox.com/?p=pve-docs.git;a=blob_plain;f=README.adoc;hb=HEAD[README.adoc] document.
Improving the documentation is just as easy as editing a Wikipedia
article and is an interesting foray in the development of a large
ZFS comes with an event daemon, which monitors events generated by the
ZFS kernel module. The daemon can also send emails on ZFS events like
-pool errors. Newer ZFS packages ships the daemon in a sparate package,
+pool errors. Newer ZFS packages ships the daemon in a separate package,
and you can install it using `apt-get`:
----
Modification of a file can be prevented by adding a `.pve-ignore.`
file for it. For instance, if the file `/etc/.pve-ignore.hosts`
exists then the `/etc/hosts` file will not be touched. This can be a
-simple empty file creatd via:
+simple empty file created via:
# touch /etc/.pve-ignore.hosts
Backup of Containers mount points
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-By default additional mount points besides the RootDisk mount point are not
-included in backups. You can reverse this default behavior by setting the
+By default additional mount points besides the Root Disk mount point are not
+included in backups. You can reverse this default behavior by setting the
* Backup* option on a mount point.
// see PVE::VZDump::LXC::prepare()
Replication of Containers mount points
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-By default additional mount points are replicated when the RootDisk
+By default additional mount points are replicated when the Root Disk
is replicated. If you want the {pve} storage replication mechanism to skip a
- mount point when starting a replication job, you can set the
+ mount point when starting a replication job, you can set the
*Skip replication* option on that mount point. +
As of {pve} 5.0, replication requires a storage of type `zfspool`, so adding a
mount point to a different type of storage when the container has replication
batch-size = 1000
batch-timeout = "1s"
-With this configuration, your server listens on all IP adresses on
+With this configuration, your server listens on all IP addresses on
port 8089, and writes the data in the *proxmox* database
|===========================================================
[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"]
|===========================================================
[thumbnail="gui-login-window.png"]
-When you connect to the server, you will first see the longin window.
+When you connect to the server, you will first see the login window.
{pve} supports various authentication backends ('Realm'), and
-you can select the langauage here. The GUI is translated to more
+you can select the language here. The GUI is translated to more
than 20 languages.
NOTE: You can save the user name on the client side by selection the
The rightmost part of the header contains four buttons:
[horizontal]
-Help :: Opens a new browser window showing the reference documenation.
+Help :: Opens a new browser window showing the reference documentation.
Create VM :: Opens the virtual machine creation wizard.
object displays configuration and status information in the content
panel. The following sections give a brief overview of the
functionality. Please refer to the individual chapters inside the
-reference documentatin to get more detailed information.
+reference documentation to get more detailed information.
Datacenter
The top header contains important VM operation commands like 'Start', 'Shutdown', 'Rest',
'Remove', 'Migrate', 'Console' and 'Help'.
Two of them have hidden buttons like 'Shutdown' has 'Stop' and
-'Console' contains the different consolen typs 'SPICE' or 'noVNC'.
+'Console' contains the different console types 'SPICE' or 'noVNC'.
On the right side the content switch white the focus of the option.
iface lo inet loopback
auto eno0
-#real IP adress
+#real IP address
iface eno1 inet static
address 192.168.10.2
netmask 255.255.255.0
iface eno2 inet manual
auto bond0
-iface bond0 inet maunal
+iface bond0 inet manual
slaves eno1 eno2
bond_miimon 100
bond_mode 802.3ad
////
TODO: explain IPv6 support?
-TODO: explan OVS
+TODO: explain OVS
////
[width="100%",cols="m,m,3*d",options="header"]
|==============================================================================
|Content types |Image formats |Shared |Snapshots |Clones
-|images rootdir vztempl iso backup |raw qcow2 vmdk subvol |no |qcow2 |qcow2
+|images rootdir vztmpl iso backup |raw qcow2 vmdk subvol |no |qcow2 |qcow2
|==============================================================================
[width="100%",cols="m,m,3*d",options="header"]
|==============================================================================
|Content types |Image formats |Shared |Snapshots |Clones
-|images vztempl iso backup |raw qcow2 vmdk |yes |qcow2 |qcow2
+|images vztmpl iso backup |raw qcow2 vmdk |yes |qcow2 |qcow2
|==============================================================================
ifdef::wiki[]
[width="100%",cols="m,m,3*d",options="header"]
|==============================================================================
|Content types |Image formats |Shared |Snapshots |Clones
-|images rootdir vztempl iso backup |raw qcow2 vmdk subvol |yes |qcow2 |qcow2
+|images rootdir vztmpl iso backup |raw qcow2 vmdk subvol |yes |qcow2 |qcow2
|==============================================================================
Examples
Instructions for GNU/Linux
~~~~~~~~~~~~~~~~~~~~~~~~~~
-You can simply use `dd` on UNUX like systems. First download the ISO
+You can simply use `dd` on UNIX like systems. First download the ISO
image, then plug in the USB stick. You need to find out what device
name gets assigned to the USB stick (see below). Then run:
Download Etcher from https://etcher.io , select the ISO and your USB Drive.
-If this doesn't work, alternatively use the OSForsenics USB
+If this doesn't work, alternatively use the OSForensics USB
installer from http://www.osforensics.com/portability.html
To build a Proxmox Ceph Cluster there should be at least three (preferably)
identical servers for the setup.
-A 10Gb network, exclusively used for Ceph, is recommmended. A meshed
+A 10Gb network, exclusively used for Ceph, is recommended. A meshed
network setup is also an option if there are no 10Gb switches
available, see {webwiki-url}Full_Mesh_Network_for_Ceph_Server[wiki] .
hostnames ensure that they are resolvable from all nodes.
In my example I want to switch my cluster communication to the 10.10.10.1/25
-network. So I replace all 'ring0_addr' respectively. I also set the bindetaddr
+network. So I replace all 'ring0_addr' respectively. I also set the bindnetaddr
in the totem section of the config to an address of the new network. It can be
any address from the subnet configured on the new network interface.
Corosync Configuration
----------------------
-The `/ect/pve/corosync.conf` file plays a central role in {pve} cluster. It
+The `/etc/pve/corosync.conf` file plays a central role in {pve} cluster. It
controls the cluster member ship and its network.
For reading more about it check the corosync.conf man page:
[source,bash]
The migration type defines if the migration data should be sent over a
encrypted (`secure`) channel or an unencrypted (`insecure`) one.
Setting the migration type to insecure means that the RAM content of a
-virtual guest gets also transfered unencrypted, which can lead to
+virtual guest gets also transferred unencrypted, which can lead to
information disclosure of critical data from inside the guest (for
example passwords or encryption keys).
---------------
{pve} has a very flexible replication scheduler. It is based on the systemd
-time calendar event format.footnote:[see `man 7 sytemd.time` for more information]
+time calendar event format.footnote:[see `man 7 systemd.time` for more information]
Calendar events may be used to refer to one or more points in time in a
single expression.
Command Line Interface Examples
-------------------------------
-Create a replication job which will run all 5 min with limited bandwidth of
+Create a replication job which will run all 5 minutes with limited bandwidth of
10 mbps (megabytes per second) for the guest with guest ID 100.
----
The following realms (authentication methods) are available:
Linux PAM standard authentication::
-In this case a system user has to exist (eg. created via the `adduser`
+In this case a system user has to exist (e.g. created via the `adduser`
command) on all nodes the user is allowed to login, and the user
authenticates with their usual system password.
+
change their own passwords via the GUI.
LDAP::
-It is possible to authenticate users via an LDAP server (eq.
+It is possible to authenticate users via an LDAP server (e.g.
openldap). The server and an optional fallback server can be
configured and the connection can be encrypted via SSL.
+
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`
-(eg. `/etc/pve/priv/ldap/my-ldap.pw`). This file should contain a
+(e.g. `/etc/pve/priv/ldap/my-ldap.pw`). This file should contain a
single line containing the raw password.
Microsoft Active Directory::
API call's schema otherwise lists it as being optional.
`["userid-group", [ <privileges>... ], <options>...]`::
-The callermust have any of the listed privileges on `/access/groups`. In
+The caller must have any of the listed privileges on `/access/groups`. In
addition there are two possible checks depending on whether the
`groups_param` option is set:
+
`["userid-param", "Realm.AllocateUser"]`::
The user needs `Realm.AllocateUser` access to `/access/realm/<realm>`, with
-`<realm>` refering to the realm of the user passed via the `userid`
+`<realm>` referring to the realm of the user passed via the `userid`
parameter. Note that the user does not need to exist in order to be
associated with a realm, since user IDs are passed in the form of
`<username>@<realm>`.
Delegate User Management
~~~~~~~~~~~~~~~~~~~~~~~~
-If you want to delegate user managenent to user `joe@pve` you can do
+If you want to delegate user management to user `joe@pve` you can do
that with:
[source,bash]
the guest OS recognizes it is running inside Qemu and cooperates with the
hypervisor.
-Qemu relies on the virtio virtualization standard, and is thus able to presente
+Qemu relies on the virtio virtualization standard, and is thus able to present
paravirtualized virtio devices, which includes a paravirtualized generic disk
controller, a paravirtualized network card, a paravirtualized serial port,
a paravirtualized SCSI controller, etc ...
it is usually a safe bet to set the number of *Total cores* to 2.
NOTE: It is perfectly safe to set the _overall_ number of total cores in all
-your VMs to be greater than the number of of cores you have on your server (ie.
+your VMs to be greater than the number of of cores you have on your server (i.e.
4 VMs with each 4 Total cores running in a 8 core machine is OK) 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.
When multiple VMs use the autoallocate facility, it is possible to set a
*Shares* coefficient which indicates the relative amount of the free host memory
-that each VM shoud take. Suppose for instance you have four VMs, three of them
+that each VM should take. Suppose for instance you have four VMs, three of them
running a HTTP server and the last one is a database server. To cache more
database blocks in the database server RAM, you would like to prioritize the
database VM when spare RAM is available. For this you assign a Shares property
of 3000 to the database VM, leaving the other VMs to the Shares default setting
-of 1000. The host server has 32GB of RAM, and is curring using 16GB, leaving 32
+of 1000. The host server has 32GB of RAM, and is currently using 16GB, leaving 32
* 80/100 - 16 = 9GB RAM to be allocated to the VMs. The database VM will get 9 *
3000 / (3000 + 1000 + 1000 + 1000) = 4.5 GB extra RAM and each HTTP server will
get 1/5 GB.
systems.
// see https://forum.proxmox.com/threads/solved-hyper-threading-vs-no-hyper-threading-fixed-vs-variable-memory.20265/
-When allocating RAMs to your VMs, a good rule of thumb is always to leave 1GB
+When allocating RAM to your VMs, a good rule of thumb is always to leave 1GB
of RAM available to the host.
{pve} will generate for each NIC a random *MAC address*, so that your VM is
addressable on Ethernet networks.
-The NIC you added to the VM can follow one of two differents models:
+The NIC you added to the VM can follow one of two different models:
* in the default *Bridged mode* each virtual NIC is backed on the host by a
_tap device_, ( a software loopback device simulating an Ethernet NIC ). This
tap device is added to a bridge, by default vmbr0 in {pve}. In this mode, VMs
have direct access to the Ethernet LAN on which the host is located.
* in the alternative *NAT mode*, each virtual NIC will only communicate with
-the Qemu user networking stack, where a builting router and DHCP server can
-provide network access. This built-in DHCP will serve adresses in the private
+the Qemu user networking stack, where a built-in router and DHCP server can
+provide network access. This built-in DHCP will serve addresses in the private
10.0.2.0/24 range. The NAT mode is much slower than the bridged mode, and
should only be used for testing.
If you are using the VirtIO driver, you can optionally activate the
*Multiqueue* option. This option allows the guest OS to process networking
packets using multiple virtual CPUs, providing an increase in the total number
-of packets transfered.
+of packets transferred.
//http://blog.vmsplice.net/2011/09/qemu-internals-vhost-architecture.html
When using the VirtIO driver with {pve}, each NIC network queue is passed to the
There are two different types of USB passthrough devices:
-* Host USB passtrough
+* Host USB passthrough
* SPICE USB passthrough
Host USB passthrough works by giving a VM a USB device of the host.
If a device is present in a VM configuration when the VM starts up,
but the device is not present in the host, the VM can boot without problems.
-As soon as the device/port ist available in the host, it gets passed through.
+As soon as the device/port is available in the host, it gets passed through.
WARNING: Using this kind of USB passthrough means that you cannot move
a VM online to another host, since the hardware is only available
There are, however, some scenarios in which a BIOS is not a good firmware
to boot from, e.g. if you want to do VGA passthrough. footnote:[Alex Williamson has a very good blog entry about this.
http://vfio.blogspot.co.at/2014/08/primary-graphics-assignment-without-vga.html]
-In such cases, you should rather use *OVMF*, which is an open-source UEFI implemenation. footnote:[See the OVMF Project http://www.tianocore.org/ovmf/]
+In such cases, you should rather use *OVMF*, which is an open-source UEFI implementation. footnote:[See the OVMF Project http://www.tianocore.org/ovmf/]
If you want to use OVMF, there are several things to consider:
can be excluded from the backup (and thus this requirement).
// see PVE::VZDump::LXC::prepare()
-NOTE: By default additional mount points besides the RootDisk mount point are
+NOTE: By default additional mount points besides the Root Disk mount point are
not included in backups. For volume mount points you can set the *Backup* option
to include the mount point in the backup. Device and bind mounts are never
backed up as their content is managed outside the {pve} storage library.
projects / pve-docs.git / commitdiff