Skip to content

VM Advanced Features

This page covers the advanced VM configuration options available in the Pilvio.pro portal: boot types, vTPM, secure boot, CPU pinning, CPU topology, bulk VM creation, and snapshot-based deployment.

For basic VM creation and management, see the Virtual Machines guide.

Boot Types

When creating or updating a VM, you can choose the boot type:

Boot Type Description Use Case
BIOS Legacy BIOS firmware Default for most Linux images and older OS
UEFI Unified Extensible Firmware Interface Required for Windows 11, modern Linux, and Secure Boot
UEFI-SECURE-BOOT UEFI + Secure Boot enabled Windows 11, workloads requiring measured boot

Tip

Most Linux images support BIOS or UEFI. Windows 11 requires UEFI-SECURE-BOOT. Check your image's documentation to confirm the required boot type.

Selecting Boot Type in the Portal

  1. Navigate to the VM create wizard or the VM details page.
  2. Find the Boot Type dropdown.
  3. Select the appropriate option.
  4. If using Secure Boot, ensure the OS image supports it.

vTPM (Trusted Platform Module)

A vTPM is a virtualised TPM 2.0 device attached to the VM. It provides:

  • Measured boot — the boot process is measured and recorded, enabling attestation.
  • BitLocker compatibility — Windows BitLocker can use the vTPM to protect disk encryption keys.
  • UEFI Secure Boot support — vTPM works with UEFI Secure Boot for enhanced security.

Enabling vTPM

  1. Navigate to the VM details page.
  2. Find the TPM toggle in the details table.
  3. Ensure the VM is halted, then switch the toggle on to attach a vTPM, or off to remove it.

Tip

The VM must be halted before attaching or detaching a vTPM — toggling it on a running VM is rejected.

CPU Pinning

CPU pinning (also called CPU affinity) assigns a VM's virtual CPUs to specific physical CPU cores on the host. This reduces context switching and improves performance for latency-sensitive workloads.

Enabling CPU Pinning

  1. Navigate to the VM details page.
  2. Find the CPU pinning toggle in the details table.
  3. Switch it on. The platform assigns the VM's vCPUs to dedicated physical cores.

Tip

Pinned vCPUs are billed at a different rate: 4 VCU per month instead of 1 VCU per month for unpinned vCPUs, reflecting the dedicated physical resource commitment. The portal shows the new estimated price before you confirm. See Billing & Resource Consumption.

CPU Topology

The CPU topology setting lets you configure how vCPUs are distributed across sockets and cores. This affects how the operating system sees and schedules workloads.

  1. Navigate to the VM details page.
  2. Click MORE, then CPU TOPOLOGY.
  3. Configure:
  4. Cores — CPU cores per socket
  5. Threads — threads (hyper-threading) per core
  6. Sockets — number of virtual sockets
  7. Click UPDATE.
  8. The total vCPUs = Sockets × Cores × Threads.

Example: 8 sockets × 2 threads × 4 cores = 64 vCPUs.

Tip

Changing CPU topology changes the total vCPU count and may affect your billing. Always review the estimated cost before applying topology changes to a running VM.

QEMU Guest Agent

The QEMU Guest Agent (QEMU GA) is a daemon that runs inside the VM and communicates with the Pilvio.pro platform. It enables:

  • Graceful shutdown — the platform can shut down the VM cleanly rather than forcing it off.
  • File system freeze — consistent snapshots by temporarily freezing the filesystem.
  • Network interface hot-add — add network interfaces without rebooting.
  • Host name retrieval — the portal can display the VM's actual hostname.

Installing QEMU GA

The installation method depends on the operating system:

Linux:

# Debian/Ubuntu
sudo apt install qemu-guest-agent

# RHEL/CentOS
sudo dnf install qemu-guest-agent

# Start the service
sudo systemctl enable qemu-guest-agent
sudo systemctl start qemu-guest-agent

Windows: QEMU GA is included on an ISO image that is automatically attached to every Windows VM created in the portal. See Enable QEMU Agent for detailed Windows installation steps.

After installation, verify the agent is running:

# Linux
sudo systemctl status qemu-guest-agent

Bulk VM Creation

You can create multiple identical VMs at once using CREATE BATCH, next to the VM create button in the cloudspace's VMs tab (the button reads IMPORT BATCH instead, if the VM source is S3):

  1. Click CREATE BATCH.
  2. Enter the number of VMs in batch (capped by the number of available IP addresses).
  3. Configure the common settings for the batch.
  4. Click CREATE BATCH.

All VMs in the batch are provisioned with the same configuration.

Creating a VM from a Snapshot

There is no standalone "create VM from snapshot" button on a disk's Snapshots tab — that tab only offers ROLLBACK and DELETE. To create a new VM from an existing disk snapshot, use the main VM-creation wizard instead:

  1. In the target cloudspace's VMs tab, click CREATE VM.
  2. Select Create from a snapshot as the virtual machine source.
  3. In Select Boot Disk, select the boot disk, then in Select snapshot select the snapshot to use (enable Show automatic snapshots to include automatic snapshots).
  4. Configure the new VM's settings (name, vCPUs, memory).
  5. Click CREATE.

The new VM boots from the snapshot's disk state.

Creating a Template from a VM

Create a reusable template from a VM:

  1. Navigate to the VM details page.
  2. Click MORE, then CREATE TEMPLATE.
  3. Enter the Template name.
  4. Click CREATE.

The VM's boot disk is converted to a template image, available in the Images section for the location. You can now create new VMs from this template.

Exporting a VM to S3

Export a VM's disk to an S3-compatible object storage:

  1. Navigate to the VM details page.
  2. Click EXPORT TO S3 at the top of the page.
  3. Enter the S3 configuration — all fields are required:
  4. Link — the S3 server link
  5. Key — access key to the server
  6. Secret — secret to access the server
  7. Region — region of the S3 server
  8. Bucket — name of the bucket
  9. Object Name
  10. Click EXPORT TO S3.

Tip

The recommended way to export a VM to S3 is via the CLI — the portal shows a note linking to that guide.

Deleting a VM (Recycle Bin)

When you delete a VM, it moves to the Recycle Bin rather than being permanently destroyed. See Recycle Bin & Restore for how long it is kept (7 days by default).