Skip to content

Virtual Machines

Eight.ly OS includes full KVM/QEMU virtual machine management with a web-based console, snapshots, templates, and live monitoring.

Where to find it: Infrastructure > Server View. VMs appear as nodes in the resource tree; create, open, and manage them from there — there's no separate VMs page.

Creating a VM

The Create Virtual Machine wizard walks you through 7 steps:

  1. General — VM name
  2. OS — select an uploaded ISO image or download from URL
  3. System — BIOS/firmware (SeaBIOS legacy or UEFI/OVMF) and machine type
  4. Hardware — CPU cores, memory, disk size and format (qcow2/raw), and GPU passthrough
  5. Network — bridge and network model
  6. Cloud-Init — optional first-boot provisioning
  7. Confirm — review settings and create

Console

Each VM has a noVNC console accessible from the VM detail view — a full graphical console in your browser, no VNC client needed.

Snapshots

Manage point-in-time snapshots from the VM's Snapshots tab:

Action Description
Create Take a snapshot of the current VM state (memory + disk, for a running VM)
List View all snapshots with timestamps and sizes
Rollback Revert the VM to a previous snapshot
Delete Remove a snapshot to free storage

Snapshots of a running VM capture both disk and memory state, so rolling back restores the VM exactly as it was — running processes included.

Templates

Convert a stopped VM into a reusable template:

  1. Stop the VM
  2. Click Convert to Template in the VM actions menu
  3. The VM becomes a template — it can no longer be started directly, only cloned

To deploy from a template, select it in the tree, clone it, give the new VM a name, and start it.

You can also clone a regular (non-template) VM directly, choosing a full clone (an independent copy) or a linked clone (shares the base image with the original).

Cloud-init

For automated VM provisioning, the Create wizard's Cloud-Init step lets you set:

  • Hostname
  • A user account, password, and SSH key

Each field is opt-in — nothing is filled in for you, so a VM only gets cloud-init configuration you actually asked for.

Always install qemu-guest-agent in the guest OS

The guest agent lets Eight.ly report the VM's IP address, execute graceful shutdowns, and freeze filesystems for consistent snapshots. Without it, Eight.ly can only see the VM as an opaque process.

GPU Passthrough

Eight.ly supports passing through GPUs to VMs for tasks like Plex transcoding, AI workloads, or gaming:

  • NVIDIA GPUs — detected directly from the hardware, even before any driver is installed on the host. Select the GPU in the VM create wizard's Hardware step.
  • Intel Arc GPUs — detected the same way, covering current desktop and Pro Arc models.

This is standard PCI passthrough (the GPU is handed entirely to the VM), not SR-IOV sharing.

GPU passthrough requirements

Your motherboard and CPU must support IOMMU (VT-d for Intel, AMD-Vi for AMD). Enable it in BIOS before attempting GPU passthrough. The GPU being passed through cannot be the one driving the host's display — you need a separate GPU or headless operation.

Networking

Bridge vs NAT

Mode Use case
NAT VM shares the host's IP via port forwarding. The default in the create wizard — simpler, no LAN configuration needed.
Bridge VM gets its own IP on your LAN. Other devices can reach it directly. Choose this for a VM you want to treat as its own server.

Select the network mode in the Network step (step 5) of the create wizard.

Static IP assignment

For server VMs, assign a static IP via cloud-init or inside the VM's OS. You can also reserve IPs in your DHCP server using the VM's MAC address (visible in the VM detail view under Network).

Disk Management

Resize disk

  1. Stop the VM
  2. Open the VM's Hardware tab
  3. Click the disk, then Resize
  4. Enter the new size — grow only, shrinking isn't offered
  5. Start the VM and extend the filesystem inside the guest
# Inside the VM — extend the partition and filesystem
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1

Add additional disks

  1. Open the VM's Hardware tab
  2. Click Add Disk
  3. Choose size, format, and storage location
  4. The disk appears as a new block device inside the VM (e.g., /dev/vdb)

Performance Tuning

CPU pinning

For latency-sensitive workloads (databases, real-time processing), pin VM vCPUs to specific physical cores from the VM's Hardware tab. This prevents the host scheduler from moving the VM's threads between cores, reducing cache misses.

Memory ballooning

Memory ballooning lets the host reclaim unused RAM from a VM. Enable it from the VM's Options tab. The VM reports its actual memory usage, and the host can inflate a "balloon" driver inside the VM to free up pages.

When to disable ballooning

Disable ballooning for VMs running databases or applications that pre-allocate large memory pools (e.g., Elasticsearch, Redis). Ballooning can cause unexpected performance drops when the host reclaims memory the application expected to have.

I/O tuning

  • Use virtio disk and network drivers for best performance (selected by default for Linux guests)
  • For Windows guests, install the virtio drivers during OS installation
  • Use qcow2 format for snapshots and thin provisioning, raw for maximum I/O performance
  • Place VM disks on fast storage when possible — spinning disks create I/O bottlenecks with multiple VMs

Clustering: Breezeway and Rehome

Live migration and automatic failover are cluster features. They live behind Settings > Experimental > Clustering & High Availability, which is off by default — turn it on, then form a cluster, before either of the following becomes usable.

Breezeway is live migration: right-click a running VM and choose Migrate to move it to another node with zero ports opened. It needs a formed cluster with shared storage behind it, and it applies to VMs only — LXC containers don't have a migrate option.

Rehome is the high-availability arc: register a VM to be protected, and if its node goes down and the failure is confirmed, Eight.ly relocates it to a healthy node automatically, then live-migrates it back home once the original node recovers. Rehome can protect LXC containers too, but the container's root filesystem has to be on shared storage first, and a container's return home after recovery is a stop/redefine/start cycle rather than a live migration — there's no live-migration equivalent for LXC.

Monitoring

Each VM shows live resource metrics:

  • CPU — utilization percentage and core count
  • Memory — used vs allocated
  • Disk I/O — read/write throughput
  • Network — inbound/outbound traffic

Metrics update in real-time from the VM detail view. For historical graphs and alerting, enable the monitoring stack.