CHAPTER 03

System Requirements and Planning

10 sections · 17 min read · SimpleVM 10.1

SimpleVM installs as a ready-to-use virtualization environment, but the quality of a deployment still depends on the hardware and network it runs on. Planning before installation is what separates a host that quietly does its job for years from one that runs out of memory, storage, or network capacity the first time real workloads arrive.

This chapter covers the decisions to make before you install: how to size processor, memory, storage, and networking; how to name and time-synchronize a host; and how single-host, multi-host, and clustered deployments differ. None of these steps changes the host — installation begins in Chapter 4, Installing SimpleVM — so this chapter has no procedures to revert. Treat it as the worksheet you complete before the installation media is even prepared.

One principle runs through every section: size for the virtual machines you will run and the growth you expect, not just for the operating system install.

3.1 Hardware Requirements

A SimpleVM host is a physical server, so plan it like one — with the difference that its resources are shared across every virtual machine it runs. Four resource areas determine how many virtual machines a host can run and how well they perform: processor (CPU), memory, storage, and networking. The sections that follow cover each in turn; this section frames how they fit together.

Plan around the workload, not the installer. SimpleVM itself is lightweight. It installs a minimal, hardened host with the virtualization components already configured, so almost all of a host’s resources are available to virtual machines. The size of the host should therefore be driven by the combined demands of the virtual machines it will run, plus headroom for the host and for growth.

Plan for the host’s service life. Adding memory or storage to a running host usually means downtime for the virtual machines on it, so it is common to provision more capacity than day-one workloads require. Decide how long the host should serve and how much the workload is likely to grow, then size for that horizon.

3.2 CPU and Virtualization Requirements

SimpleVM runs virtual machines using the host processor’s hardware virtualization features. The processor must be a 64-bit CPU with hardware-assisted virtualization — Intel VT-x or AMD-V — and that feature must be enabled in the system firmware (BIOS or UEFI). Without it, the host cannot start virtual machines.

Cores and virtual CPUs. Each virtual machine is assigned one or more virtual CPUs, which the host schedules onto its physical cores. A host can present more total virtual CPUs than it has physical cores, because not every virtual machine is busy at once, but heavy oversubscription causes virtual machines to compete for processor time. Plan core count around the combined virtual CPUs of the virtual machines you expect to run at the same time, plus overhead for the host itself.

Enable virtualization in firmware first. Hardware-assisted virtualization is set in the server’s BIOS or UEFI setup, usually under a name such as Intel Virtualization Technology, VT-x, or AMD-V / SVM Mode. Enable it before installing SimpleVM. Because firmware menus differ by server vendor, consult the server’s hardware documentation for the exact menu location.

Confirming virtualization support after installation. Once SimpleVM is installed, you can confirm the processor reports the required extensions from the web terminal or over SSH. A non-empty result from the following command means the CPU exposes hardware virtualization:

grep -E 'vmx│svm' /proc/cpuinfo

A vmx result indicates Intel VT-x; an svm result indicates AMD-V. The web terminal is covered in Chapter 19, Host Administration Tools.

Plan compatible processors for clusters. In a cluster, live migration moves a running virtual machine between hosts, so the hosts’ processors must be compatible. Plan clustered hosts with the same or closely compatible CPUs to avoid migration restrictions. See Section 3.9, Planning for Clustering and High Availability, and Chapter 21, VM Migration.

3.3 Memory Planning

Memory is often the first resource a virtualization host runs out of, so plan it deliberately. The memory a host needs is the sum of the memory assigned to all of its virtual machines, plus memory for the SimpleVM host itself, plus headroom.

Always leave host headroom. Do not plan at full allocation. A host whose memory is fully committed to virtual machines has nothing left for its own operation, for short-term spikes, or for starting an additional virtual machine in an emergency. A simple approach is to list each planned virtual machine and its memory, add them together, add an allowance for the host and for headroom, and size the host at or above that total.

Treat memory overcommitment as a deliberate exception. A host can assign more total memory to virtual machines than it physically has, relying on the fact that virtual machines rarely use all of their assigned memory at once. This can raise virtual machine density, but it risks severe performance loss — or virtual machines failing to start — if real demand exceeds physical memory. For production hosts, plan around physical memory and treat overcommitment as a monitored exception rather than a default. Monitoring host memory is covered in Chapter 23, Monitoring Your SimpleVM Host.

