Getting started

Quick Start: First Provision

A practical beta onboarding guide for installing VMNexor, adding a Proxmox node, preparing templates and provisioning the first VM service.

VMNexor documentation is actively evolving. Some features, wording, and screenshots may change during beta.

Beta documentation

This guide is written for early VMNexor beta users. It only covers workflows that have already been implemented, tested or established during VMNexor development.

What VMNexor does

VMNexor is a Proxmox-based VM provisioning and infrastructure management platform focused on hosting providers, customer self-service workflows and WHMCS integration.

  • Automated VM provisioning
  • Multi-node Proxmox management
  • Customer VM controls
  • VM reinstall automation
  • Linux and Windows template support
  • WHMCS integration workflows
  • Console relay access
  • Licensing and update workflows

Current supported environment

VMNexor has been actively tested against Proxmox VE 8 and Proxmox VE 9 during development.

  • Linux templates tested: Ubuntu 24.04, Debian 12 and Debian 13
  • Windows templates tested: Windows Server 2019, Windows Server 2022 and Windows 10
  • Additional operating systems may work but should be validated before production use

Recommended deployment layout

A typical VMNexor deployment uses one application VM, one or more Proxmox nodes, a database and a reverse proxy.

  • VMNexor application VM for the web UI, API, scheduler and queue workers
  • Proxmox nodes for VM provisioning and infrastructure operations
  • MariaDB or MySQL for the platform database
  • Nginx for web serving and reverse proxying
  • PHP 8.4 as the application runtime

Before you start

Before provisioning through VMNexor, prepare the Proxmox side first.

  • Working Proxmox VE node or cluster
  • Proxmox API access configured
  • Storage configured
  • Networking configured
  • DNS records configured
  • At least one tested VM template

Installation layout

Current VMNexor builds use a release-based deployment structure with shared persistent storage.

  • The current symlink points at the active release
  • The releases directory stores deployed builds
  • The shared directory stores persistent state, logs, environment configuration and runtime files
Current release pointer
Release history
Persistent application data

Core services

Current VMNexor deployments use standard web, queue, scheduler and console relay services.

Check the web service
Check the reverse proxy
Check background worker services
Check scheduled task services
Check console access services

Add your first Proxmox node

After installation, add your first Proxmox node from the VMNexor admin area.

  • Log into the VMNexor admin panel
  • Open infrastructure or node management
  • Add the Proxmox API hostname and credentials
  • Configure node name, storage and network details
  • Confirm VMNexor can communicate with the Proxmox API

Prepare a Linux template

  • Install cloud-init
  • Install QEMU Guest Agent
  • Clean machine-specific state before templating
  • Shut down the VM
  • Convert the VM into a Proxmox template
  • Test networking, DNS and reboot behaviour after provisioning
Install the guest agent and cloud-init using your operating system package manager, then enable required services according to your distribution standards.

Prepare a Windows template

Windows provisioning uses Cloudbase-Init, VirtIO drivers and QEMU Guest Agent. Current testing favours using Cloudbase-Init for networking and allowing Windows first-boot behaviour to complete normally.

  • Install VirtIO drivers
  • Install QEMU Guest Agent
  • Install and configure Cloudbase-Init
  • Run Sysprep where appropriate
  • Shut down and convert the VM to a Proxmox template
  • Validate boot, networking, DNS and password behaviour

Create your first VM package

A VM package defines the resources and template choices used during provisioning.

  • CPU allocation
  • RAM allocation
  • Disk size
  • Template selection
  • Storage selection
  • Node or location selection
  • Network and IP allocation rules

Provision the first VM service

Once a package and template are ready, create a test VM service and watch the provisioning workflow complete.

  • Select node, template, storage and IP allocation
  • Start provisioning
  • Confirm clone completion
  • Confirm cloud-init or Cloudbase-Init behaviour
  • Confirm the VM starts
  • Confirm networking and DNS from inside the guest

Validate customer functions

  • Power controls
  • Reboot and shutdown
  • Console access
  • Reinstall workflows
  • QEMU Guest Agent reporting
  • Template-specific password behaviour

WHMCS integration

VMNexor includes WHMCS integration workflows for provisioning, lifecycle actions, reinstall rules, product synchronization and customer controls. WHMCS deployment steps may vary by billing environment.

  • Connect WHMCS products to VMNexor provisioning logic
  • Map products to templates and packages
  • Validate create, suspend, unsuspend and terminate behaviour
  • Validate customer reinstall behaviour before production use

Console relay

VMNexor uses relay-based console access so customers do not need direct Proxmox access.

  • Proxy the relay through Nginx
  • Use HTTPS
  • Validate browser-based behaviour behind reverse proxies
  • Keep console sessions controlled and short-lived
Customer console request
VMNexor console access layer
Provider reverse proxy

Proxmox 9 testing note

During development, VM cloning worked on Proxmox 9, but some qcow2 disk resize operations timed out when expanding from the template size. Test resize behaviour on your selected storage before using Proxmox 9 in production.

Production checks

Before production rollout, validate the full lifecycle rather than only the initial VM create operation.

  • Create VM service
  • Reboot VM service
  • Stop and start VM service
  • Open console
  • Run reinstall
  • Confirm networking after reinstall
  • Confirm DNS after reinstall
  • Confirm WHMCS lifecycle actions if WHMCS is connected
  • Back up persistent application data
  • Back up the database

Terminology standards

  • Use Proxmox node instead of randomly switching between host, server and hypervisor
  • Use VM service for provisioned customer services
  • Use reinstall for OS reinstall workflows
  • Use template for Proxmox VM templates
  • Use customer area for customer-facing VM management
  • Use console relay for VM console proxy service

Next steps

After the first provision works, continue with the more detailed operational guides.

  • Linux template guide
  • Windows template guide
  • Cloudbase-Init guide
  • Cloud-Init guide
  • Routed /32 networking guide
  • WHMCS module guide
  • Console access guide
  • Troubleshooting guide

Related guides