Hypervisor Configuration

Overview

Polystack Compute uses a native hypervisor as its default virtualization layer, managed through the libvirt driver. The native hypervisor provides hardware-assisted virtualization on x86, ARM, and POWER architectures, delivering near-bare-metal performance for virtual machine workloads. The libvirt driver translates OpenStack Compute API requests into hypervisor operations on each compute node. Understanding these configuration options helps you tune workload placement, CPU topology, storage performance, and security posture.

Prerequisites

Administrator access to the Polystack platform and the deployment console
Compute nodes running Polystack OS with libvirt and qemu-kvm installed
Verify hardware virtualization support: grep -o 'vmx\|svm' /proc/cpuinfo | head -1

Supported Image Formats

The following disk image formats are supported by the native hypervisor driver. The format is detected automatically from the image metadata stored in the Polystack Image Service.

Format	Name	Description	Recommended Use
`raw`	Raw disk image	Flat binary representation of disk contents. No overhead from format features.	Maximum I/O performance, RBD-backed volumes
`qcow2`	QEMU Copy-on-Write v2	Supports snapshots, compression, and copy-on-write. More flexible than raw.	Local storage, development environments
`qed`	QEMU Enhanced Disk	Optimized for sparse images with faster lookup tables than qcow2.	Legacy workloads; qcow2 is preferred for new deployments
`vmdk`	VMware Disk	VMware-compatible format. Supported for import/migration scenarios.	VM migrations from VMware environments

For production deployments using Software-Defined-Storage (distributed storage) as the storage backend, use raw format images. The distributed storage layer handles copy-on-write natively, making qcow2 overhead unnecessary and counterproductive.

Hardware Requirements

x86 / x86_64
ARM / AArch64
POWER / ppc64le

x86 is the primary supported architecture for Polystack Compute.CPU Requirements

Intel VT-x (vmx flag in /proc/cpuinfo) or AMD-V (svm flag)
For optimal performance: Intel VT-d or AMD-Vi (IOMMU) for PCI passthrough

Verification

Check virtualization support

grep -oE 'vmx|svm' /proc/cpuinfo | sort -u

Check IOMMU (for PCI passthrough)

dmesg | grep -i iommu

BIOS/UEFI Settings

Enable Intel VT-x / AMD-V in BIOS
Enable Intel VT-d / AMD-Vi if PCI passthrough is required
Enable Hyper-Threading for improved vCPU density (optional)

Both vmx or svm flag and IOMMU should be present for full feature support.

ARM 64-bit (AArch64) is supported for compute nodes running compatible hardware.CPU Requirements

ARMv8-A or later with hardware virtualization extensions (EL2)
PSCI firmware support for CPU hotplug operations

Verification

Check ARM virtualization support

grep -i 'Features' /proc/cpuinfo | grep -i asimd

Not all ARM platforms support all hypervisor features. Verify your hardware’s EL2 support before deploying production workloads.

IBM POWER (ppc64le) is supported with the native hypervisor driver for POWER.CPU Requirements

POWER8 or later for full hardware virtualization
POWER7 supports paravirtualized mode (reduced performance)

Verification

Check POWER virtualization mode

grep -i 'platform' /proc/cpuinfo

Full hardware virtualization on POWER requires bare-metal POWER hardware — nested virtualization is not supported in this mode.

Backing Storage Options

The hypervisor driver supports multiple backing storage configurations for instance disks. The backing storage determines how ephemeral instance disks are stored on compute nodes.

Storage Type	Description	Pros	Cons
QCOW (local)	qcow2 files on compute node local storage	Simple setup, copy-on-write snapshots	No live migration, no fault tolerance
Flat (raw local)	Raw image files on compute node local storage	Maximum local I/O performance	No live migration, no fault tolerance
LVM	Logical volumes on compute node volume groups	Better I/O than file-backed, thin provisioning	Complex setup, no live migration
RBD (Software-Defined-Storage)	Distributed block device via network	Live migration, fault tolerance, snapshots	Requires Software-Defined-Storage distributed storage cluster

Local storage backends (QCOW, Flat, LVM) do not support live migration. Use RBD-backed storage when live migration between compute nodes is required.

The storage backend is configured per compute node in the Nova configuration, managed by the deployment console via the ironcore-ansible deployment playbooks.

CPU Configuration Modes

The CPU mode controls how CPU features and topology are presented to virtual machines. This affects live migration compatibility and performance.