Size for failover in a cluster. In a clustered or high-availability deployment, size memory so that, if a host becomes unavailable, the remaining hosts have enough free memory to run the affected virtual machines. A cluster in which every host runs near full memory cannot absorb a failure. See Section 3.9, Planning for Clustering and High Availability.

3.4 Storage Planning

SimpleVM stores virtual machine disks and installation media in storage pools — managed storage locations the host presents to virtual machines. Plan storage around three questions: how much capacity the virtual machines and their media need, where that storage lives relative to the operating system, and whether the deployment needs shared storage for migration or high availability.

Separate the operating system from virtual machine and data storage. This is the single most important storage design decision. Wherever practical, install the SimpleVM operating system on one disk (or set of disks) and place virtual machine data on separate storage. Separation keeps the host operating system isolated from virtual machine I/O and capacity, makes the host easier to recover or reinstall without disturbing virtual machine data, and is assumed by several later chapters — post-installation configuration, storage, backup, migration, and clustering.

Reference layout (example). In the reference build, the operating system disk presents the standard boot partitions and a logical volume group for the host, while a separate data disk is mounted at /data and holds the storage pools. The default storage pools live under that data volume:

These default pools are created during installation and are active and persistent across reboots. Storage pools are covered in Chapter 12, Managing Storage Pools; host disks, partitions, and logical volumes are covered in Chapter 13, Managing Host Storage.

Use redundancy appropriate to the environment. The reference build places the operating system on a mirrored (RAID 1) disk and virtual machine data on a separate RAID 5 disk. The principle is the separation of operating system and data storage, together with disk redundancy suited to the environment — the specific RAID levels are environment-specific, not a SimpleVM requirement.

Identify disks by their characteristics, not their names. Device names such as /dev/sda and /dev/sdb vary by server and controller. When you plan and later prepare storage, identify the correct disk by its size, model, controller or RAID mapping, and existing partitions — never by device name alone. Preparing the data volume is covered in Chapter 5, Post-Installation Configuration (see Section 5.6, Prepare the Data Volume for Storage Pools).

Size capacity for disks, media, snapshots, and growth. Plan storage for the combined size of all virtual machine virtual disks, plus space for installation media in the ISO pool, plus room for snapshots and growth. Remember that snapshots consume additional space on the same storage as the virtual machine and are not a substitute for backups. Snapshots are covered in Chapter 11, VM Snapshots; backup planning in Chapter 20, Backup and Recovery.

Plan shared storage if you need migration or high availability. High availability requires shared storage reachable by every host in the cluster — for example NFS, iSCSI, Fibre Channel, or an equivalent — and shared storage is also the preferred foundation for live migration. If the deployment will use clustering or HA, design the shared storage backend as part of the hardware plan, not as an afterthought. See Section 3.9, Planning for Clustering and High Availability, Chapter 21, VM Migration, and Chapter 22, Configuring Host Clusters for Live VM Migration and High Availability (see Section 22.7, Shared Storage Requirements for High Availability).

3.5 Network Planning

A SimpleVM host needs reliable networking for two distinct purposes: management access, so administrators can reach the web console, and virtual machine traffic, so virtual machines can reach the networks they serve. Plan these so they do not compete, and so the management interface stays reachable and protected.

Plan a stable, protected management address. Administrators reach SimpleVM through the web console at https://<host>:9090 — the management URL shown on the host console after startup. Give each host a stable management address on a network administrators can reach but that is not exposed to untrusted networks. Do not place the management interface directly on the public internet; restrict it to trusted networks, a VPN, or a jump host. The firewall allows the web console on port 9090 by default; firewall planning is covered in Chapter 16, Firewall and Security Settings.

Choose how virtual machines connect. Virtual machines reach networks in two main ways:

• Bridged networking connects virtual machines directly to a physical network through a host bridge, so they appear as ordinary devices on that network. This is the usual choice for production virtual machines that other systems must reach. Host bridge networking is covered in Chapter 15, Managing Host Networking (see Section 15.5, Bridge Networking).
• The default NAT network provides an isolated, host-local network with its own DHCP range — useful for testing, or for virtual machines that do not need to be reached directly from the physical network. SimpleVM provides a default NAT network named default. See Chapter 14, Managing Virtual Networks (see Section 14.2, Default NAT Network).

Separate traffic where practical. On hosts with more than one network interface, plan to separate management traffic, virtual machine traffic, and — where used — storage and migration traffic. Separation improves both performance and security: a busy virtual machine or a storage transfer should not crowd out management access. The reference build uses host bridge networking and presents the host on more than one addressed interface.

