CHAPTER 18

Software Updates

5 sections · 10 min read · SimpleVM 10.1

SimpleVM is built on an enterprise Linux base, and like any host it needs periodic software updates to stay secure, stable, and compatible with the virtualization components it depends on. Updates on a virtualization host carry more weight than on a single workstation, because one host runs many virtual machines: an update that restarts a service or requires a reboot affects every VM on that host. For that reason this chapter treats updates as a planned maintenance task rather than a one-click action.

The workflow is the same each time: check the host’s status, plan a maintenance window, confirm current backups, apply updates intentionally, verify the host afterward, and plan any reboot the updates require. Routine updates are handled entirely from the Software updates page; the command line is available from the web terminal when you need it, but is rarely necessary for normal maintenance.

Cross-reference: For signing in to the management interface, see Section 6.5, Sign In with Administrative Access; for the management URL, see Section 6.3, Management URLs. To review and protect running VMs before a host reboot, see Section 8.7, Starting, Stopping, Pausing, and Rebooting VMs and, for moving VMs to another host, Section 21.5, Live VM Migration. For backups before updating, see Chapter 20, Backup and Recovery. To confirm host health after an update, see Chapter 7, Understanding the Dashboard and Host Overview. To run package commands from the browser, see Section 19.4, Web Terminal Overview and Section 19.5, Running Administrative Commands. For step-by-step update diagnosis, see Section 25.8, Update Issues. For a command reference, see Chapter 26, Advanced Administration and Command-Line Reference.

This chapter at a glance. The sections below move from understanding updates to applying them and restarting the host safely:

• Understand updates — what the Software updates page shows and why updates are a planned task (Section 18.1).
• Check before you change — view available updates and confirm the host’s current state (Section 18.2).
• Apply safely — apply updates intentionally, inside a window and with backups, then verify (Section 18.3).
• Track — read the update history to confirm what was applied and when (Section 18.4).
• Plan the reboot — restart the host without surprising the VMs it runs (Section 18.5).

18.1 Software Updates Overview

Overview

The Software updates page (under Tools in the left navigation, URL /updates) is where you check whether the SimpleVM host has package updates available, when it last checked, how update settings are configured, and what has been updated recently. Keeping the host current maintains security and stability and keeps the virtualization stack compatible with the rest of the platform.

The page is organized into three cards:

• Status — the current update state (for example, “System is up to date”), the time of the last check, and a refresh control to check again.
• Settings — Automatic updates (shown as “Not set up,” with an Enable action) and Kernel live patching (shown as “Not installed,” with an Install action).
• Update history — a list of dated update events, each with a package count, that you can expand for detail.

Underneath the product layer, updates are delivered by the standard enterprise-Linux package manager (dnf). You rarely need the command line for routine updates — the page handles checking, applying, and history — but the same information is available from the web terminal when you need it (see Section 19.5, Running Administrative Commands).

18.2 Viewing Available Updates

Overview

Before changing anything, check whether the host is current. The Status card reports the state at a glance — up to date, updates available, or a status that needs refreshing — and the time of the last check. Refreshing re-checks the host against its configured repositories. Viewing updates does not change the host, so this is a safe first step.

Before you begin

• Sign in to the SimpleVM management interface with administrative access. See Section 6.5, Sign In with Administrative Access.
• Confirm the host has network access to its configured software repositories.
• Note which virtual machines are running, in case the check leads to applying updates or a reboot. See Section 8.7, Starting, Stopping, Pausing, and Rebooting VMs.

Procedure

1. In the left navigation under Tools, open Software updates.
2. Review the Status card. It shows the current state (for example, “System is up to date”) and the last-checked time (for example, “Last checked: 2 minutes ago”).
3. To check again, select the refresh control in the Status card.
4. If updates are available, review the available-update detail before applying. Expand or open the update list if the interface provides one.

Verification

• The Status card reports the current update state and an updated last-checked time.
• If the host is current, the page reports that the system is up to date.
• If updates are available, the page lists or summarizes the packages that can be updated.

Viewing updates is read-only — it changes nothing on the host — so no revert is required. The change happens in Section 18.3, Applying Updates.

18.3 Applying Updates

Overview

Applying updates installs newer host packages from the configured repositories. On a SimpleVM host this can update the operating system, the web console components, the virtualization tools, security packages, or supporting services. Apply updates intentionally, inside a maintenance window, and verify the host afterward.

Before you begin

