Documentation Post-Installation Configuration

CHAPTER 05

Post-Installation Configuration

15 sections · 26 min read · SimpleVM 10.1

Post-installation configuration is the bridge between installing SimpleVM and operating it. The goal is not to rebuild the platform — the installer already delivered a running, security-hardened host with the virtualization components in place. The goal is to confirm that the host is ready to carry virtual machines, and to prepare the one thing the installer may leave for you: the data volume that backs your storage pools. Chapter 4, Installing SimpleVM ends with a host that boots and shows a management URL; this chapter walks the short set of checks that turn that into a host you can trust with production workloads.

A SimpleVM host keeps its operating system separate from virtual machine data. In the reference build, the operating system is installed on a mirrored disk, and VM data lives on a separate disk mounted at /data; the storage pools that hold VM images and ISO files (/data/images and /data/isos) live on that data volume, not on the operating system disk. This separation is the single most important storage design decision, and it recurs through configuration, storage, backup, and migration. The principle is the OS/data separation itself — the specific RAID levels are environment-specific. See Section 3.4, Storage Planning, and Chapter 13, Managing Host Storage.

The configuration at a glance. Each step below explains what you are doing and why, not only which control to use. The readiness sequence is:

  • Confirm access — read the management URL from the host console and reach the web console (Section 5.2).
  • Review the host — sign in and check health, resource usage, host name, and time (Section 5.3), and confirm administrative access before making changes (Section 5.4).
  • Prepare storage — identify the operating system disk and the separate data volume (Section 5.5), prepare the data volume (Section 5.6), and verify the VM image and ISO storage pools (Section 5.7).
  • Review networking and security — host networking (Section 5.8), firewall zones and services (Section 5.9), and SELinux (Section 5.10).
  • Confirm maintenance state — review update status (Section 5.11), then complete the readiness checklist (Section 5.12).

Before you begin

Confirm the following before you start. Most map to work you have already done in installation and planning:

  • SimpleVM 10.1 installed and verified. The host boots, shows its console, and you can already reach the web console. See Chapter 4, Installing SimpleVM (and Section 4.10, Post-Installation Verification).
  • The management URL from the host console, recorded during installation — in the form https://<host>:9090.
  • The administrator account created during installation (the default name is svmadmin) and its password. The root account is disabled by default; you administer the host through this account.
  • Your planning decisions from Chapter 3 — storage layout (Section 3.4, Storage Planning), networking (Section 3.5, Network Planning), and host identity (Section 3.6, Hostname, DNS, and Time Synchronization Planning).
  • A way to reach the server's console or out-of-band management — a directly attached keyboard and monitor, or the server's management controller (for example, a BMC, IPMI, iDRAC, or iLO console) — in case a networking or firewall change interrupts your browser session.
  • A supported browser — a current version of Microsoft Edge, Google Chrome, or Mozilla Firefox.

5.1 Configuration Goals

Overview

Think of this chapter as a readiness review rather than a build. The host arrives from installation already configured to run virtual machines; what remains is to confirm that the pieces a workload depends on are present and healthy, and to finish preparing storage if the installer left the data volume for you. Working through the checks in order means that by the time you create your first production VM, you already know the host is reachable, healthy, correctly storaged, connected, and secured.

Specifically, post-installation configuration confirms that you can:

  • Reach the web console at the management URL shown on the host console, and sign in with an administrative account.
  • See expected host health, resource usage, host name, and system time.
  • Tell the operating system disk apart from the separate data volume, and prepare that data volume for use.
  • Confirm the VM image and ISO storage pools are active, persistent, and set to start automatically.
  • Review host networking, the firewall, and SELinux without weakening the host's security posture.
  • Review update status, and complete a readiness checklist before VM creation.

Most steps here only read and confirm. A few change the host — preparing the data volume, and any firewall or SELinux adjustments you choose to make. Those changes are reversible only where a safe recovery path exists, so this chapter ends with a consolidated Revert this change section and a Troubleshooting section that the change-making steps point back to.

