X-Git-Url: https://git.proxmox.com/?a=blobdiff_plain;f=pvenode.adoc;h=6ea9d7a914848647d6b7e092d62740f1aab4c1b6;hb=9deec2e220ee2f61bc808242b249f21f2a5ba55b;hp=a41085fd521bd9362c49f3c45b0e463362b2452d;hpb=ed53a3e668888dc2e629377964356be0a3388bb8;p=pve-docs.git diff --git a/pvenode.adoc b/pvenode.adoc index a41085f..6ea9d7a 100644 --- a/pvenode.adoc +++ b/pvenode.adoc @@ -16,30 +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 tool (`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[] -endif::manvolnum[] -EXAMPLES --------- +Examples +~~~~~~~~ + +.Install an externally provided certificate + `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 @@ -48,9 +56,118 @@ pvenode acme cert order systemctl restart pveproxy ----- -Setup ACME account and order a certificate for local node. +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 `` +by running: + +---- +ethtool | grep Wake-on +---- + +`pvenode` allows you to wake sleeping members of a cluster via WoL, using the +command: + +---- +pvenode wakeonlan +---- + +This broadcasts the WoL magic packet on UDP port 9, containing the MAC address +of `` 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 +---- + +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 +---- + + +[[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! ifdef::manvolnum[] include::pve-copyright.adoc[]