Restarting and patching hypervisor hosts

A hypervisor restart takes every guest on it down with it, so Tenvara never restarts a hypervisor host on its own. Updates are installed in the patch window as on any other device; the restart is left to a person, who sees Restart needed on the host and restarts it with Restart this host when it suits the customer.

The Hypervisor hosts group and patch policy#

Every install has a built-in device group and a built-in patch policy, both called Hypervisor hosts, in both editions.

The group is dynamic and covers every customer (your organisation in the Company edition). A device joins it by itself when:

• it runs Proxmox VE (or XCP-ng or XenServer);
• it runs the Hyper-V role;
• or Infrastructure > Hypervisors knows it as a host.

The same rule is offered as Hypervisor hosts in the group editor if you want it in a group of your own.

The policy applies to that group, above any policy you scoped to a group, and sets one thing: the host is never restarted after updates. Everything else (which updates are approved, the patch window, the customer's and the site's settings) comes from your other policies, so a hypervisor host is patched like any other server. A device's own policy still wins.

Both built-ins can be renamed, changed and switched off, but not deleted: where other groups and policies offer delete, these offer to switch off. Switching the policy on switches its group on too. If your install already had its own group for hypervisors with a never-restart policy, the built-ins start switched off with a note naming yours, so nothing changes until you decide.

Note: Compliance still counts a restart left pending past the policy's grace days, so a host nobody restarts shows up in your patch compliance figures.

See Patching for groups, policies and windows.

Restart needed#

A host is flagged Restart needed when patching is waiting for a restart, or when a Proxmox VE node runs an older kernel than the one installed. You see it:

• on the node's row and its page, with a Restart needed callout;
• on the host's device page, which names the policy that does not restart it;
• on Infrastructure > Hypervisors, as a badge such as "1 to restart" in the cluster's Platform column.

On a host that Infrastructure has adopted, the device page offers Restart this host rather than an ordinary restart, so the guests are looked after.

Restart this host (Proxmox VE)#

Restart this host restarts one node and nothing else: no packages are installed. Open it from:

• the node's page, or its Restart needed callout;
• the cluster page's More actions menu, Restart a host;
• the "to restart" badge on Infrastructure > Hypervisors, or press r on the cluster's row.

1. Under Host, pick the node. Nodes that need a restart are listed first, marked "(restart needed)".
2. Under Running guests, choose:
   • Move them off live: guests managed by HA leave through maintenance mode; the others move live to the online node with the most room that can take them (shared storage, or local disks the other node also has).
   • Leave them where they are: nothing moves.
3. Under Guests that cannot move live, choose for each one:
   • Shut down: shut down cleanly before the restart and started again afterwards (the default).
   • Leave it to the host: the node's own guest shutdown takes it down with the host, and it is started again afterwards.
   • Cancel the restart: nothing starts while any guest says this.
4. Set Each guest has this long to shut down (a guest's own shutdown timeout in Proxmox comes first), and tick Force a guest off if it has not shut down in time if the run should not pause on a guest that hangs.
5. Press Restart with the node's name.

The run then waits for the node's own report from after the restart and, in a cluster, for quorum. It takes the node out of maintenance mode, starts the guests it shut down in their Proxmox start order, and brings the guests it moved back. Every step is a line of the node's log on the run, in plain words, and the audit log records the restart. You can cancel a restart until the node actually restarts.

Mark guests that should never move (local disks, a passed-through device, too big for any other node) as Never move on their page: see Managing virtual machines and containers.

One host at a time#

In a cluster, only one run (a restart or an update run) goes at a time. If one is already going, the dialog says so under One host at a time and its button reads Restart when its turn comes: the restart waits as queued and starts by itself when the run before it ends. A run that is paused keeps the others waiting until it is resumed or cancelled.

A restart is refused for a node that is offline or has no connected agent, and for a cluster read through a Proxmox VE API connection (there is no agent on the node to restart it).

A paused update run and Repair packages#

Update hosts on the cluster page installs updates node by node. If a package fails to install on a node, the node's agent repairs the half-installed packages once and runs the upgrade again before giving up.

If the packages are still not right, the run pauses on that node, and Tenvara will not reboot it, because a node with half-installed packages may have an incomplete kernel or boot loader:

1. The node page shows Upgrade interrupted: packages half-installed with the packages and What dpkg said.
2. Press Repair packages to run the repair again on the node, or fix it on the node yourself.
3. Once it is fixed, Resume the run. It carries on from where it stopped.

Wherever a paused run blocks something (the node page, the Update hosts dialog, the restart dialog), it is named with the node and the error, Resume, Cancel the run and a link to the run. When you are sure the packages are safe, Restart anyway goes past the check; Tenvara asks you to confirm and records it in the audit log.

Permissions#

Restarting a host, repairing packages and running host updates need Infrastructure Manage and an adopted cluster. See Infrastructure overview.

Related#

• Proxmox clusters and nodes
• Hyper-V hosts and virtual machines
• Proxmox tasks, backups and alerts