Plan consistent networking for clusters. Clustered hosts need the same virtual networks on every host, so that a migrated virtual machine can reconnect on the destination, and they benefit from a reliable network for migration and cluster communication. Plan this as part of a multi-host design. See Section 3.8, Multi-Host Deployment Planning, and Section 3.9, Planning for Clustering and High Availability.

3.6 Hostname, DNS, and Time Synchronization Planning

Three host-identity settings are easy to overlook at install time but cause problems later if they are wrong: the hostname, DNS resolution, and time synchronization. Plan them before installation so the host is correct from first boot.

Hostname. Give each host a stable hostname, using a fully qualified domain name (FQDN) where DNS supports it. A correct, stable hostname matters for software updates, support, time services, migration, and clustering. Avoid renaming a host after it is in service, which can disrupt those services. The hostname is set during installation; see Chapter 4, Installing SimpleVM (see Section 4.5, Configuring Network and Hostname).

DNS. Plan working DNS resolution for the host. Correct DNS underpins updates, support connectivity, time synchronization, and — in multi-host deployments — the ability of hosts to resolve one another for migration and clustering. Reviewing and adjusting DNS and hostname settings after installation is covered in Chapter 15, Managing Host Networking (see Section 15.6, DNS and Hostname Settings).

Time synchronization. Accurate, synchronized time is essential. System time affects logs, certificates, authentication, software updates, clustering, and troubleshooting — and in a cluster, the hosts must agree on the time. Plan a reliable time source, such as an internal or organizational network time service, for every host, and ensure clustered hosts use consistent time synchronization.

3.7 Single-Host Deployment Planning

The simplest SimpleVM deployment is a single host: one physical server running SimpleVM, with local storage and the default networks. It is a good fit for smaller environments, branch or edge locations, test and development, and any workload that does not require moving running virtual machines between hosts.

Plan a single host around the items already covered:

• One server sized for its workloads, following Section 3.1 through Section 3.5.
• Local storage, with the operating system kept separate from virtual machine and data storage (see Section 3.4, Storage Planning).
• A stable management address, hostname, DNS, and time source (see Section 3.5 and Section 3.6).
• A backup strategy — required even for a single host.

Plan for what a single host cannot do. A single host cannot provide live migration or high availability, because both require at least one additional host and — for HA — shared storage. If you expect to need those capabilities later, consider designing toward a multi-host deployment now (for example, by choosing compatible hardware and planning for shared storage) so the move is straightforward. See Section 3.8, Multi-Host Deployment Planning.

After installation, complete the readiness checks before running workloads. See Chapter 5, Post-Installation Configuration (see Section 5.12, Post-Installation Readiness Checklist).

3.8 Multi-Host Deployment Planning

A multi-host deployment runs SimpleVM on two or more servers. Multiple hosts allow workloads to be distributed, allow virtual machines to be moved between hosts for maintenance or balancing, and — with shared storage — make high availability possible.

Beyond sizing each host individually, a multi-host deployment adds requirements that tie the hosts together:

• Consistent networking across hosts. The same virtual networks should exist on every host so a moved virtual machine can reconnect on the destination. See Section 3.5, Network Planning.
• Shared storage for high availability. HA requires storage reachable by every participating host (NFS, iSCSI, Fibre Channel, or equivalent). Live migration is also far simpler with shared storage. See Section 3.4, Storage Planning.
• Consistent DNS and time. Hosts must resolve one another and agree on the time. See Section 3.6, Hostname, DNS, and Time Synchronization Planning.
• CPU compatibility for live migration. Hosts that will exchange running virtual machines should have the same or closely compatible processors. See Section 3.2, CPU and Virtualization Requirements.
• Failover capacity. If the deployment must tolerate a host failure, the remaining hosts need enough free CPU and memory to run the affected virtual machines. See Section 3.3, Memory Planning.

Plan the networks up front. A multi-host deployment is easier to operate when the management network and a reliable network for migration and cluster communication are planned from the start, rather than retrofitted later.

Migration and clustering are different things. Moving a virtual machine between two standalone hosts is VM migration, covered in Chapter 21, VM Migration. Joining hosts so they coordinate live migration and high availability is clustering, covered in Chapter 22, Configuring Host Clusters for Live VM Migration and High Availability. The next section explains the difference and what clustering requires.

3.9 Planning for Clustering and High Availability

