d/changelog: fix typos/spelling

[pve-docs.git] / pvecm.adoc

diff --git a/pvecm.adoc b/pvecm.adoc
index 2af682825a8b062a1926b80f617d4482431319c7..446735ce36603fdc2dc4742d2227a78406d3ef2c 100644 (file)
--- a/pvecm.adoc
+++ b/pvecm.adoc
@@ -58,7 +58,7 @@ Grouping nodes into a cluster has the following advantages:
 Requirements
 ------------
 
-* All nodes must be able to connect to each other via UDP ports 5404 and 5405
+* All nodes must be able to connect to each other via UDP ports 5405-5412
  for corosync to work.
 
 * Date and time must be synchronized.
@@ -172,11 +172,14 @@ infrastructure for bigger clusters.
 Adding Nodes to the Cluster
 ---------------------------
 
-CAUTION: A node that is about to be added to the cluster cannot hold any guests.
-All existing configuration in `/etc/pve` is overwritten when joining a cluster,
-since guest IDs could otherwise conflict. As a workaround, you can create a
-backup of the guest (`vzdump`) and restore it under a different ID, after the
-node has been added to the cluster.
+CAUTION: All existing configuration in `/etc/pve` is overwritten when joining a
+cluster. In particular, a joining node cannot hold any guests, since guest IDs
+could otherwise conflict, and the node will inherit the cluster's storage
+configuration. To join a node with existing guest, as a workaround, you can
+create a backup of each guest (using `vzdump`) and restore it under a different
+ID after joining. If the node's storage layout differs, you will need to re-add
+the node's storages, and adapt each storage's node restriction to reflect on
+which nodes the storage is actually available.
 
 Join Node to Cluster via GUI
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1259,6 +1262,26 @@ it is likely that some nodes will boot faster than others. Please keep in
 mind that guest startup is delayed until you reach quorum.
 
 
+[[pvecm_next_id_range]]
+Guest VMID Auto-Selection
+------------------------
+
+When creating new guests the web interface will ask the backend for a free VMID
+automatically. The default range for searching is `100` to `1000000` (lower
+than the maximal allowed VMID enforced by the schema).
+
+Sometimes admins either want to allocate new VMIDs in a separate range, for
+example to easily separate temporary VMs with ones that choose a VMID manually.
+Other times its just desired to provided a stable length VMID, for which
+setting the lower boundary to, for example, `100000` gives much more room for.
+
+To accommodate this use case one can set either lower, upper or both boundaries
+via the `datacenter.cfg` configuration file, which can be edited in the web
+interface under 'Datacenter' -> 'Options'.
+
+NOTE: The range is only used for the next-id API call, so it isn't a hard
+limit.
+
 Guest Migration
 ---------------