5.2 Confirm the Host Console and Management URL

Overview

After SimpleVM restarts, the local console displays the host login prompt and the management URLs. You use this screen for one purpose here: to confirm the host finished booting and to read the address administrators use to reach the web console from another computer. You do not log in at this text console for routine work — administration happens in the browser — but the management address comes from here.

Figure 5-1. The SimpleVM host console after first boot, showing the product and build (Thinware SimpleVM 10.1.2601.1), the base operating system and kernel, and the management URLs on port 9090 under Management Console, followed by the login prompt.
Figure 5-1. The SimpleVM host console after first boot, showing the product and build (Thinware SimpleVM 10.1.2601.1), the base operating system and kernel, and the management URLs on port 9090 under Management Console, followed by the login prompt.

Procedure

  1. At the physical console or the server's remote console, wait for the SimpleVM login prompt to appear.
  2. Locate the management address listed under Management Console. It is shown in the form https://<host>:9090 — for example, https://tw-rnd1.thinware.lab:9090 and https://10.0.0.52:9090.
  3. If more than one URL is listed — which happens when the host has more than one network address — record the address on the network you manage the host from.
  4. From an administrator workstation on that network, open a supported browser and enter the management URL exactly as shown, including the https:// prefix and the:9090 port.

Terminology: The host console labels the address Management Console, while this guide refers to the same thing as the web console or the SimpleVM management interface. These are the same interface, reached at https://<host>:9090 — the difference is wording, not function.

Verification

The browser should reach the host and present the SimpleVM sign-in page. On a newly installed host you may first see a certificate warning, because the host is presenting its default certificate; confirm the address matches the intended host before you continue. Signing in is covered in Chapter 6, Accessing the SimpleVM Management Interface.

Troubleshooting

If the browser cannot reach the interface, confirm the host is powered on and showing its console, that you entered the address with the https:// prefix and the:9090 port, and that the workstation can reach the host on the network. If the console listed more than one URL, try the alternate address. See Section 25.3, Login and Access Issues.

5.3 Sign In and Review the Host Overview

Overview

The host Overview page is the first place to confirm a host is healthy after installation, and the page you return to before any administrative work. It presents four panels — Health, Usage, System information, and Configuration — giving you system health, live CPU and memory usage, hardware and identity details, and key settings such as host name, system time, and performance profile. A short review here catches problems before they reach a workload.

Figure 5-2. The SimpleVM host Overview page, with the Health, Usage, System information, and Configuration panels, and the System and Tools navigation groups on the left.
Figure 5-2. The SimpleVM host Overview page, with the Health, Usage, System information, and Configuration panels, and the System and Tools navigation groups on the left.

Procedure

  1. Open the management URL in your browser and sign in with the administrator account created during installation (default svmadmin).
  2. Confirm the Overview page loads. The left navigation shows two groups: System (Overview, Virtual machines, Storage, Networking, Logs, Services, Accounts) and Tools (File browser, Software updates, SELinux, Diagnostic reports, Kernel dump, Terminal).
  3. In Health, check the update status and the last successful login. A newly installed host should report a clean state.
  4. In Usage, confirm CPU and memory are at expected idle levels — a freshly installed host with no running VMs should not show high CPU or memory pressure.
  5. In System information, confirm the model, machine ID, and uptime look correct for the host you intend to configure.
  6. In Configuration, confirm the host name and system time are correct, and note the performance profile (the SimpleVM host profile is virtual-host).

Why time matters: Accurate system time underpins logs, certificates, authentication, updates, clustering, and troubleshooting. Confirm the host name and time now — both are far easier to correct before workloads and cluster relationships depend on them.

Verification

The host shows normal health and expected idle resource usage, with the correct host name and system time and no failed services. Resolve any significant warning before creating production VMs. The Overview page is an operational starting point, not a full monitoring tool; for what each panel means in depth, see Chapter 7, Understanding the Dashboard and Host Overview.

5.4 Review Administrative Access

Overview

