Planning guide for a virtualisation learning environment. Software evaluation terms, hardware support and local electricity costs require current verification.
Stuart Kerr Spindlow has confirmed personal use and testing of the software covered by Happy SysAdm. The assessments here distinguish documented behaviour from measured results; worked scenarios are labelled and are not personal test records.Choose a bounded learning objective
For learning a single mechanism, use the smallest repeatable lab that demonstrates it. A one-host lab is a good fit for guest configuration and restore practice; it cannot demonstrate survival of a physical host failure without another recovery destination. A multi-host lab is worth the extra complexity when quorum, migration or failover is the subject rather than merely a more impressive diagram.
Write down the experiment: deploying two test servers, observing a storage failure or practising a restore. List the smallest set of VMs and services needed. Avoid building a miniature enterprise before you know which concept you want to learn.
Estimate memory, CPU, storage capacity and sustained storage performance for concurrent workloads. Include host overhead, snapshots and backup copies. Leave headroom so resource starvation does not masquerade as the behaviour you are trying to study.
Design the isolation boundary
Use separate virtual networks and explicit routing rules. A lab DHCP server, directory service or test mail system must not accidentally serve the production or home network. Verify the boundary from both sides rather than trusting a network name.
Use fictional or sanitised data and distinct credentials. Do not import production backups into a casual lab without an approved data-handling process. Keep privileged management interfaces off the public internet and maintain a reliable local recovery path.
Keep the experiment inside an explicit boundary
- Home or production network
Existing clients and services must not receive accidental lab DHCP, directory or mail services.
- Controlled boundary
Separate virtual networks and explicit routing rules. Verify reachability from both sides.
- Lab networks and guests
Use distinct credentials and fictional or sanitised data; keep a local recovery path.
Keep privileged management interfaces off the public internet.
Check licensing and operating costs
Verify that the hypervisor, guest operating systems and applications may be used for the intended evaluation. Record expiry dates and any feature limits. An evaluation licence is not a permanent production entitlement.
Include power, noise, cooling and replacement storage in the budget. Used hardware may be inexpensive but unsupported or inefficient. Confirm compatible network and storage devices before assuming that a current hypervisor will install cleanly.
Make experiments repeatable
Keep a simple build recipe, configuration record and expected outcome. Take measurements with the workload and resource allocation noted. Label observations as lab results; they are not evidence that a production service will scale or recover identically.
Use backups for lab work you need to keep and disposable rebuilds for experiments you can recreate. Clean up unused VMs and credentials after each exercise. If a test breaks the environment, document the failure and rebuild rather than silently changing several variables at once.
A transparent memory budget
A hypothetical 32 GiB host reserving 8 GiB for the host and supporting services leaves 24 GiB for guests. Four guests configured at 4 GiB each require 16 GiB, leaving 8 GiB within that allocation. This is a declared planning scenario, not a vendor requirement or a measured working-set result.
Dynamic memory, cache demand and simultaneous workloads can change actual use. Avoid treating idle guests as evidence of usable peak capacity. Power cost requires a measured wall-power reading and the applicable tariff; a power-supply rating alone cannot support a claimed annual running cost.