Operations

KVM & VPS Engine

Provision and operate KVM virtual machines locally or across Fleet hypervisors, including snapshots, patching and migration.

One-Click documentation · Step-by-step guide

One-Click can turn suitable controller or Fleet members into KVM hypervisors and manage guests through the same shell-native control model.

Create a Guest

one-click --vps create --target hypervisor1 --name db1 --image ubuntu24 --cpu 2 --ram 4G --disk 40G --mode nat

Guests can be built with NAT or public networking depending on the environment. NAT guests can later be published through the edge proxy or reached through the private mesh.

Lifecycle Operations

--vps start / stopPower state.

--vps editGuest configuration.

--vps snapshotSnapshot lifecycle.

--vps backupGuest backup.

--vps patchPatch workflow.

--vps reinstallOS reinstallation.

--vps migrateMove a guest between suitable hypervisors.

one-click --vps snapshot create --target web1 --name backup_v1
one-click --vps migrate --target hypervisor2 --name web1
one-click --vps reinstall -n web1 -i ubuntu24 --password '<temporary-password>'

VPS Movement: Fleet-to-Fleet Migration vs Import/export

One-Click has two intentionally different VPS movement mechanisms.

Fleet-to-Fleet migrationone-click --vps migrate is a hypervisor-level move. The VM is shut down, its libvirt XML and disk artifacts are copied to another trusted Fleet hypervisor, the VM is defined and started there, and the virtualization ledger is updated.

External import/exportone-click --vps import and one-click --vps export --name <vps_name> are guest-filesystem migrations. They are intended for crossing the Fleet boundary or moving into a freshly provisioned replacement while preserving destination boot/network/SSH identity.

Use Fleet-to-Fleet migration when both hypervisors are already part of the same Fleet and you want to move the actual VM disks and configuration. Use import/export when the source or destination is outside the Fleet or when the replacement machine must retain its own infrastructure identity.

Safeguarded Fleet-to-Fleet migration stages the destination first, validates the copied VM before committing inventory, and retains the original source VM shut down with autostart disabled after success. If migration fails before commit, the destination copy is removed and the original VM is restarted with its previous autostart state restored.

← Documentation index Explore the project on GitHub →