CPU Mode	Description	Live Migration	Performance	Use Case
`host-passthrough`	Exposes exact host CPU model and all features	Requires identical CPUs	Best	Homogeneous clusters, bare-metal benchmarks
`host-model`	Snapshots the host CPU model at VM launch	Restricted to similar CPUs	Near-native	Clusters with similar CPU generations
`custom`	Specifies an explicit baseline CPU model	Cross-generation compatible	Reduced	Mixed-CPU clusters, live migration across generations
`none`	QEMU default — minimal feature set	Compatible	Lowest	Legacy compatibility only; not recommended

For mixed-CPU clusters (e.g., nodes with Intel Icelake and Cascadelake CPUs), use cpu_mode = custom with a common baseline model such as Cascadelake-Server-noTSX. This ensures live migration succeeds across all nodes in the cluster.

Configuring CPU Mode

CPU mode is set in the Nova compute configuration, which the deployment console manages via globals.d overrides:

/etc/ironcore/globals.d/_50_compute.yml

nova_cpu_mode: "custom"
nova_cpu_model: "Cascadelake-Server-noTSX"

Apply the change with:

Apply compute configuration

ironcore-ansible deploy -t nova

Nested Virtualization

Nested virtualization allows virtual machines to run their own hypervisors (e.g., for CI/CD pipelines, hypervisor testing, or running Kubernetes with virtualization-backed nodes).

Enabling Nested Virtualization

Enable on the host kernel

Load the hypervisor module with nested support enabled:

echo "options kvm_intel nested=1" | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

echo "options kvm_amd nested=1" | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_amd && sudo modprobe kvm_amd

Verify nested support is active

Verify nested virtualization

cat /sys/module/kvm_intel/parameters/nested   # Should return Y or 1
cat /sys/module/kvm_amd/parameters/nested     # AMD alternative

Output should be Y or 1 confirming nested virtualization is enabled.

Set CPU mode to host-passthrough

Nested VMs require the host CPU feature flags to be visible inside the VM. Set cpu_mode = host-passthrough in the Nova configuration, or use host-model if cross-node migration is needed.

globals.d override for nested virtualization

nova_cpu_mode: "host-passthrough"

Nested Virtualization Limitations

Performance is significantly reduced compared to first-level VMs due to double emulation overhead
Live migration of nested VMs may not be supported depending on the inner hypervisor
Not recommended for production workloads — use dedicated bare-metal nodes for performance-sensitive nested environments
host-passthrough CPU mode restricts live migration to nodes with identical physical CPUs

Performance Tuning

VHostNet

VHostNet offloads virtio-net packet processing from QEMU user-space to the kernel, significantly reducing CPU overhead for network-intensive workloads.

Verify VHostNet is loaded

lsmod | grep vhost_net

VHostNet is enabled by default on Polystack OS. No additional configuration is required.

CPU Pinning

For latency-sensitive workloads, pin instance vCPUs to dedicated physical cores to eliminate CPU scheduler jitter. See the Advanced Features guide for CPU pinning configuration.

Huge Pages

Configure huge page memory backing for memory-intensive or NUMA-sensitive workloads. Huge pages reduce TLB pressure and improve memory throughput. See the Advanced Features guide for huge page setup.

Capabilities

Advanced Features

CPU pinning, huge pages, NUMA topology, GPU passthrough, and SR-IOV configuration

Live Migration

Configure and execute live migrations between compute nodes

Compute Architecture

Understand the full Polystack Compute architecture and service components

Security Hardening

Hypervisor-level security configuration and CIS compliance hardening

Troubleshooting

VMs fail to start: hypervisor not available

Cause: Hardware virtualization is disabled in BIOS or the hypervisor kernel module is not loaded.Resolution:

Check hypervisor module status

lsmod | grep kvm

Load hypervisor modules manually

sudo modprobe kvm
sudo modprobe kvm_intel   # or kvm_amd for AMD CPUs

If the module fails to load, enable VT-x/AMD-V in the server BIOS and reboot.

Live migration fails: 'guest CPU doesn't match specification'

Cause: The source and destination compute nodes have incompatible CPU models. This commonly occurs in mixed-CPU clusters when host-model or host-passthrough is used.Resolution: Switch to custom CPU mode with a common baseline:

globals.d fix

nova_cpu_mode: "custom"
nova_cpu_model: "Cascadelake-Server-noTSX"

