Phase 7 — Operations and comparison#

6 lessons · Level: intermediate

This phase is the work that keeps the system alive: the monthly routine, the commands, the errors you meet most, and the choice between VirtFusion and Proxmox.

What is in this phase#

Lesson	What you learn
1 — The security checklist	The tasks to do each month
2 — CLI reference	The commands that work when the panel does not open
3 — Common problems and their corrections	The errors that arrive most often
4 — Updates, PHP, and moving the control server	Update and move the system safely
5 — VirtFusion against Proxmox VE	The full comparison, and which one for which work
6 — Run both, and the migration path	Keep both, or move from one to the other

Lesson 1 — The security checklist#

Look at these once each month#

Task	How
Patch the host kernel and reboot	This is the one real correction for a KVM escape
Update VirtFusion	The control server and every hypervisor
Make sure that administrator 2FA is on	On every administrator account
Update the administrator IP list	`vfcli-ctrl admin:ip-restrict list`
Examine the API tokens	Delete the unused ones, and look at the IP lock
Test a backup restore	A backup that was never tested is not a backup
Look at the trusted hosts	Update the list when the domain changes

The KVM vulnerabilities of 2026#

Name	CVE	What it reaches
Januscape	CVE-2026-53359	x86, both Intel and AMD. A use-after-free in the KVM shadow MMU
Zapscape	CVE-2026-64561	x86, and especially AMD and some Intel configurations
ITScape	CVE-2026-46316	arm64 only. A double-free in the vGIC-ITS emulation

What to do: install the patched kernel of your distribution, and reboot. On x86, until the patch arrives, the interim measure is to keep nested virtualization off. On arm64 there is no way except the patch.

CAUTION: Do not turn the QEMU sandbox off. Without a very special reason, do not change /etc/libvirt/qemu.conf. It is a layer of security.

Lesson 2 — CLI reference#

The control server — `vfcli-ctrl`#

BASH

# accounts and access
vfcli-ctrl user:reset-admin-password
vfcli-ctrl system:reset-access-credentials
vfcli-ctrl tfa-force-off
vfcli-ctrl captcha-off

# administrator IP restriction
vfcli-ctrl admin:ip-restrict enable
vfcli-ctrl admin:ip-restrict disable
vfcli-ctrl admin:ip-restrict addip IP_TO_ADD
vfcli-ctrl admin:ip-restrict delip IP_TO_DELETE
vfcli-ctrl admin:ip-restrict list

# hypervisors
vfcli-ctrl hypervisor:force-remove
vfcli-ctrl hypervisor:re-commission

# servers
vfcli-ctrl server:password show SERVER_ID
vfcli-ctrl server:dnd enable SERVER_ID
vfcli-ctrl server:dnd disable SERVER_ID
vfcli-ctrl server:creation-date SERVER_ID '2026-08-01 00:00:00'
vfcli-ctrl server:configurations HYPERVISOR_ID --options=network

# traffic
vfcli-ctrl server:traffic-statistics reset-all
vfcli-ctrl server:traffic-statistics reset-all --include-datastore

# backups
vfcli-ctrl backups:force-flush
vfcli-ctrl backup-storage:reset-key

# tasks and services
vfcli-ctrl task:cancel
vfcli-ctrl app:restart --services=queue

The hypervisor — `vfcli-hv`#

BASH

vfcli-hv dr:backup
vfcli-hv dr:backup --only-servers=1754,1253
vfcli-hv dr:backup --exclude-system-data

WARNING: hypervisor:force-remove takes that node and its servers away from the control server by force. Use it only when the node is truly dead. If you do not, VM records stay behind with no node attached to them.

Lesson 3 — Common problems and their corrections#

The network#

A VM has no internet, but the host has. UFW on the hypervisor blocks the routed packets:

BASH

ufw default allow routed

Unable to get index for interface eth0: No such device The MacVTap interface name is wrong. Run ip a on the node, then correct Hypervisor → Networks → Primary Network → Interface Name.

The hypervisor connection#

A 401 error, and the hypervisor cannot be reached. The IP of the control server changed. On the hypervisor, in /opt/virtfusion/app/hypervisor/conf/auth.json, change the "ip" field to the new IP. Do not change the token, hash, or id fields.

"Commission status done" during a re-commission. The node is locked to another control server. If the node is clean, delete /opt/virtfusion/app/hypervisor/conf/auth.json. If it is not clean, install the node again.

Migration and DR#

A hybrid migration is stuck. Go to Server → Migrations, open the log, copy the first command in the Commands part, and run it over SSH on the control server.

The error "priority.xml found". A DR process runs, or it failed. Run it again:

BASH

vfcli-hv dr:backup --only-servers=SERVER_ID

The panel and the services#

A 500 error after a MariaDB update. Download the current MariaDB configuration file and install it. Restart the service, then restart the VirtFusion services.

The console preview does not work. ImageMagick is missing:

BASH

apt install imagemagick        # Debian and Ubuntu
dnf install ImageMagick        # RHEL, Alma, and Rocky

Supervisor needs an update. Install the current configuration and reload it. First make sure that no server task is running.

Inside the VM#

Turn nested virtualization on. With the CPU model host-passthrough it is on by default. To turn it off, change the CPU flag.

The order to search in#

Are the services running? Use systemctl status for vf-nginx, the queue

worker, and libvirtd.

Do the control server and the hypervisor reach each other? Port 8892 must

be open in both directions.

Is a task stuck? Run vfcli-ctrl task:cancel.
Is it the network? Look at UFW, the interface name, and which node holds

the IP block.

Then read the log, before you make a guess.

Lesson 4 — Updates, PHP, and moving the control server#

