Advanced VM Hardware Settings¶

These settings are under right-click the VM → Settings → Hardware. CPU, memory and option changes need the VM powered off. Disks, network adapters and controllers can be added while it runs (see Change hardware while the VM runs).

CPU type¶

CPU type	Use it when
Host model (default)	Most VMs. The guest sees a CPU close to the host's, and can migrate to hosts of the same or newer CPU generation.
Host passthrough	You want the fastest CPU and every host feature, and every host the VM might move to has the same CPU. Migration to a different CPU can fail.
Cluster baseline	The cluster mixes CPU generations and the VM must live-migrate across all of them. The console picks the newest CPU model every active host in the VM's cluster can run.
Named model…	You need a specific model, for example to match a license tied to a CPU type. The list shows the models the VM's host can run.

Cluster baseline is worked out when you save the settings and stored as that named model. If you later add a host with an older CPU to the cluster, power the VM off, choose Cluster baseline again and save, so it is recomputed to include the new host.

Nested virtualization¶

Expose Hardware Virtualization lets the guest run its own hypervisor (KVM, Hyper-V, nested labs). It works with any CPU type. With Host passthrough it's always on, because that type always exposes the host's virtualization support.

Hugepages¶

Back memory with hugepages (Memory row) gives large or latency-sensitive VMs (databases, packet processing, real-time workloads) faster memory. The host must have enough hugepages reserved for the VM's whole memory; if it doesn't, the console tells you so. Reserve them on the host first, for example with a hugepages= kernel argument or vm.nr_hugepages.

Guest NUMA nodes¶

Guest NUMA nodes splits the VM's vCPUs and memory into that many NUMA nodes, for large VMs whose software is NUMA-aware. 0 or 1 means no guest NUMA. The vCPUs and memory must divide evenly by the number of nodes.

Shared folders (virtiofs)¶

A VM can mount a folder from its host, with no network share in between.

An admin lists the host folders VMs may share: Settings → Shared Folders (virtiofs), one path per line (for example /srv/shares). Save. System folders such as /etc are refused.
In the VM's Settings → Hardware → Shared Folders, + Add folder, pick an allowed folder and give it a tag.
Start the VM and mount it in the guest:
```
mount -t virtiofs <tag> /mnt/shared
```

The host checks the allowed list again before sharing, so a folder removed from it in Settings can't be shared any more. The folder must exist on the host the VM runs on.

A VM with a shared folder can only be migrated powered off, and the load balancer leaves it alone.

Change hardware while the VM runs¶

Change	While running
Add a disk	Yes
Grow a disk (Resize on the disk)	Yes. The guest sees the new size at once. Extend the partition and filesystem inside the guest yourself. Shrinking a running VM's disk is refused. Raw passthrough (RDM) disks can't be resized.
Add a network adapter	Yes
Add a SCSI controller	Yes
Add vCPUs / memory	Only with Enable CPU Hot-Add / Enable Memory Hot-Add turned on beforehand (while the VM was off).
CPU type, NUMA, hugepages, boot and options	No: power the VM off first.

After adding a disk, adapter or controller to a running VM, Apply Settings just closes the dialog. The device was already added. If you also changed CPU, memory, boot or option settings, the dialog asks you to power the VM off first.

VMs created before 1.1.0-rc2

Older Linux VMs were created without ACPI, which hot-plug needs. The first disk, adapter or controller added to such a VM while it runs is saved to its configuration and appears only after a power off and start. A reboot from inside the guest isn't enough. That first add also turns ACPI on (and, on q35, adds spare hot-plug slots), so later devices are added live. New VMs have ACPI from the start.