Several steps in this chapter change the host — preparing storage, and any firewall or SELinux adjustments. Those require administrative privileges. Before you make system-level changes, confirm you are signed in as the intended administrator and that you can elevate to administrative access when a task needs it. SimpleVM separates everyday viewing from privileged change: a user may see information while still needing to elevate before changing storage, networking, the firewall, updates, or VMs.

Procedure

  1. Confirm the signed-in user is the intended administrative account. The current user is shown at the top left of the interface.
  2. Locate the Administrative access indicator at the top right of the page. This is the control SimpleVM uses to elevate from limited to administrative access.
  3. When a task requires elevated privileges, use Administrative access to elevate, and provide credentials if prompted.
  4. Do not use a shared account for production administration unless that is your organization's approved practice. Each administrator should use a named account.

5.5 Identify the OS Disk and Data Storage Volume

Overview

Before you prepare or assign any storage, identify which disk holds the SimpleVM operating system and which disk or volume is intended for VM data. This matters most on servers with several virtual disks or RAID volumes, where it is easy to act on the wrong device. The Storage page (under System) shows the host's disks, partitions, filesystems, logical volumes, and mount points, along with read and write activity.

Figure 5-3. The host Storage page: read/write activity graphs at the top, then a storage table listing disks, partitions, logical volumes, and mount points. In the reference build,  sda  carries the operating system and  sdb  is the data volume mounted at  /data .
Figure 5-3. The host Storage page: read/write activity graphs at the top, then a storage table listing disks, partitions, logical volumes, and mount points. In the reference build, sda carries the operating system and sdb is the data volume mounted at /data .

Identify disks by their characteristics, not their names. Device names such as /dev/sda and /dev/sdb vary by server and storage controller. Confirm the target by its size, model, RAID or controller mapping, and existing partitions — never by device name alone.

In the reference build, the host storage page confirms this layout:

DeviceRoleDetails
sdaOperating system diskDELL PERC H730, GPT, 480 GB — partitions sda1 (/boot/efi, vfat), sda2 (/boot, xfs), and sda3 (LVM2 physical volume, group rl)
rl (LVM)OS logical volumesVolume group rl provides / and /home (xfs)
sdbData volumeDELL PERC H730, xfs, mounted at /data (3.6 TB) — backs the VM image and ISO storage pools
sr0Optical driveMedia drive

Procedure

  1. In the left navigation, under System, open Storage.
  2. Review the storage table — disks, partitions, filesystems, and logical volumes.
  3. Identify the operating system disk by its system partitions: the EFI partition (/boot/efi), the boot partition (/boot), and the LVM volumes for / and /home.
  4. Identify the separate data disk or data volume intended for VM storage. In the reference build this is sdb, mounted at /data.
  5. Confirm the data volume's size matches your deployment plan, and note whether it is already formatted and mounted.

Verification

You can point to the operating system disk and the data volume on the Storage page and state which is which. If the data volume already appears mounted at its intended path with the expected capacity, the installer prepared it for you and you can move to Section 5.7. If it does not, prepare it in Section 5.6. For a fuller treatment of host storage, see Chapter 13, Managing Host Storage.

5.6 Prepare the Data Volume for Storage Pools

Overview

If the data volume is not yet formatted and mounted after installation, prepare it before creating or assigning storage pools. Preparing the volume turns the second disk into a mounted filesystem the host can use, and gives SimpleVM a stable, persistent location for VM disk images and ISO files on storage that is separate from the operating system. The storage pool itself is created separately, in the virtual machine storage workflow (Section 5.7); this step prepares the storage the pool will point at.

Use the web console workflow where it is available, because it gives you a visual confirmation of the disk and mount point you are acting on. Command-line examples are included as verification and support references.

Recommended settings. These are sensible defaults for a SimpleVM data volume; adjust them only if your environment requires it.