Updates#

VirtFusion changes quickly. Keep it current. Before an update:

Let the running tasks finish, or cancel them.
Take a backup of the database.
Update the control server first, then the hypervisors.

The PHP upgrade#

The PHP version of the control server is upgraded separately. Follow the "PHP Upgrade" guide of VirtFusion. The hypervisor also has PHP compatibility points.

Change the domain#

When you change the domain of the panel, three things must change together:

The control domain setting
The SSL certificate, with ACME on the new domain
The Trusted Hosts list

If you forget one, the panel does not open, or a security hole stays open.

Move the control server#

To move it to a new machine, the usual steps are:

Take a full backup on the old server: the database and the encryption key.
Install the same version on the new machine.
Restore the backup.
Re-issue the licence, because the licence locks to the control server.
Write the new IP into the auth.json of each hypervisor.
Correct the SSL certificate and the Trusted Hosts.

WARNING: A database backup is almost useless without the encryption key. Keep both together, but in a different place from the backup data.

Lesson 5 — VirtFusion against Proxmox VE#

A quick comparison#

Subject	VirtFusion	Proxmox VE
The main purpose	Sell VPS, to many tenants	Run your own infrastructure
Cost	A commercial licence, one for each cluster	Free. The enterprise repository is optional
Customer panel	Yes, separate, with limited rights	No. Everyone sees one UI, controlled by permissions
Virtualization	KVM only, full VMs	KVM and LXC containers
Cluster	Control server and nodes. No quorum needed	Corosync quorum. Two nodes need a QDevice
HA failover	No. If a node fails, recovery is manual or by DR	Yes, but it needs fencing
Live migration	Yes, on local or Ceph. The CPUs must match	Yes
Storage	local, Ceph RBD, remote FS, StorPool, Lightbits	LVM, LVM-thin, ZFS, Ceph, NFS, iSCSI
Backup	Its own Backup Manager (S3, PBS, SSH, Rclone)	vzdump and Proxmox Backup Server
Snapshots	Elevate, with commit and discard	Full snapshots and rollback
Billing connection	Modules for 7 billing systems	None
API	REST, `/api/v1`, a Bearer token	REST, tickets and tokens, `pvesh`
Traffic accounting	For each VM, with a package limit	None. You must build it
OS templates	cloud-init template management	You make the templates yourself
rDNS management	Yes, manual or automation	None

Who takes which#

Situation	Advice
You sell VPS and need a customer panel	VirtFusion
You run the servers of your own company	Proxmox VE
You need containers (LXC)	Proxmox VE
You want automatic provisioning from WHMCS or Blesta	VirtFusion
A VM must move to another node by itself when a node fails	Proxmox VE, with HA and fencing
You sell traffic accounting and bandwidth limits	VirtFusion
The budget is zero	Proxmox VE

An honest assessment#

VirtFusion is good at everything the customer sees: the panel, the billing connection, IP and traffic management, templates, and SSO. To build these on Proxmox takes months.

Proxmox is good at the flexibility of the infrastructure: containers, ZFS, snapshots, HA failover, and it costs nothing.

In short: VirtFusion is a platform to sell a product. Proxmox is a virtualization platform. Which one is "better" depends on what you sell.

Lesson 6 — Run both, and the migration path#

Both together#

Many providers run both:

Work	Where
Customer VPS	On the VirtFusion nodes
Your own internal services (monitoring, DNS, backup)	On Proxmox, in LXC containers

Do not install both on one bare-metal machine. Both want to control libvirt, KVM, and the network, and they collide. Keep separate nodes.

Proxmox to VirtFusion#

There is no automatic import tool. You do each VM by hand:

Stop the VM.
Export the disk from Proxmox, with qm move_disk or with `qemu-img

convert` straight to qcow2 or raw.

Install cloud-init and the QEMU guest agent inside it.
Clean the network configuration. On Debian, keep only

source /etc/network/interfaces.d/* in /etc/network/interfaces.

Make a server of the same size in VirtFusion, and install a similar OS.
Put the prepared disk on the hypervisor, with the correct name:

[UUID]_[DISK_ID].img.

Boot it, then look at the network and the data.

Advice on planning: do not move every VM together. Move one test VM of your own first, then a small customer, and the large ones last. Announce the downtime window for each one in advance. Use Mailouts.

What happens to the LXC containers#

VirtFusion runs no container. For the LXC services on Proxmox there are two paths:

Run those services as full VMs in VirtFusion. They need more RAM.
Keep one Proxmox node for the internal services only.

At the end of phase 7 you can#

Run the monthly security routine
Do emergency work with the CLI
Correct the common errors yourself
Update and move the control server safely
Choose correctly between VirtFusion and Proxmox

Back to the contents

Phase 7 — Operations and comparison#

What is in this phase#

Lesson 1 — The security checklist#

Look at these once each month#

The KVM vulnerabilities of 2026#

Lesson 2 — CLI reference#

The control server — vfcli-ctrl#

The hypervisor — vfcli-hv#

Lesson 3 — Common problems and their corrections#

The network#

The hypervisor connection#

Migration and DR#

The panel and the services#

Inside the VM#

The order to search in#

Lesson 4 — Updates, PHP, and moving the control server#

Updates#

The PHP upgrade#

Change the domain#

Move the control server#

Lesson 5 — VirtFusion against Proxmox VE#

A quick comparison#

Who takes which#

An honest assessment#

Lesson 6 — Run both, and the migration path#

Both together#

Proxmox to VirtFusion#

What happens to the LXC containers#

At the end of phase 7 you can#

The control server — `vfcli-ctrl`#

The hypervisor — `vfcli-hv`#