Clustering joins multiple SimpleVM hosts so they can coordinate live VM migration and high availability. This section covers the planning decisions; the full configuration procedure is in Chapter 22, Configuring Host Clusters for Live VM Migration and High Availability, which is the authoritative reference for clustering, live migration, and high availability.

Live migration and high availability are related but distinct.

• Live migration moves a running virtual machine from one host to another with minimal interruption — used for maintenance, hardware replacement, and load balancing.
• High availability (HA) keeps workloads recoverable when a host becomes unavailable — if a host fails, its virtual machines can be brought back up on another host.

A deployment can use live migration without full HA, but HA depends on the shared-storage and clustering foundation described here.

Shared storage is required for HA. High availability requires shared storage reachable by every host in the cluster (NFS, iSCSI, Fibre Channel, or equivalent). Plan it as a core part of the design — without it, a failed host’s virtual machines cannot be restarted elsewhere. See Section 3.4, Storage Planning, and Section 22.7, Shared Storage Requirements for High Availability.

Choose a cluster size for the resilience you need.

• A two-node cluster provides simple redundancy — one host can take over for the other.
• A three-or-more-node cluster provides better resilience and more stable quorum (the cluster’s ability to agree on which hosts are active and avoid split decisions).

Choose the size based on how much failure the deployment must tolerate and on the failover capacity of the remaining hosts.

Size every host for failover. Plan the cluster so that, if one host is lost, the remaining hosts can run the affected workloads. Provide CPU and memory headroom on every host accordingly (see Section 3.3, Memory Planning).

Plan cluster networking and firewall access. Clustered hosts communicate over the network and require specific firewall access between the cluster members. SimpleVM provides a dedicated cluster firewall zone for this purpose, restricted to the addresses of the peer hosts rather than open to the whole network. In the reference build, the cluster zone allows the services shown below:

Restricting these services to known peer-host addresses keeps cluster communication off untrusted networks. Firewall zones are covered in Chapter 16, Firewall and Security Settings (see Section 16.5, Cluster Firewall Requirements), and the full cluster firewall procedure is in Chapter 22.

3.10 Production Deployment Considerations

Before a SimpleVM host carries production workloads, confirm that the deployment has been planned for protection, security, access, maintenance, and monitoring — not just for capacity. This section collects the planning items that turn a working host into a production-ready one. Most are detailed in later chapters; the goal here is to make sure none is overlooked.

Pre-deployment planning checklist.

• Capacity. CPU, memory, storage, and networking sized for the workloads and for growth (Section 3.1 through Section 3.5).
• Storage separation and redundancy. Operating system kept separate from virtual machine and data storage, with redundancy appropriate to the environment, and shared storage planned if HA is required (Section 3.4, Storage Planning).
• Host identity. Stable hostname, working DNS, and reliable time synchronization (Section 3.6, Hostname, DNS, and Time Synchronization Planning).
• Backup strategy. A backup plan for important virtual machines — required even for a single host, because snapshots and migration are not backups (Chapter 20, Backup and Recovery).
• Firewall and security. Firewall left enabled, with required services confirmed, and the management interface restricted to trusted networks (Chapter 16, Firewall and Security Settings).
• User access. Administrative accounts and access reviewed and limited to who needs them (Chapter 17, User Access and Administrative Tasks).
• Updates and maintenance. A plan for applying software updates and scheduling any required reboots (Chapter 18, Software Updates).
• Monitoring. Host and virtual machine monitoring in place so capacity and health problems are caught early (Chapter 23, Monitoring Your SimpleVM Host).
• High availability (if required). Cluster size, shared storage, networking, and failover capacity planned (Section 3.9, Planning for Clustering and High Availability).
• Documentation. The deployment recorded: hosts, addresses, storage layout, networks, and the purpose and resources of each virtual machine.

Keep the security defaults in place. Plan to keep the firewall enabled and SELinux in enforcing mode. These are part of SimpleVM’s security posture, and disabling them is not a supported way to resolve a problem. Where a security setting blocks a workflow, the correct approach is to adjust it deliberately, not to turn it off. Security is covered in Chapter 16, Firewall and Security Settings.

Planning continues after installation. Once the host is installed, complete the post-installation readiness checks — storage preparation, storage pools, host networking, firewall, and SELinux — before creating production virtual machines. See Chapter 5, Post-Installation Configuration (see Section 5.12, Post-Installation Readiness Checklist). If a problem appears during or after deployment, Chapter 25, Troubleshooting, provides a standalone troubleshooting reference.