SettingRecommended valueReason
Partition tableGPTStandard for modern systems and for disks larger than 2 TB.
FilesystemXFSThe default for large Linux storage volumes on the RHEL family, unless a project requirement says otherwise. The reference data volume is XFS.
Mount point/dataThe confirmed SimpleVM data mount point that backs the storage pools.
VM image directory/data/imagesThe confirmed target path of the default VM image storage pool.
ISO directory/data/isosThe confirmed target path of the isos storage pool.
Mount at bootEnabledThe storage must come back automatically after a host restart, or VMs cannot start.
EncryptionEnvironment-specificUse only if your organization has a key-management and recovery process.

Before you begin

  • SimpleVM is installed and has booted successfully.
  • You are signed in with administrative access (Section 5.4).
  • You have identified the operating system disk and the separate data volume (Section 5.5).
  • You have confirmed no data you need exists on the target data disk.

Procedure

  1. Under System, open Storage.
  2. Select the data disk or volume intended for VM storage. Confirm it is the right device by size, model, and controller — not by device name.
  3. Create the partition, filesystem, or logical volume your plan calls for — typically a GPT partition table and an XFS filesystem.
  4. Mount the prepared filesystem at the SimpleVM data location (/data).
  5. Confirm the mount is persistent so the storage returns automatically after a reboot.
  6. Create or confirm the directories used for VM images and ISO files (/data/images and /data/isos).

What this does: This turns the raw data disk into a mounted, persistent filesystem the host can use, located on storage separate from the operating system. It does not yet create a storage pool — SimpleVM is pointed at this location in Section 5.7.

Verification

Confirm, from the web console, that the new filesystem appears on the Storage page, that the mount point shows the expected path, that available capacity matches the data volume's size, and that the filesystem is mounted and set to mount automatically at boot.

From the web terminal or an administrative shell, the following read-only commands confirm the mount. They only display information and change nothing:

lsblk -f # disks, partitions, filesystems, and mount points findmnt /data # confirm the data volume is mounted at /data df -h /data # filesystem type and available capacity

The output should show the data partition mounted at /data, and the filesystem type should match what you formatted.

5.7 Verify VM Image and ISO Storage Pools

Overview

A storage pool is the VM-facing storage layer: it exposes a prepared host storage location to SimpleVM for VM disk images, ISO files, and other VM volumes. The pool does not replace host storage configuration — it points SimpleVM at storage you have already prepared (Section 5.6). Keeping VM disk images and installation media on dedicated pools on the data volume is what keeps them off the operating system disk.

Figure 5-4. The Storage pools page (reached from Virtual machines), showing the  default  and  isos  pools expanded. Each is active, persistent, set to autostart, and of type  dir .
Figure 5-4. The Storage pools page (reached from Virtual machines), showing the default and isos pools expanded. Each is active, persistent, set to autostart, and of type dir .

On a correctly prepared SimpleVM 10.1 host, the Storage pools page confirms two pools, both ready for use before you create VMs:

PoolTarget pathPersistentAutostartTypeState
default/data/imagesyesyesdiractive
isos/data/isosyesyesdiractive

The default pool holds VM disk images; the isos pool holds installation media. Keep them separate. The page also shows each pool's capacity — in the reference build, 259.42 / 3350.11 GiB on the data volume.

Procedure

  1. Under System, open Virtual machines.
  2. Open Storage pools (the summary card at the top of the page links to it; the breadcrumb is Virtual machines > Storage pools).
  3. Confirm the expected pools are listed — default and isos.
  4. Expand each pool and review its Target path. The default pool should target /data/images; the isos pool should target /data/isos.
  5. Confirm each pool is active, Persistent, and set to Autostart.
  6. Confirm available capacity matches the prepared data volume.

If a pool must be created or checked from the command line, use the following as a support reference. Replace the pool name and path as needed:

virsh pool-list --all # active and inactive pools virsh pool-info <pool> # state, capacity, allocation # Create a directory-based pool on a prepared mount: sudo virsh pool-define-as <pool> dir --target <path> sudo virsh pool-build <pool> sudo virsh pool-start <pool> sudo virsh pool-autostart <pool>

Verification