• Confirm a current backup of important virtual machines and host configuration exists, and that it has been tested. See Chapter 20, Backup and Recovery, and Section 20.6, Testing Backups.
• Review running VMs and decide, per your maintenance policy, whether to shut them down, migrate them, or leave them running. See Section 8.7, Starting, Stopping, Pausing, and Rebooting VMs and, for migration, Section 21.5, Live VM Migration.
• Make sure you can still reach the host if the web console session disconnects — local console access or out-of-band management.
• Do not begin updates during storage, migration, backup, or cluster maintenance unless the maintenance plan specifically accounts for it.

Procedure

1. Open Software updates.
2. Review the available updates and note whether a reboot is expected.
3. Select the update action shown by the interface — for example, Install updates or Update all.
4. Wait for the update task to complete. Do not restart the host unless the workflow instructs you to or your maintenance plan requires it.
5. If the interface reports that a reboot is required, continue to Section 18.5, Reboot Planning before restarting the host.

Verification

• The update task completes without an error message.
• The Software updates page reports the host as up to date, or shows the updates that still need attention.
• The Update history card includes the new update event.
• After any required reboot, the management interface is reachable and the expected VMs are present and in their expected state. See Chapter 7, Understanding the Dashboard and Host Overview.

Revert this change

Software updates cannot always be cleanly reverted, and on a production virtualization host reverting can be riskier than the original update. Treat recovery as a planned operation, not a quick undo.

• For review, use the Update history card or package history from the web terminal (dnf history) to see exactly what changed. See Section 19.5, Running Administrative Commands.
• For a failed or unsafe update, the safest recovery is usually to restore from a tested backup or revert to a known-good host image. See Section 20.5, Recovery Planning. If neither is available, contact SimpleVM support before attempting a rollback.
• Do not undo kernel, virtualization, storage, or security updates on a production host unless the recovery procedure has been tested.

The following review commands run from the web terminal as svmadmin, with sudo for privileged actions. They report what is installed and what changed; they do not, by themselves, constitute a supported rollback procedure for SimpleVM.

18.4 Update History

Overview

The Update history card records recent update activity — each entry dated, with a package count, and expandable for the package detail. Use it to confirm when updates were applied and to correlate a problem that appears after maintenance with a specific update event.

Procedure

1. Open Software updates.
2. Review the Update history card for recent entries. Each shows a date, time, and package count (for example, “Feb 7, 2026, 10:11 PM — 80 packages”).
3. Expand an entry to view the packages it changed, if the interface provides an expansion control.
4. For a production host, record the update time and package count in your maintenance notes.

Verification

• The history includes the most recent update activity.
• Expanding an entry shows the packages changed in that event.

The update history is a read-only record, so there is nothing to revert. The same transactions are available on the command line with dnf history from the web terminal (see Section 19.5, Running Administrative Commands, and Chapter 26, Advanced Administration and Command-Line Reference).

18.5 Reboot Planning

Overview

Some updates — kernel updates in particular — do not fully take effect until the host restarts. Reboot planning matters more on a virtualization host than on a workstation because restarting the host stops or interrupts every local VM that has not been shut down, migrated, or otherwise protected by the deployment design.

Before you begin

• Notify affected users or system owners according to your maintenance process.
• Decide whether VMs should be shut down or migrated before the restart. For migration planning, see Section 21.5, Live VM Migration; for power actions, see Section 8.7, Starting, Stopping, Pausing, and Rebooting VMs.
• Confirm host and VM backups, or recovery procedures, are current enough for the maintenance risk. See Chapter 20, Backup and Recovery.
• Make sure you can reconnect to the management interface after the reboot, and have console or out-of-band access in case it does not return as expected.

Procedure

1. Open Virtual machines and review which VMs are running.
2. Shut down, migrate, or leave VMs running according to your maintenance plan. See Section 8.7, Starting, Stopping, Pausing, and Rebooting VMs and Section 21.5, Live VM Migration.
3. Open Software updates and confirm whether a reboot is required.
4. Restart the host using your approved maintenance method — the reboot action shown by the interface, or a restart from the web terminal if that is your documented process.
5. Wait for the host to restart, then reconnect to the management interface.

Verification

• The management interface loads after the reboot. See Section 6.3, Management URLs.
• The host overview reports normal health and expected resource usage. See Section 7.2, Health and Resource Usage.
• Virtual machines are in their expected state.
• The Software updates page no longer reports a pending reboot, if that status is shown.

Revert this change

A reboot itself is not reversible: once the host restarts, the running state of any VM that was not shut down or migrated is gone. The protection is in the plan, not in an undo — confirm VMs are shut down or migrated before you restart, and keep backups current. If the host does not return as expected after a reboot, use console or out-of-band access and see Section 25.8, Update Issues.

Troubleshooting

Most update and reboot problems are connectivity or state problems: a host that does not come back, a management interface you cannot reach, or a VM that does not return to its expected state. Identify what changed and which path is affected before making further changes to a production host.