Getting the VirtFusion system requirements right before installation saves you from rebuilding servers later. VirtFusion splits into a control server (the web panel, database and API) and one or more hypervisors (the KVM nodes that run customer VPSs), and each has its own needs.
Before you start
- Decide how many hypervisors you expect in the first year and roughly how many VPSs each will host.
- Have a valid VirtFusion licence; the licence type limits how many hypervisors you can add.
- Check the official VirtFusion documentation for the current list of supported operating systems, because it changes between releases.
Control server requirements
The control server does not run virtual machines, so it can be small. It should be a dedicated VPS or server used only for VirtFusion.
- OS: a fresh, minimal install of a supported Linux release with nothing else installed (no cPanel, no web server).
- CPU and RAM: 2 vCPU and 2–4 GB RAM is a sensible starting point; add more as the number of servers and API calls grows.
- Disk: 20–40 GB of fast SSD or NVMe for the OS, database and logs.
- Network: a public IPv4 address and a hostname (FQDN) with a DNS A record, so you can issue an SSL certificate for the panel.
Tip: Never host the control server on one of your own hypervisors. If that node fails you lose the panel you need to fix it.
Hypervisor requirements
- CPU: 64-bit with hardware virtualisation (Intel VT-x or AMD-V) enabled in the BIOS. Verify with
egrep -c '(vmx|svm)' /proc/cpuinfo; the result must be greater than 0. - RAM: enough for all planned VPSs plus 2–4 GB for the host. Overselling RAM on KVM causes swapping and slow customers.
- Storage: separate disks for VPS storage are recommended. Choose local file storage, LVM or ZFS before installing; see VirtFusion storage options.
- OS: a fresh, minimal supported Linux release on bare metal (nested virtualisation is fine for testing only).
- Out-of-band access: IPMI, iDRAC or iLO, because bridge changes can cut SSH.
Network and IP planning
- Reserve the main server IP for the hypervisor itself.
- Get one or more IPv4 blocks routed to each hypervisor for customer VPSs, plus an IPv6 /64 or larger if you want to offer IPv6.
- Plan the bridge name (commonly
br0) and keep it the same on every node to simplify configuration. - Open the ports VirtFusion needs between the control server and hypervisors (SSH and the ports listed in the documentation), and allow your admins to reach the panel on HTTPS.
Sizing example
| Role | Small setup | Growing setup |
|---|---|---|
| Control server | 2 vCPU, 2 GB RAM, 30 GB SSD | 4 vCPU, 8 GB RAM, 80 GB NVMe |
| Hypervisor | 8 cores, 64 GB RAM, 2× NVMe | 32+ cores, 256 GB+ RAM, NVMe RAID or ZFS |
Troubleshooting
- Virtualisation not detected: enable VT-x/AMD-V (and VT-d if needed) in the BIOS, then reboot.
- Installer refuses the OS: reinstall with a supported release; do not try to force it.
- Panel unreachable after install: check the firewall and that the hostname resolves to the server IP.
Frequently asked questions
Can the control server run on a VPS?
Yes. A small, dedicated VPS is a common choice, as long as it is not hosted on your own VirtFusion hypervisors.
Do I need hardware RAID on hypervisors?
Not strictly, but you need some redundancy: hardware RAID, mdadm or a ZFS mirror protects customers from a single disk failure.
Can I mix Intel and AMD hypervisors?
Yes, but live migration between different CPU vendors is not reliable, so group similar hardware together.