The required pools are active and show the expected target paths on the data volume. A pool intended for production VM disks should not point to an operating system location unless your deployment specifically uses that layout. Storage pools are covered in full in Chapter 12, Managing Storage Pools; uploading installation media to the ISO pool is covered there and in Chapter 19, Host Administration Tools.

5.8 Review Host Networking

Overview

Host networking affects management access, VM connectivity, updates, DNS resolution, migration, clustering, and support. Review it now, while the deployment is still simple, so that any mistake is corrected before workloads depend on it. The Networking page (under System) shows transmit and receive activity, the firewall status, the host's network interfaces, and a network log.

Figure 5-5. The Networking page: transmit/receive graphs, the Firewall status with its active-zones link and Edit rules and zones button, and the interface list with Add VPN, Add bond, Add bridge, and Add VLAN actions.
Figure 5-5. The Networking page: transmit/receive graphs, the Firewall status with its active-zones link and Edit rules and zones button, and the interface list with Add VPN, Add bond, Add bridge, and Add VLAN actions.

In the reference build, the interface list shows host bridge networking in use:

InterfaceIP addressRole
bridge010.0.0.142/24Host bridge carrying management traffic
eno110.0.0.52/24Physical interface on the management subnet
enp2s0f0, enp2s0f1Not availableAdd-in card ports, not currently connected
virbr0192.168.122.1/24Default NAT virtual network for VMs

Procedure

  1. Under System, open Networking.
  2. Review the active interfaces and confirm the management IP address you used to reach the host.
  3. Confirm the expected interface or bridge is active. In the reference build, host management is carried on bridge0.
  4. Review the transmit and receive graphs for any unexpected activity on an otherwise idle host.
  5. Confirm the firewall is Enabled unless an approved support procedure says otherwise (reviewed in detail in Section 5.9).

Verification

Your management workstation can reach the host by its planned name or address, and the host shows the expected management network and any expected bridge or virtual networking. Because the reference host is addressed on both bridge0 and eno1, treat the management address as “the URL shown on the host console” or the management-network address rather than a single canonical IP. The following read-only commands confirm the host's networking from the terminal:

hostnamectl # host name, operating system, and kernel ip addr # assigned network addresses ip route # routing table and default gateway

Host networking — interface configuration, bridges, DNS, and host name — is covered in full in Chapter 15, Managing Host Networking.

5.9 Review Firewall Zones and Services

Overview

SimpleVM ships with a zone-based host firewall, enabled and configured for normal operation. The purpose of this review is to confirm the firewall is on and that the right services are allowed in the right zones — not to turn anything off. Keep the firewall enabled; the point of firewall documentation is to confirm required communication works, not to teach turning it off.

Figure 5-6. The Firewall detail page, reached from Networking with Edit rules and zones. It shows the Public, Cluster, and Libvirt zones with their allowed services.
Figure 5-6. The Firewall detail page, reached from Networking with Edit rules and zones. It shows the Public, Cluster, and Libvirt zones with their allowed services.

The page header reads “Incoming requests are blocked by default. Outgoing requests are not blocked.” On a SimpleVM 10.1 host, three zones are confirmed:

ZoneAssigned toAllowed services
PublicInterfaces bridge0, eno1, eno2; entire subnetdhcpv6-client (UDP 546), cockpit (TCP 9090 — the web console)
ClusterPeer host 10.0.0.54ssh (TCP 22), qemu-nbd (TCP 49152–49215)
LibvirtInterface virbr0; entire subnetdhcp (UDP 67), dns and related VM-network services

The Public zone keeps the web console reachable on port 9090. The Cluster zone is restricted to a known peer host and allows exactly the services live VM migration needs; the Libvirt zone serves the VM network. The cluster zone's services are described further in Chapter 22, Configuring Host Clusters for Live VM Migration and High Availability.

Procedure

  1. Under System, open Networking.
  2. In the Firewall section, confirm the firewall is Enabled, then select Edit rules and zones to open the zone detail page.
  3. Review the Public, Cluster, and Libvirt zones and the services allowed in each.
  4. Do not remove a service from a zone unless you understand what it supports. Removing cockpit from the Public zone, for example, can lock you out of the web console.
  5. If a change is genuinely required, record the previous state first, then make the smallest change — open only the service needed, only in the required zone, only for the source that needs it.

