Phase 1 — What it is, and how it fits together#

6 lessons · Level: beginner

This phase tells you what VirtFusion does, how it is arranged inside, and what each word means.

What is in this phase#

Lesson 1 — What VirtFusion is, and the problem it solves#

Bro, what is this? Ok so basically: KVM can already cut a server into VPS. What it cannot do is give your customers a panel, hand out IPs, count bandwidth, or talk to your billing system. VirtFusion is that missing layer. It sits on top of KVM. It is not a hypervisor itself.

In plain words#

You have a bare-metal server. You want to divide it into VPS and sell them.

You can do this with KVM alone. Then you must build everything yourself: the customer panel, IP allocation, OS templates, bandwidth accounting, the VNC console, and the billing connection.

VirtFusion gives you that layer. It is not a hypervisor itself. Plain Linux KVM runs below it, with libvirt and QEMU. VirtFusion sits on top and gives management, a panel, and an API.

What it gives you#

What it does not give you#

• It does not do the billing. Invoices, payment gateways, and tax belong

to a separate system. The one exception is the hourly credit in Self Service. See phase 6.

• It does not run containers. There is no LXC and no Docker, only full VMs.
• It does not configure network switches. VLANs and routing stay your work.

Lesson 2 — The control server and the hypervisor#

Bro, what is this? Ok so basically: VirtFusion comes in two pieces. The control server is the brain, and it runs zero VMs. The hypervisor is the muscle, the bare metal where customer VMs actually live. One control server per cluster, as many hypervisors as you want. Miss this split and nothing else in these docs makes sense.

In plain words#

VirtFusion installs in two parts. If you do not understand this division, the rest stays unclear.

The control server runs no VM. It only gives instructions. The hypervisor obeys the instructions and reports the result.

"One for each cluster" does not mean one for each region#

A cluster is one control server and every hypervisor it manages. The control server defines the cluster. Nothing about geography does.

So one control server can manage nodes in Singapore, Frankfurt, and Dallas at the same time. That is still one cluster, and one licence. You separate the locations with hypervisor groups, and the customer chooses a group at checkout.

You add a second control server only when you want a second, independent cluster — for latency you can measure, for failure isolation, or because a law says the data stays in one country. A second cluster is a second licence.

Note: Phase 5, lesson 5 covers the part that follows from this. If you do run more than one cluster, each one has its own base URL and its own API token, and your application must record which cluster each server belongs to.

How they talk to each other#

customer browser ──443──▶ control server
                               │
                               │ 8892 (HTTPS, both directions)
                               ▼
                       hypervisor 1 … n
                               │
customer browser ──5900+───────┘   (VNC console)

• The control server sends work to the hypervisor on port 8892.
• The hypervisor reports back on the same port. Open it in both directions.
• The VNC console goes from the customer browser straight to port 5900+

on the hypervisor.

Both on one machine?#

This works for a test, but it is not advised. With NAT it does not work at all, because the proxy ports collide. See phase 3, lesson 4.

Lesson 3 — The words you need#

Bro, what is this? Ok so basically: this is the vocabulary list. Do not memorise it. Just know it is here, because the next six phases use these exact words and each one means one specific thing.

KVM, hypervisor, VM — what is what#

These three words get thrown around like they mean the same thing. They do not, and mixing them up makes everything after this harder than it needs to be.

KVM is not a program you run. It is a module inside the Linux kernel that lets one physical CPU pretend to be many. It has shipped with Linux since

1. It is either available on a machine or it is not, and that comes down to

whether VT-x (Intel) or AMD-V (AMD) is switched on in the BIOS. No VT-x or AMD-V means no KVM, and no amount of configuration talks you out of that.

QEMU is the program that pretends to be the hardware — the disk, the network card, the screen. One QEMU process per VM. On its own QEMU is slow, because it emulates a CPU in software. Put it together with KVM and the guest runs its instructions on the real CPU at close to native speed. That pairing is what people mean when they say "KVM virtualization".