Apply with ironcore-ansible deploy -t nova on all nodes, then retry the migration.

Poor disk I/O performance on RBD-backed instances

Cause: qcow2 format images are being used with Software-Defined-Storage distributed storage, adding unnecessary copy-on-write overhead.Resolution: Use raw format for all images on Software-Defined-Storage-backed deployments. Convert existing images:

Convert qcow2 to raw

openstack image create \
  --disk-format raw \
  --container-format bare \
  --file <(qemu-img convert -f qcow2 -O raw source.qcow2 /dev/stdout) \
  my-raw-image

Nested VMs fail to start inside a guest

Cause: The host compute node does not have nested virtualization enabled, or the CPU mode does not expose virtualization feature flags to the guest.Resolution:

Verify nested support: cat /sys/module/kvm_intel/parameters/nested
Confirm the instance is using a flavor with hw:cpu_mode=host-passthrough or equivalent
Verify the guest OS can see the virtualization flag: grep -c vmx /proc/cpuinfo from inside the VM

libvirtd not running on compute node

Cause: The libvirtd service failed to start or crashed.Resolution:

Check libvirtd status

sudo systemctl status libvirtd
sudo journalctl -u libvirtd -n 50

Common causes include AppArmor policy conflicts and missing QEMU binaries. Review the journal output for the specific error and consult the Polystack support portal.

Heterogeneous Hardware Support

Polystack supports mixing different hardware configurations within a single cluster — no hardware homogeneity required.

Mixed Node Types

Run converged (compute+storage), compute-only, and storage-heavy nodes in the same cluster. Each node contributes its resources to the shared pool.

Mixed CPU Generations

Intel and AMD processors of different generations coexist. CPU feature masking ensures live migration compatibility across generations. See CPU Feature Masking.

Mixed Storage Media

NVMe, SSD, and HDD drives in the same cluster. CRUSH device classes auto-detect media type per device and route data to the correct tier. See Storage Tiers.

Varying RAM Capacities

Nodes with different RAM sizes — no configuration needed. The scheduler tracks per-host capacity independently and places instances on hosts with sufficient resources.

Use Host Aggregates to group nodes by capability (e.g., GPU hosts, high-memory hosts) and restrict specific flavors to specific hardware groups. See Scheduling.

Next Steps

Advanced Features

Configure CPU pinning, huge pages, and GPU passthrough for specialized workloads

Live Migration

Set up and execute live migrations across compute nodes

Compute Admin Guide

Full administrator reference for the Polystack Compute service

Ironcore Product

Learn about the full Ironcore Advanced Virtualization Suite

Core Services

Other Services

Overview

Supported Image Formats

Hardware Requirements

Backing Storage Options

CPU Configuration Modes

Configuring CPU Mode

Nested Virtualization

Enabling Nested Virtualization

Enable on the host kernel

Verify nested support is active

Set CPU mode to host-passthrough

Performance Tuning

VHostNet

CPU Pinning

Huge Pages

Capabilities

Advanced Features

Live Migration

Compute Architecture

Security Hardening

Troubleshooting

Heterogeneous Hardware Support

Mixed Node Types

Mixed CPU Generations

Mixed Storage Media

Varying RAM Capacities

Next Steps

Advanced Features

Live Migration

Compute Admin Guide

Ironcore Product

​Overview

​Supported Image Formats

​Hardware Requirements

​Backing Storage Options

​CPU Configuration Modes

​Configuring CPU Mode

​Nested Virtualization

​Enabling Nested Virtualization

Enable on the host kernel

Verify nested support is active

Set CPU mode to host-passthrough

​Performance Tuning

​VHostNet

​CPU Pinning

​Huge Pages

​Capabilities

Advanced Features

Live Migration

Compute Architecture

Security Hardening

​Troubleshooting

​Heterogeneous Hardware Support

Mixed Node Types

Mixed CPU Generations

Mixed Storage Media

Varying RAM Capacities

​Next Steps

Advanced Features

Live Migration

Compute Admin Guide

Ironcore Product

Overview

Supported Image Formats

Hardware Requirements

Backing Storage Options

CPU Configuration Modes

Configuring CPU Mode

Nested Virtualization

Enabling Nested Virtualization

Performance Tuning

VHostNet

CPU Pinning

Huge Pages

Capabilities

Troubleshooting

Heterogeneous Hardware Support

Next Steps