Verification

After reviewing — or changing — firewall settings, confirm the web console is still reachable, VM networking still works, and any required cluster or migration services remain allowed. The following read-only commands report the firewall state from the terminal:

firewall-cmd --get-active-zones # zones and their interfaces/sources firewall-cmd --list-all # services and ports for the default zone

Firewall and security settings are covered in full in Chapter 16, Firewall and Security Settings.

5.10 Review SELinux Status

Overview

SELinux is part of the SimpleVM host's security posture. The purpose of this step is to review the current SELinux state — not to disable it. If SELinux ever blocks a required workflow, investigate the specific denial, file context, or label rather than turning SELinux off as a general fix. Because SimpleVM uses RHEL-family security behavior, labeling matters when VM disk images live outside the default virtualization directory: if a storage path is not labeled appropriately, virtual machines may fail to start or be unable to access their disks.

Figure 5-7. The SimpleVM web terminal, used here for read-only SELinux checks. The prompt  [svmadmin@tw-rnd1 /]$  confirms the terminal opens as the signed-in administrative user, not as  root ; commands that change the system are run with  sudo .
Figure 5-7. The SimpleVM web terminal, used here for read-only SELinux checks. The prompt [svmadmin@tw-rnd1 /]$ confirms the terminal opens as the signed-in administrative user, not as root ; commands that change the system are run with sudo .

Procedure

  1. Under Tools, open SELinux and review the current status and mode.
  2. For a command-line check, open Terminal (under Tools) and run the following read-only commands:

getenforce # current SELinux mode (e.g. Enforcing) sestatus # detailed SELinux status

  1. Confirm the mode matches your approved SimpleVM security baseline. If it does not, record the finding and resolve it before treating the host as production-ready.

Optional support reference — storage labeling. If SimpleVM support directs you to label the VM storage paths, the example below applies the virt_image_t context commonly used for libvirt image storage. Run it only when directed:

sudo semanage fcontext -a -t virt_image_t "/data/images(/.)?" sudo semanage fcontext -a -t virt_image_t "/data/isos(/.)?" sudo restorecon -Rv /data/images /data/isos

Then confirm the label and the pool state:

ls -Zd /data/images /data/isos # SELinux context on the storage paths sudo virsh pool-info <pool> # the pool should be active

The directories should show a context appropriate for virtual machine storage, and the storage pool should be active.

Verification

SELinux is in the mode your SimpleVM baseline expects, and the VM storage paths carry an appropriate label. If a workflow is blocked, the denial — not a disabled SELinux — is what you investigate. The web terminal and command-line access are covered in Chapter 19, Host Administration Tools; broader security guidance is in Chapter 16, Firewall and Security Settings.

5.11 Review Update Status

Overview

Before placing workloads on the host, review its software update status. Applying updates can require a reboot, and on a virtualization host a reboot affects every local VM — so it is far easier to handle updates now, before production VMs exist, than to schedule a maintenance window around them later. The Software updates page (under Tools) shows the current state, a settings area, and an update history.

Figure 5-8. The Software updates page: a Status card (current state and last-checked time), a Settings card (automatic updates and kernel live patching), and an Update history card with dated entries.
Figure 5-8. The Software updates page: a Status card (current state and last-checked time), a Settings card (automatic updates and kernel live patching), and an Update history card with dated entries.

Procedure

  1. Under Tools, open Software updates.
  2. In the Status card, review the current state (for example, “System is up to date”) and the last-checked time; refresh if needed.
  3. Review the Update history card and the Settings card. Automatic updates show as “Not set up” and kernel live patching as “Not installed” on a fresh host.
  4. If updates are available, plan to apply them before creating production VMs, and reboot only when required and only during an approved maintenance window.

5.12 Post-Installation Readiness Checklist

Complete this checklist before creating production virtual machines. Each item maps to a section above; the notes column is for recording the result of your review.