libvirt is the manager. It is the daemon that defines, starts, stops and inspects those QEMU processes, and virsh is its command line. When the control server is down and you SSH into a node to reboot a customer VM by hand, libvirt is what you are actually talking to.

A hypervisor is not software here. It is the machine. One bare-metal box running the kernel with KVM, plus QEMU, plus libvirt, plus the VirtFusion agent. In the panel, "Hypervisor" means exactly that: one physical node in your rack.

A VM is one guest. Its own kernel, its own operating system, its own IP, its own root password. VirtFusion calls it a Server. When you sell it, you call it a VPS. Three names, one object.

And VirtFusion is none of the above. It is the layer that tells the hypervisors what to do and gives your customers somewhere to press buttons. It runs no VM itself.

One more that catches people out: a container (LXC, Docker) is not a VM. A container shares the kernel of its host. A VM brings its own. VirtFusion runs VMs only. If you need containers, that is Proxmox, and phase 7 compares the two.

In plain words#

Every object in VirtFusion has one exact name. You do not have to learn this table, but come back to it. The other six phases use these words.

extRelationId — the most important idea here#

Put the user id from your own application, or from WHMCS, into VirtFusion as the extRelationId. Then you do not have to remember the internal VirtFusion user id. You can find the user with your own id:

GET /api/v1/users/{your-system-user-id}/byExtRelation

Rule: Do not keep the VirtFusion user id as the primary key in your own database. Between your id and the VirtFusion user, extRelationId is the only reliable link. If a user is deleted and made again, the internal id changes. Your id does not.

Lesson 4 — Licences and what they cost#

Bro, what is this? Ok so basically: one key covers the whole cluster and it is locked to the control server. But every hypervisor needs a tier that caps how many VMs it can run, and you can mix tiers. Unlimited on the big node, 5 on the little test box.

In plain words#

One licence covers one cluster. It is tied to the control server. However many hypervisors you have, you need only one key. But you must choose a tier for each hypervisor.

You can use different tiers together under one licence. For example, use Unlimited on a large node and 5 on a small test node.

Practical points#

• You can upgrade or downgrade at any time from the account portal, if no

invoice is unpaid.

• The licence locks to the control server. To move it to a new server you

must re-issue it, and the number of re-issues is limited.

• If you open more than one account with the same details, the accounts can be

cancelled automatically.

CAUTION: Keep NTP running on the control server. If its clock is more than 60 seconds away from real time, licence validation fails. Compare the time with chronyc or ntpdate.

Lesson 5 — The ports you must open#

Bro, what is this? Ok so basically: 80 and 443 into the control server, 8892 both directions to each hypervisor, and 5900+ for the consoles. The point is that UFW is already running on every hypervisor. That is the thing that quietly kills VM internet and makes you doubt your network.

The port list#

UFW is installed and running on the hypervisor by default. Remember this when you add rules.

CAUTION: If a VM has no internet but the host does, UFW is blocking the routed packets. This is the most common cause. Correct it on the hypervisor:

BASHকপি

ufw default allow routed

Common mistakes#

• Port 8892 is open in one direction only. The hypervisor never shows as

"commissioned".

• Ports 5900+ are blocked. The console shows a black screen.
• The IP of the control server changed and the hypervisor does not know. Every

call returns a 401 error. Phase 7, lesson 3 corrects this.

Lesson 6 — VirtFusion or Proxmox: a first look#

Bro, what is this? Ok so basically: both run KVM, so the question is not which one is stronger. It is what you are doing. Selling VPS to customers is VirtFusion. Running your own servers is Proxmox. That is the whole decision.

In plain words#

Both run KVM. The difference is the purpose.

In short: to sell VPS, use VirtFusion. To run your own servers, use Proxmox. The full comparison and the migration path are in phase 7.

At the end of phase 1 you can#

• Separate what VirtFusion gives you from what it does not
• Say what the control server does, and what the hypervisor does
• Give the meaning of each of the main words
• Explain how a licence is counted
• Say which port is needed, and why

Next: Phase 2 — Installation