[pve-devel] [PATCH v2 pve-docs 1/4] remove pvenode.adoc from chapter 18

[pve-devel] [PATCH v2 pve-docs 1/4] remove pvenode.adoc from chapter 18

[Dylan Whyte]

removes pvenode.adoc inclusion from chapter 18, "Shell interface for the
Proxmox VE API", as the section is already included as part of section
3.10 "Proxmox Node Management"

Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
---

changes from v1:
* new patch. noticed after linking to pvenode.adoc from qm.adoc and
pct.adoc was causing errors in the build.

 pve-admin-guide.adoc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/pve-admin-guide.adoc b/pve-admin-guide.adoc
index f2cb040..b32b55b 100644
--- a/pve-admin-guide.adoc
+++ b/pve-admin-guide.adoc
@@ -80,8 +80,6 @@ include::pveperf.adoc[]
 
 include::pvesh.adoc[]
 
-include::pvenode.adoc[]
-
 :leveloffset: 1
 
 include::pve-faq.adoc[]
-- 
2.30.2

[pve-devel] [PATCH v2 pve-docs 2/4] fix #844: document first VM/CT start-up delay

[Dylan Whyte]

adds subsection to the "PVE Node Management" section, discussing the
initial VM/CT startup delay feature.

also makes reference to this in the Qemu & LXC sections of the
documentation.

Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
---

changes from v1:
* Add section to PVE node management section and cross reference in
pct.adoc and qm.adoc.

 pct.adoc     |  5 +++++
 pvenode.adoc | 18 ++++++++++++++++++
 qm.adoc      |  3 +++
 3 files changed, 26 insertions(+)

diff --git a/pct.adoc b/pct.adoc
index b88569f..c5ed243 100644
--- a/pct.adoc
+++ b/pct.adoc
@@ -433,6 +433,11 @@ always start after those where the parameter is set, and this parameter only
 makes sense between the machines running locally on a host, and not
 cluster-wide.
 
+If you require a delay between the host boot and the booting of the first
+container, see the section on
+xref:first_guest_boot_delay[Proxmox VE Node Management].
+
+
 Hookscripts
 ~~~~~~~~~~~
 
diff --git a/pvenode.adoc b/pvenode.adoc
index bace13c..f7835f5 100644
--- a/pvenode.adoc
+++ b/pvenode.adoc
@@ -83,6 +83,24 @@ of `<node>` obtained from the `wakeonlan` property. The node specific
 pvenode config set -wakeonlan XX:XX:XX:XX:XX:XX
 ----
 
+
+[[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
+----
+
+
 // TODO: extend and improve chapter!
 
 ifdef::manvolnum[]
diff --git a/qm.adoc b/qm.adoc
index c291cb0..80734e3 100644
--- a/qm.adoc
+++ b/qm.adoc
@@ -923,6 +923,9 @@ start after those where the parameter is set. Further, this parameter can only
 be enforced between virtual machines running on the same host, not
 cluster-wide.
 
+If you require a delay between the host boot and the booting of the first VM,
+see the section on xref:first_guest_boot_delay[Proxmox VE Node Management].
+
 
 [[qm_qemu_agent]]
 Qemu Guest Agent
-- 
2.30.2

[pve-devel] [PATCH v2 pve-docs 3/4] pvenode: add task & migrate/stop/startall sections

[Dylan Whyte]

Adds PVE Node Management sections related to viewing task history, and
bulk operations for starting, stopping, and migrating all guests.

Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
---
changes from v1:
* New patch, adding sections for items requested by @Thomas

 pvenode.adoc | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 63 insertions(+), 1 deletion(-)

diff --git a/pvenode.adoc b/pvenode.adoc
index f7835f5..dfa73aa 100644
--- a/pvenode.adoc
+++ b/pvenode.adoc
@@ -83,6 +83,54 @@ of `<node>` obtained from the `wakeonlan` property. The node specific
 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
@@ -101,7 +149,21 @@ pvenode config set --startall-onboot-delay 10
 ----
 
 
-// TODO: extend and improve chapter!
+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
+----
+
 
 ifdef::manvolnum[]
 include::pve-copyright.adoc[]
-- 
2.30.2

Re: [pve-devel] [PATCH v2 pve-docs 3/4] pvenode: add task & migrate/stop/startall sections

[Thomas Lamprecht]

On 31.08.21 12:44, Dylan Whyte wrote:
> Adds PVE Node Management sections related to viewing task history, and
> bulk operations for starting, stopping, and migrating all guests.
> 
> Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
> ---
> changes from v1:
> * New patch, adding sections for items requested by @Thomas
> 
>  pvenode.adoc | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 63 insertions(+), 1 deletion(-)
> 
> diff --git a/pvenode.adoc b/pvenode.adoc
> index f7835f5..dfa73aa 100644
> --- a/pvenode.adoc
> +++ b/pvenode.adoc
> @@ -83,6 +83,54 @@ of `<node>` obtained from the `wakeonlan` property. The node specific
>  pvenode config set -wakeonlan XX:XX:XX:XX:XX:XX
>  ----
>  
> +Task history
> +~~~~~~~~~~~~

we use title-case for the headings

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
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~

Same here, should be:

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
> @@ -101,7 +149,21 @@ pvenode config set --startall-onboot-delay 10
>  ----
>  
>  
> -// TODO: extend and improve chapter!
> +Bulk guest migration
> +~~~~~~~~~~~~~~~~~~~~

dito

> +
> +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
> +----
> +
>  
>  ifdef::manvolnum[]
>  include::pve-copyright.adoc[]
> 

[pve-devel] [PATCH v2 pve-docs 4/4] pvenode/wake-on-lan: language fix-up

[Dylan Whyte]

minor corrections to the introduction and wake-on-lan section of
"Proxmox VE Node Management"

also expand introduction, based on new content

Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
---
changes from v1:
* New patch. May as well do some fix-up while I'm here!

 pvenode.adoc | 28 +++++++++++++++-------------
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/pvenode.adoc b/pvenode.adoc
index dfa73aa..98305ce 100644
--- a/pvenode.adoc
+++ b/pvenode.adoc
@@ -24,11 +24,13 @@ ifdef::wiki[]
 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[]
@@ -43,7 +45,7 @@ Examples
 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 local node.
+.Setup ACME account and order a certificate for the local node.
 
 -----
 pvenode acme account register default mail@example.invalid
@@ -56,19 +58,19 @@ endif::manvolnum[]
 
 Wake-on-LAN
 ~~~~~~~~~~~
-Wake-on-LAN (WoL) allows 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 computers firmware (BIOS/UEFI)
+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 motherboards vendor manual, if unsure.
-`ethtool` can be used to check the WoL configuration of `<interface>` by
-running:
+'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 to wake sleeping members of a cluster via WoL using the
+`pvenode` allows you to wake sleeping members of a cluster via WoL, using the
 command:
 
 ----
@@ -76,8 +78,8 @@ 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 by the following command:
+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
-- 
2.30.2