AreaReady stateSection
Host consoleManagement URL visible and host login prompt available5.2
Management interfaceBrowser access works and the administrator can sign in5.2–5.3
Administrative accessSigned in as the intended admin; can elevate when needed5.4
Host overviewHealth, CPU, memory, host name, and system time reviewed5.3
Data storageData volume identified, formatted if needed, mounted, and persistent5.5–5.6
Storage poolsVM image and ISO pools active, persistent, autostart enabled5.7
NetworkingManagement IP, interfaces, and expected bridge/network reviewed5.8
FirewallFirewall enabled; required zones and services reviewed5.9
SELinuxStatus reviewed against the approved SimpleVM baseline5.10
UpdatesUpdate status reviewed before production VM creation5.11
Documentation notesand items recorded for follow-up

Next steps. With the host verified as ready, continue to Chapter 6, Accessing the SimpleVM Management Interface, for day-to-day sign-in, and Chapter 8, Creating and Managing Virtual Machines, to create your first workload.

Revert this change

Most steps in this chapter are review-only. The ones that change the host — preparing storage, and any firewall or SELinux adjustments — are reversible only where a safe recovery path exists. Treat each accordingly.

Storage preparation

  • If you selected the wrong disk, stop immediately and do not create VMs on the host.
  • If data was overwritten, the safe recovery path is to restore from backup or to reinstall — there is no in-place undo for an overwritten disk.
  • If you created only a mount point or directory, unmount and remove it only after confirming no VM data is stored there.

Storage pool changes

  • Confirm no VM is using the pool.
  • Deactivate the pool from Storage pools if needed.
  • Delete only the pool definition if the stored VM volumes must be preserved — removing a directory-based pool definition does not erase the files in its path.
  • Delete stored volumes only when you are certain the VM data is no longer needed. Formatting or deleting the underlying partition is a separate, destructive action.

If the mounted data filesystem itself must be removed, first back up or move any needed VM data, then unmount it and remove its automatic mount entry only after confirming the path is no longer in use:

findmnt /data # confirm what is mounted before changing anything sudo umount /data

Firewall changes

  • Restore the previous zone assignment or service list you recorded before the change.
  • Confirm the web console remains reachable.
  • Confirm VM networking still works after the change.

SELinux changes

  • Return SELinux to the approved SimpleVM mode.
  • Restore changed file contexts where applicable (for example, with restorecon).
  • Re-test the blocked workflow rather than leaving SELinux weakened.

Troubleshooting

The table below covers the issues most often seen during post-installation configuration. For symptom-by-symptom guidance across the whole product, see Chapter 25, Troubleshooting.

SymptomFirst checks
The browser cannot reach the management interfaceConfirm the URL matches the host console, includes https:// and the:9090 port, and is reachable from the workstation. Verify host networking and firewall status from the console if needed. See Section 25.3, Login and Access Issues.
The data disk does not appearConfirm the RAID controller or storage controller presents the disk to the operating system. If the disk was added after installation, rescan or reboot per the hardware vendor's procedure.
The wrong disk appears selectedDevice names can differ from your notes. Compare disk size, model, controller mapping, and existing partitions before formatting.
The storage pool is inactiveThe target path may not exist, may not be mounted, or may have wrong permissions. Verify the mount with findmnt and check directory permissions. Do not create VMs on an inactive pool.
The storage pool points to the wrong locationDo not create VM disks in that pool. Correct the pool's target path after confirming the approved storage layout.
A VM cannot start after using the new poolSELinux labeling or permissions may block access to the disk image. Check the directory label with ls -Zd and reapply the storage label if needed (Section 5.10).
The pool disappears after a restartThe pool or filesystem may not be set to start or mount automatically. Confirm mount-at-boot and pool autostart.
The ISO is not available during VM creationConfirm the ISO was placed in the ISO storage location and that the isos pool is active.
A firewall or SELinux setting blocks a workflowIdentify the specific blocked service, port, file context, or policy. Do not disable the firewall or SELinux as a permanent workaround.