]> git.proxmox.com Git - pve-docs.git/blobdiff - pvenode.adoc
vzdump: drop overly scary & outdated warning about fleecing
[pve-docs.git] / pvenode.adoc
index 073a30180a25e6a1df4a40a0f8e0c613c9268832..21a46a8650ea5bef15b7d0479faf8988b17d7dd0 100644 (file)
@@ -6,7 +6,7 @@ pvenode(1)
 NAME
 ----
 
-pvenode - {PVE} Node Management
+pvenode - Proxmox VE Node Management
 
 SYNOPSIS
 --------
@@ -16,26 +16,38 @@ include::pvenode.1-synopsis.adoc[]
 DESCRIPTION
 -----------
 endif::manvolnum[]
-
 ifndef::manvolnum[]
+
+[[proxmox_node_management]]
 Proxmox Node Management
-=======================
+-----------------------
+ifdef::wiki[]
 :pve-toplevel:
+endif::wiki[]
 endif::manvolnum[]
 
-The {PVE} node management tools (`pvenode`) allows to control node specific
+The {PVE} node management tool (`pvenode`) allows you to control node specific
 settings and resources.
 
-Currently `pvenode` allows to set a node's description and to manage
-the node's SSL certificates used for the API and the web GUI through `pveproxy`.
+Currently `pvenode` allows you to set a node's description, run various
+bulk operations on the node's guests, view the node's task history, and
+manage the node's SSL certificates, which are used for the API and the web GUI
+through `pveproxy`.
+
+ifdef::manvolnum[]
+include::output-format.adoc[]
+
+Examples
+~~~~~~~~
+
+.Install an externally provided certificate
 
-EXAMPLES
---------
 `pvenode cert set certificate.crt certificate.key -force`
 
-Install an externally provided certificate. Both files need to be PEM encoded.
-`certificate.key` contains the private key and `certificate.crt` contains the
-whole certificate chain.
+Both files need to be PEM encoded. `certificate.key` contains the private key
+and `certificate.crt` contains the whole certificate chain.
+
+.Setup ACME account and order a certificate for the local node.
 
 -----
 pvenode acme account register default mail@example.invalid
@@ -44,9 +56,141 @@ pvenode acme cert order
 systemctl restart pveproxy
 -----
 
-Configure acme to get certificates.
+endif::manvolnum[]
+
+Wake-on-LAN
+~~~~~~~~~~~
+Wake-on-LAN (WoL) allows you to switch on a sleeping computer in the network, by
+sending a magic packet. At least one NIC must support this feature, and the
+respective option needs to be enabled in the computer's firmware (BIOS/UEFI)
+configuration. The option name can vary from 'Enable Wake-on-Lan' to
+'Power On By PCIE Device'; check your motherboard's vendor manual, if you're
+unsure. `ethtool` can be used to check the WoL configuration of `<interface>`
+by running:
+
+----
+ethtool <interface> | grep Wake-on
+----
+
+`pvenode` allows you to wake sleeping members of a cluster via WoL, using the
+command:
+
+----
+pvenode wakeonlan <node>
+----
+
+This broadcasts the WoL magic packet on UDP port 9, containing the MAC address
+of `<node>` obtained from the `wakeonlan` property. The node-specific
+`wakeonlan` property can be set using the following command:
+
+----
+pvenode config set -wakeonlan XX:XX:XX:XX:XX:XX
+----
+
+The interface via which to send the WoL packet is determined from the default
+route. It can be overwritten by setting the `bind-interface` via the following
+command:
+
+----
+pvenode config set -wakeonlan XX:XX:XX:XX:XX:XX,bind-interface=<iface-name>
+----
+
+The broadcast address (default `255.255.255.255`) used when sending the WoL
+packet can further be changed by setting the `broadcast-address` explicitly
+using the following command:
+
+----
+pvenode config set -wakeonlan XX:XX:XX:XX:XX:XX,broadcast-address=<broadcast-address>
+----
+
+Task History
+~~~~~~~~~~~~
+
+When troubleshooting server issues, for example, failed backup jobs, it can
+often be helpful to have a log of the previously run tasks. With {pve}, you can
+access the nodes's task history through the `pvenode task` command.
+
+You can get a filtered list of a node's finished tasks with the `list`
+subcommand. For example, to get a list of tasks related to VM '100'
+that ended with an error, the command would be:
+
+----
+pvenode task list --errors --vmid 100
+----
+
+The log of a task can then be printed using its UPID:
+
+----
+pvenode task log UPID:pve1:00010D94:001CA6EA:6124E1B9:vzdump:100:root@pam:
+----
+
+
+Bulk Guest Power Management
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In case you have many VMs/containers, starting and stopping guests can be
+carried out in bulk operations with the `startall` and `stopall` subcommands of
+`pvenode`.  By default, `pvenode startall` will only start VMs/containers which
+have been set to automatically start on boot (see
+xref:qm_startup_and_shutdown[Automatic Start and Shutdown of Virtual Machines]),
+however, you can override this behavior with the `--force` flag. Both commands
+also have a `--vms` option, which limits the stopped/started guests to the
+specified VMIDs.
+
+For example, to start VMs '100', '101', and '102', regardless of whether they
+have `onboot` set, you can use:
+
+----
+pvenode startall --vms 100,101,102 --force
+----
+
+To stop these guests (and any other guests that may be running), use the
+command:
+
+----
+pvenode stopall
+----
+
+NOTE: The stopall command first attempts to perform a clean shutdown and then
+waits until either all guests have successfully shut down or an overridable
+timeout (3 minutes by default) has expired. Once that happens and the
+force-stop parameter is not explicitly set to 0 (false), all virtual guests
+that are still running are hard stopped.
+
+
+[[first_guest_boot_delay]]
+First Guest Boot Delay
+~~~~~~~~~~~~~~~~~~~~~~
+
+In case your VMs/containers rely on slow-to-start external resources, for
+example an NFS server, you can also set a per-node delay between the time {pve}
+boots and the time the first VM/container that is configured to autostart boots
+(see xref:qm_startup_and_shutdown[Automatic Start and Shutdown of Virtual Machines]).
+
+You can achieve this by setting the following (where `10` represents the delay
+in seconds):
+
+----
+pvenode config set --startall-onboot-delay 10
+----
+
+
+Bulk Guest Migration
+~~~~~~~~~~~~~~~~~~~~
+
+In case an upgrade situation requires you to migrate all of your guests from one
+node to another, `pvenode` also offers the `migrateall` subcommand for bulk
+migration. By default, this command will migrate every guest on the system to
+the target node. It can however be set to only migrate a set of guests.
+
+For example, to migrate VMs '100', '101', and '102', to the node 'pve2', with
+live-migration for local disks enabled, you can run:
+
+----
+pvenode migrateall pve2 --vms 100,101,102 --with-local-disks
+----
 
-// TODO: extend and improve chapter!
+// TODO: explain node shutdown (stopall is used there) and maintenance options
 
 ifdef::manvolnum[]
 include::pve-copyright.adoc[]