Default keybord layout for vnc server.
-`language`: `<ca | da | de | en | es | eu | fa | fr | he | it | ja | nb | nn | pl | pt_BR | ru | sl | sv | tr | zh_CN | zh_TW>` ::
+`language`: `<ar | ca | da | de | en | es | eu | fa | fr | he | hr | it | ja | ka | kr | nb | nl | nn | pl | pt_BR | ru | sl | sv | tr | ukr | zh_CN | zh_TW>` ::
Default GUI language.
-`mac_prefix`: `<string>` ::
+`mac_prefix`: `<string>` ('default =' `BC:24:11`)::
-Prefix for autogenerated MAC addresses.
+Prefix for the auto-generated MAC addresses of virtual guests. The default `BC:24:11` is the Organizationally Unique Identifier (OUI) assigned by the IEEE to Proxmox Server Solutions GmbH for a MAC Address Block Large (MA-L). You're allowed to use this in local networks, i.e., those not directly reachable by the public (e.g., in a LAN or NAT/Masquerading).
+
+Note that when you run multiple cluster that (partially) share the networks of their virtual guests, it's highly recommended that you extend the default MAC prefix, or generate a custom (valid) one, to reduce the chance of MAC collisions. For example, add a separate extra hexadecimal to the Proxmox OUI for each cluster, like `BC:24:11:0` for the first, `BC:24:11:1` for the second, and so on.
+ Alternatively, you can also separate the networks of the guests logically, e.g., by using VLANs.
++
+For publicly accessible guests it's recommended that you get your own https://standards.ieee.org/products-programs/regauth/[OUI from the IEEE] registered or coordinate with your, or your hosting providers, network admins.
`max_workers`: `<integer> (1 - N)` ::
Cluster-wide notification settings.
-`fencing`=`<always | never>` ('default =' `always`);;
+`fencing`=`<always | never>` ;;
-Control if notifications about node fencing should be sent.
-* 'always' always send out notifications
-* 'never' never send out notifications.
-For production systems, turning off node fencing notifications is notrecommended!
+UNUSED - Use datacenter notification settings instead.
`package-updates`=`<always | auto | never>` ('default =' `auto`);;
+DEPRECATED: Use datacenter notification settings instead.
Control how often the daily update job should send out notifications:
* 'auto' daily for systems with a valid subscription, as those are assumed to be production-ready and thus should know about pending updates.
* 'always' every update, if there are new pending updates.
* 'never' never send a notification for new pending updates.
-`replication`=`<always | never>` ('default =' `always`);;
+`replication`=`<always | never>` ;;
-Control if notifications for replication failures should be sent.
-* 'always' always send out notifications
-* 'never' never send out notifications.
-For production systems, turning off replication notifications is notrecommended!
+UNUSED - Use datacenter notification settings instead.
`target-fencing`=`<TARGET>` ;;
-Control where notifications about fenced cluster nodes should be sent to. Has to be the name of a notification target (endpoint or notification group). If the 'target-fencing' parameter is not set, the system will send mails to root via a 'sendmail' notification endpoint.
+UNUSED - Use datacenter notification settings instead.
`target-package-updates`=`<TARGET>` ;;
-Control where notifications about available updates should be sent to. Has to be the name of a notification target (endpoint or notification group). If the 'target-package-updates' parameter is not set, the system will send mails to root via a 'sendmail' notification endpoint.
+UNUSED - Use datacenter notification settings instead.
`target-replication`=`<TARGET>` ;;
-Control where notifications for failed storage replication jobs should be sent to. Has to be the name of a notification target (endpoint or notification group). If the 'target-replication' parameter is not set, the system will send mails to root via a 'sendmail' notification endpoint.
+UNUSED - Use datacenter notification settings instead.
`registered-tags`: `<tag>[;<tag>...]` ::
`user-allow`=`<existing | free | list | none>` ('default =' `free`);;
-Controls which tags can be set or deleted on resources a user controls (such as guests). Users with the `Sys.Modify` privilege on `/` are always unrestricted. * 'none' no tags are usable. * 'list' tags from 'user-allow-list' are usable. * 'existing' like list, but already existing tags of resources are also usable.* 'free' no tag restrictions.
+Controls which tags can be set or deleted on resources a user controls (such as guests). Users with the `Sys.Modify` privilege on `/` are alwaysunrestricted.
+* 'none' no tags are usable.
+* 'list' tags from 'user-allow-list' are usable.
+* 'existing' like list, but already existing tags of resources are also usable.
+* 'free' no tag restrictions.
`user-allow-list`=`<tag>[;<tag>...]` ;;
projects / pve-docs.git / blobdiff