]>
Commit | Line | Data |
---|---|---|
a99bdc62 FG |
1 | ifdef::manvolnum[] |
2 | pvenode(1) | |
3 | ========== | |
4 | :pve-toplevel: | |
5 | ||
6 | NAME | |
7 | ---- | |
8 | ||
0e9c6c13 | 9 | pvenode - Proxmox VE Node Management |
a99bdc62 FG |
10 | |
11 | SYNOPSIS | |
12 | -------- | |
13 | ||
14 | include::pvenode.1-synopsis.adoc[] | |
15 | ||
16 | DESCRIPTION | |
17 | ----------- | |
18 | endif::manvolnum[] | |
a99bdc62 | 19 | ifndef::manvolnum[] |
b8072e84 DT |
20 | |
21 | [[proxmox_node_management]] | |
a99bdc62 | 22 | Proxmox Node Management |
31bba0a9 TL |
23 | ----------------------- |
24 | ifdef::wiki[] | |
a99bdc62 | 25 | :pve-toplevel: |
31bba0a9 | 26 | endif::wiki[] |
a99bdc62 FG |
27 | endif::manvolnum[] |
28 | ||
6c2ce758 | 29 | The {PVE} node management tool (`pvenode`) allows you to control node specific |
9cbe129f TL |
30 | settings and resources. |
31 | ||
6c2ce758 DW |
32 | Currently `pvenode` allows you to set a node's description, run various |
33 | bulk operations on the node's guests, view the node's task history, and | |
34 | manage the node's SSL certificates, which are used for the API and the web GUI | |
35 | through `pveproxy`. | |
aeecd9ea | 36 | |
ed53a3e6 | 37 | ifdef::manvolnum[] |
a5d27935 DM |
38 | include::output-format.adoc[] |
39 | ||
67c9747f | 40 | Examples |
31bba0a9 TL |
41 | ~~~~~~~~ |
42 | ||
43 | .Install an externally provided certificate | |
44 | ||
aeecd9ea SI |
45 | `pvenode cert set certificate.crt certificate.key -force` |
46 | ||
31bba0a9 TL |
47 | Both files need to be PEM encoded. `certificate.key` contains the private key |
48 | and `certificate.crt` contains the whole certificate chain. | |
49 | ||
6c2ce758 | 50 | .Setup ACME account and order a certificate for the local node. |
aeecd9ea SI |
51 | |
52 | ----- | |
53 | pvenode acme account register default mail@example.invalid | |
54 | pvenode config set --acme domains=example.invalid | |
55 | pvenode acme cert order | |
56 | systemctl restart pveproxy | |
57 | ----- | |
58 | ||
31bba0a9 | 59 | endif::manvolnum[] |
9cbe129f | 60 | |
42a16720 | 61 | Wake-on-LAN |
31bba0a9 | 62 | ~~~~~~~~~~~ |
6c2ce758 DW |
63 | Wake-on-LAN (WoL) allows you to switch on a sleeping computer in the network, by |
64 | sending a magic packet. At least one NIC must support this feature, and the | |
65 | respective option needs to be enabled in the computer's firmware (BIOS/UEFI) | |
42a16720 | 66 | configuration. The option name can vary from 'Enable Wake-on-Lan' to |
6c2ce758 DW |
67 | 'Power On By PCIE Device'; check your motherboard's vendor manual, if you're |
68 | unsure. `ethtool` can be used to check the WoL configuration of `<interface>` | |
69 | by running: | |
42a16720 CE |
70 | |
71 | ---- | |
72 | ethtool <interface> | grep Wake-on | |
73 | ---- | |
74 | ||
6c2ce758 | 75 | `pvenode` allows you to wake sleeping members of a cluster via WoL, using the |
42a16720 CE |
76 | command: |
77 | ||
78 | ---- | |
79 | pvenode wakeonlan <node> | |
80 | ---- | |
81 | ||
82 | This broadcasts the WoL magic packet on UDP port 9, containing the MAC address | |
6c2ce758 DW |
83 | of `<node>` obtained from the `wakeonlan` property. The node-specific |
84 | `wakeonlan` property can be set using the following command: | |
42a16720 CE |
85 | |
86 | ---- | |
87 | pvenode config set -wakeonlan XX:XX:XX:XX:XX:XX | |
88 | ---- | |
89 | ||
6c46e10c DW |
90 | Task History |
91 | ~~~~~~~~~~~~ | |
92 | ||
93 | When troubleshooting server issues, for example, failed backup jobs, it can | |
94 | often be helpful to have a log of the previously run tasks. With {pve}, you can | |
95 | access the nodes's task history through the `pvenode task` command. | |
96 | ||
97 | You can get a filtered list of a node's finished tasks with the `list` | |
98 | subcommand. For example, to get a list of tasks related to VM '100' | |
99 | that ended with an error, the command would be: | |
100 | ||
101 | ---- | |
102 | pvenode task list --errors --vmid 100 | |
103 | ---- | |
104 | ||
105 | The log of a task can then be printed using its UPID: | |
106 | ||
107 | ---- | |
920dac8b | 108 | pvenode task log UPID:pve1:00010D94:001CA6EA:6124E1B9:vzdump:100:root@pam: |
6c46e10c DW |
109 | ---- |
110 | ||
111 | ||
112 | Bulk Guest Power Management | |
113 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
114 | ||
115 | In case you have many VMs/containers, starting and stopping guests can be | |
116 | carried out in bulk operations with the `startall` and `stopall` subcommands of | |
117 | `pvenode`. By default, `pvenode startall` will only start VMs/containers which | |
118 | have been set to automatically start on boot (see | |
119 | xref:qm_startup_and_shutdown[Automatic Start and Shutdown of Virtual Machines]), | |
120 | however, you can override this behavior with the `--force` flag. Both commands | |
121 | also have a `--vms` option, which limits the stopped/started guests to the | |
122 | specified VMIDs. | |
123 | ||
124 | For example, to start VMs '100', '101', and '102', regardless of whether they | |
125 | have `onboot` set, you can use: | |
126 | ||
127 | ---- | |
128 | pvenode startall --vms 100,101,102 --force | |
129 | ---- | |
130 | ||
131 | To stop these guests (and any other guests that may be running), use the | |
132 | command: | |
133 | ||
134 | ---- | |
135 | pvenode stopall | |
136 | ---- | |
137 | ||
0f7778ac DW |
138 | |
139 | [[first_guest_boot_delay]] | |
140 | First Guest Boot Delay | |
141 | ~~~~~~~~~~~~~~~~~~~~~~ | |
142 | ||
143 | In case your VMs/containers rely on slow-to-start external resources, for | |
144 | example an NFS server, you can also set a per-node delay between the time {pve} | |
145 | boots and the time the first VM/container that is configured to autostart boots | |
146 | (see xref:qm_startup_and_shutdown[Automatic Start and Shutdown of Virtual Machines]). | |
147 | ||
148 | You can achieve this by setting the following (where `10` represents the delay | |
149 | in seconds): | |
150 | ||
151 | ---- | |
152 | pvenode config set --startall-onboot-delay 10 | |
153 | ---- | |
154 | ||
155 | ||
6c46e10c DW |
156 | Bulk Guest Migration |
157 | ~~~~~~~~~~~~~~~~~~~~ | |
158 | ||
159 | In case an upgrade situation requires you to migrate all of your guests from one | |
160 | node to another, `pvenode` also offers the `migrateall` subcommand for bulk | |
161 | migration. By default, this command will migrate every guest on the system to | |
162 | the target node. It can however be set to only migrate a set of guests. | |
163 | ||
164 | For example, to migrate VMs '100', '101', and '102', to the node 'pve2', with | |
165 | live-migration for local disks enabled, you can run: | |
166 | ||
167 | ---- | |
168 | pvenode migrateall pve2 --vms 100,101,102 --with-local-disks | |
169 | ---- | |
170 | ||
a99bdc62 FG |
171 | |
172 | ifdef::manvolnum[] | |
173 | include::pve-copyright.adoc[] | |
174 | endif::manvolnum[] |