CHAPTER 13
Managing Host Storage
This chapter explains how to work with host storage — the physical and operating-system-level storage that supports the SimpleVM host itself. Host storage includes the local disks and hardware RAID virtual disks presented to the host, the partitions and filesystems on them, the directories where those filesystems are mounted, and any logical volumes managed by LVM. The single most useful idea in this chapter is the boundary between two layers. Host storage is the foundation: the host owns the disks, partitions, filesystems, mount points, and capacity. A storage pool, by contrast, is only the VM-facing window onto a prepared host location, and it is covered separately in Chapter 12, Managing Storage Pools. Keeping that boundary clear is what makes every storage change deliberate and reversible.
Most of what you do here is read-first. You open the Storage page to answer practical questions — which disks are attached, how they are divided, where data lives, and whether activity or capacity is becoming a problem — long before you change anything. The web console deliberately keeps host storage at arm’s length: the destructive actions live behind per-row menus, not front-and-center buttons, because formatting, deleting, resizing, or unmounting the wrong target can take down the host or every VM that depends on it.
Cross-reference: For signing in to the management interface, see Section 6.5, Sign In with Administrative Access. For the VM-facing storage pools that sit on top of host storage, see Chapter 12, Managing Storage Pools. For the VM disks that ultimately consume this storage, see Chapter 9, Managing VM Disks. For the storage design behind the OS-and-data layout described here, see Section 3.4, Storage Planning. For ongoing capacity and activity monitoring across the host, see Section 23.4, Storage Monitoring. For end-to-end storage diagnosis, see Section 25.5, Storage Issues. For the command-line tools mentioned in this chapter and where to run them, see Section 26.4, Common Storage Commands, and Chapter 19, Host Administration Tools.
This chapter at a glance. The sections below move from understanding the storage layout to watching it and maintaining it:
- Understand the layout — what host storage is, and how to read the disks, partitions, and logical volumes the host presents (Sections 13.1 through 13.3).
- Watch activity — how to read the read/write graphs and what their patterns suggest (Section 13.4).
- Diagnose and maintain — how to trace a storage bottleneck to its source, and how to plan and verify host storage maintenance safely (Sections 13.5 and 13.6).
13.1 Host Storage Overview
Overview
The SimpleVM host storage view exists to help you answer three practical questions before you ever change anything: Which disks are attached to the host? How is each disk divided into partitions, filesystems, and logical volumes? And is storage activity or capacity becoming a problem for the host or for VM workloads?
In a production deployment, the most important design principle is to separate the operating system from the primary VM and data storage wherever practical. A common pattern installs the SimpleVM operating system on one protected disk or RAID volume and places VM disk images, ISO files, and other operational data on a separate data disk or RAID volume. The exact RAID levels and disk sizes depend on the server and the business requirement; the principle of separating OS storage from data storage is what matters, because it keeps maintenance, capacity planning, and recovery clear. This same principle recurs across planning, storage pools, backup, and clustering — see Section 3.4, Storage Planning.
Common host storage objects. The Storage table mixes several kinds of object. Knowing which is which is the whole skill of reading the page:
| Object | What it means | Why it matters |
|---|---|---|
| Disk | A physical drive, a hardware RAID virtual disk, or another block device presented to the host — for example, sda on a DELL PERC H730 controller. | Disks provide the raw capacity the host has to work with. Identify them by model and size, not by name. |
| Partition | A defined section of a disk, such as an EFI system partition, a boot partition, or an LVM physical volume — for example, sda1, sda2, sda3. | Partitions show how a disk is divided and what each section is used for. |
| Filesystem | A formatted area mounted at a path such as /, /boot, /boot/efi, or /data. On the reference build these are xfs and vfat. | Filesystems are where the host and applications actually read and write files. |
| Logical volume | A flexible volume carved from an LVM volume group rather than mapped to one fixed partition — for example, root and home inside group rl. | Logical volumes make allocation and resizing more flexible than fixed partitions. |
| Mount point | The directory path where a filesystem is attached to the operating system — /, /home, /data, and so on. | The mount point tells you where data actually lives, which is what you trace during troubleshooting. |
Verification
- The Storage page opens and lists the expected OS disk or RAID virtual disk.
- Any separate data disk or storage volume appears with the expected capacity.
- The operating-system mount points (/, /boot, /boot/efi) and any data mount point such as /data are visible where applicable.
- The layout matches the deployment plan from Section 3.4, Storage Planning.
13.2 Viewing Disks and Partitions
Overview
Use the Storage page to review the disks and partitions SimpleVM can see. This is the read-first habit that everything else in the chapter depends on: before you touch anything, identify each disk, its size, its partitions, its mount points, and whether it is already in use by the host or by VM storage. The most important rule is to identify a disk by its size, model, and controller mapping — never by device name alone. Device names such as /dev/sda and /dev/sdb are assigned by the server and controller and can change; the model string, capacity, and existing partition layout are what reliably tell you which physical disk you are looking at.
Before you begin
- Sign in to the SimpleVM management interface with an account that has administrative access. See Section 6.5, Sign In with Administrative Access.
- Decide whether you are only viewing storage or planning a change. Viewing is always safe; a change is not.
- If you are planning a change, confirm that backups are current and that no running VM or storage pool depends on the storage you intend to modify.
Procedure
- In the left navigation, under System, select Storage. The Storage page opens at /storage.
- Review the Reading and Writing activity graphs at the top of the page to get a sense of current disk activity. (Reading the graphs in detail is covered in Section 13.4, Storage Performance Graphs.)
- In the Storage table, identify each disk by its ID, model or controller description, Type, Location, and Size — for example, a 480 GB disk on a DELL PERC H730 controller showing GPT partitions.
- Expand a disk to view its partitions, filesystems, and any LVM physical volume it contains.
- For each filesystem, note the Location (mount point) and the capacity bar — for example, /boot/efi, /boot, or a data mount at /data.
- Record the mount point and usage for any filesystem that may hold VM disk images, ISO files, backups, or host operating-system data. This record is what you will trace against later if something goes wrong.
- Do not open the per-row action menu (the vertical-dots menu) for a disk or partition until you have confirmed its purpose. The actions behind it can be destructive.
Confirming the layout from the command line (optional). If you prefer to confirm the same layout outside the web console — or need detail the page does not show — open the host web terminal (see Chapter 19, Host Administration Tools) and use the read-only commands below. None of these change anything.
Verification
- Each disk you expect to see is present, identified by model and size rather than by device name.
- Partitions, filesystems, and any LVM physical volume appear under the correct disk.
- Mount points and usage match what you expect for the host OS and for VM storage.
13.3 Logical Volumes
Overview
A logical volume is a flexible storage volume managed by LVM (Logical Volume Manager). Instead of binding each filesystem to one fixed physical partition, LVM groups one or more physical volumes into a volume group and then allocates logical volumes from that group. This makes storage easier to organize and, where the design allows, easier to grow. It also means you should understand the relationship between physical disks, volume groups, and logical volumes before changing any of them.
How logical volumes appear in SimpleVM. On the Storage page, logical volumes are listed under their volume group. On the reference build the group is named rl and contains two logical volumes: root, mounted at /, and home, mounted at /home — both xfs. The physical volume that backs the group is the sda3 partition on the OS disk. A separate disk, sdb, is mounted directly at /data and is not part of the LVM group. Your group name, volume names, sizes, and mount points will differ; this layout is an example, not a fixed rule.
| LVM term | What it is on the reference build |
|---|---|
| Physical volume (PV) | A disk or partition handed to LVM — here, the sda3 partition (an LVM2 physical volume). |
| Volume group (VG) | A pool of one or more physical volumes — here, the group rl. |
| Logical volume (LV) | A volume allocated from the group and given a filesystem and mount point — here, root (/) and home (/home). |
Procedure: view logical volumes
- Open Storage from the left navigation under System.
- Find the LVM2 volume group in the Storage table — for example, rl.
- Expand the group to view the logical volumes inside it.
- For each logical volume, review the name, filesystem type, mount point (Location), used space, and total size.
- Compare the usage against expected host usage and against your VM storage locations, so you know which volumes are growing and why.
Changing logical volumes. Logical-volume changes — creating, formatting, mounting, extending, shrinking, or removing a volume — are administrative storage operations, not routine VM tasks. If a logical volume holds VM storage, changing it can affect storage pools and running virtual machines. Plan these changes for a maintenance window, with backups and a clear rollback path.
Verification
- Logical-volume names and mount points match the intended host storage design.
- Root- and boot-related storage have enough free space for updates, logs, and crash dumps.
- Data volumes used for VM storage have headroom for expected VM growth, snapshots, and ISO files.
- No unexpected or unidentified logical volume is consuming large amounts of space.
Revert this change
Viewing logical volumes changes nothing and needs no revert. If you did change a volume, the safe revert path depends on what you did:
- If you created a new, unused logical volume, you can remove it — but only after confirming it is not mounted and holds no needed data.
- If you mounted a filesystem at the wrong path, unmount it and correct the mount configuration before relying on it.
- If you formatted, deleted, or resized the wrong target, stop immediately. Do not continue writing to the affected storage. Preserve the current state and recover from backup, or engage support-guided recovery — these actions usually cannot be cleanly undone.
13.4 Storage Performance Graphs
Overview
The top of the Storage page shows two activity graphs: Reading and Writing, both in MiB/s. They let you see whether the host is actively reading from or writing to storage right now, and whether activity changes during VM startup, shutdown, backups, updates, or other maintenance. A time-range control sits above the graphs — a window selector (a 5-minute window by default), a zoom control, and step-back and step-forward arrows — so you can widen the view or move back in time.
Procedure: read the graphs
- Open Storage from the left navigation under System.
- Review the Reading graph for current and recent read activity (MiB/s).
- Review the Writing graph for current and recent write activity (MiB/s).
- Use the time-range control to widen the window or step back to a period of interest — for example, the window when a backup or update ran.
- Correlate what you see with known host or VM activity: a VM boot, a disk import, a backup job, a software update, or a large file transfer.
How to interpret what you see. Throughput patterns suggest a cause, but they rarely prove one. Use this table as a starting point, not a verdict:
| What you see | What it may mean |
|---|---|
| Brief read or write spikes | Normal activity during VM boot, file copy, package updates, backup scans, or storage maintenance. |
| Sustained high write activity | A VM, a backup process, a logging problem, or a write-heavy workload may be writing continuously. |
| High read activity while VMs feel slow | VMs may be waiting on storage reads — common during boot storms, antivirus scans, or large application loads. |
| Low graph activity but users report slow VMs | The bottleneck may be CPU, memory, network, guest-OS behavior, or storage latency that throughput alone does not show. |
| Activity on a disk you did not expect | A VM, storage pool, or file path may be using a different disk or mount point than intended. |
13.5 Identifying Storage Bottlenecks
Overview
A storage bottleneck occurs when capacity, throughput, latency, or device health keeps the host or its virtual machines from running normally. In SimpleVM, storage trouble usually shows up indirectly: slow VM boot times, sluggish applications, failed VM creation, stalled imports, delayed backups, or unexpected pauses during disk-heavy work. The goal of this section is to trace a symptom back to the specific disk, volume, or pool behind it before changing anything.
Before you begin
- Have the affected VM name or host task in hand, and the rough time the problem started.
- Confirm you can reach the Storage page and, if needed, the storage-pool and VM views.
- Resist the urge to free space by deleting files or reformatting until you have identified what each storage object holds.
Procedure: initial checks
- Open Storage and review the Reading and Writing graphs for the affected period.
- Check available capacity on the filesystems used by the host and by VM storage pools, using the per-row capacity bars.
- Confirm that VM disks are stored on the intended data volume or storage pool, not on the OS volume.
- Check whether the issue began during a known event — a backup, an update, a VM import, an ISO upload, or a large file copy.
- Determine the scope: is one VM affected, several VMs on the same storage location, or the entire host?
Common warning signs. Any one of these is worth investigating before it becomes an outage:
- A filesystem used for VM storage is nearly full.
- The host root filesystem (/) is low on free space.
- VMs on one disk are slow while VMs on another disk are fine.
- Read or write activity stays high for long stretches with no obvious workload behind it.
- A storage pool reports less capacity than the host disk or mount point it should be using — a sign the pool may be pointed at the wrong volume.
- A disk, RAID virtual disk, or mounted filesystem is missing from the Storage page.
Recommended troubleshooting path. Work from the symptom down to the hardware, narrowing scope at each step:
- Identify the affected VM or host task.
- Identify the storage pool or file path that workload uses. See Chapter 12, Managing Storage Pools.
- Identify the host disk, partition, filesystem, or logical volume behind that storage location, using the Storage page.
- Check available capacity and current activity on that storage device.
- If only one VM is affected, examine the VM disk, the guest operating system, and the workload before blaming host storage. See Chapter 9, Managing VM Disks.
- If several VMs on the same storage location are affected, investigate the shared storage device, the data volume, or the backing hardware.
- If the whole host is affected, review host logs, hardware health, RAID and controller status, memory pressure, and network impact before changing any storage configuration.
13.6 Host Storage Maintenance Tasks
Overview
Host storage maintenance should be planned, documented, and — when it changes anything — performed in a maintenance window with the host and VM workloads verified afterward. Some tasks are safe, read-only checks you can run any time. Others can affect the host, its storage pools, or running VMs. Knowing which is which is the point of this section.
Routine maintenance checklist (safe, read-first). These checks change nothing and are worth doing on a regular schedule:
- Review Storage page capacity for the OS, data, and VM storage locations.
- Confirm the data volume or VM storage location has enough free space for expected VM growth and snapshots.
- Check that ISO files, old imports, temporary files, and unused VM disk images are not quietly consuming space.
- Verify that storage pools still point to the intended host location after any change. See Chapter 12, Managing Storage Pools.
- Review the storage graphs during normal business activity and during maintenance windows to establish a baseline you can compare against later.
- Confirm backups are completing and that backup jobs are not filling local host storage. See Chapter 20, Backup and Recovery.
- Document any storage change: the disk, the mount point, the storage pool, the reason, and the verification result.
Before making a storage change. Run through this list before any change that is not read-only:
- Identify the exact disk, partition, logical volume, filesystem, or mount point you are about to change — by model, size, and mount point, not device name.
- Confirm whether any storage pool uses the target storage.
- Shut down, migrate, or pause affected workloads if the change requires it.
- Create or verify a backup of the affected VMs and host configuration where practical.
- Record the current state. Screenshots of the Storage page and the output of lsblk -f, lvs, vgs, and pvs make rollback and support review far easier.
- Plan how you will verify success — and how you will revert if it does not work.
Revert this change
The safest revert path depends on what the maintenance did:
- Read-only review: no revert needed.
- Mount-point or storage-pool path change: restore the previous path or pool configuration, then confirm VMs can reach their disks.
- New data volume added but unused: unmount and remove the configuration only after confirming no data was written to it.
- File cleanup: restore deleted files from backup if they turn out to have been needed.
- Formatting, repartitioning, or volume deletion: these usually cannot be cleanly reverted. Stop further writes immediately and recover from backup or support-guided recovery.
Troubleshooting
Use this table for quick triage. For end-to-end storage diagnosis across the host, see Section 25.5, Storage Issues.
| Symptom | What to check |
|---|---|
| A disk does not appear on the Storage page. | Confirm the disk or RAID virtual disk is healthy and visible to the server hardware first. A storage rescan or a host restart may be required, depending on the controller. |
| A data mount point is missing. | Check whether the filesystem is mounted and whether the mount configuration is correct. Do not recreate or format the disk unless you have confirmed the data is intentionally disposable. |
| The host root filesystem (/) is nearly full. | Identify large logs, temporary files, update caches, diagnostic bundles, or misplaced VM files. Move VM data to the intended data volume or storage pool. See Chapter 19, Host Administration Tools. |
| A storage pool shows less capacity than expected. | Compare the pool target path with the host mount point. The pool may be using the OS volume instead of the intended data volume. See Chapter 12, Managing Storage Pools. |
| Storage activity is high but no workload is obvious. | Check VM activity, backup jobs, updates, file transfers, log growth, and scheduled tasks. Use host logs and the command-line tools if the console view is not enough. |
| A storage change caused VM access problems. | Stop making changes, document the current state, and restore the previous path, mount, or pool configuration if known. Recover from backup if data was removed or overwritten. |
Chapter summary
Managing host storage is mostly about understanding the layout beneath SimpleVM before changing it. Use the Storage page to identify disks, partitions, filesystems, mount points, and logical volumes, and to read read/write activity. Identify disks by model and size rather than device name. Keep operating-system storage and VM data storage clearly separated wherever practical, watch free space and activity trends, and treat every destructive action — format, delete, resize, unmount — as a maintenance-window task backed by current backups and a documented recovery path. Host storage is the foundation; the storage pools in Chapter 12, Managing Storage Pools, and the VM disks in Chapter 9, Managing VM Disks, sit on top of it.