9.18.19.7. Live migration outcomes using vNUMA
Migration outcomes for VMs are dependent on the configured Topology Manager policies. These policies determine how CPU and memory resources are allocated with respect to the physical NUMA nodes of the host. There are four available policies: None, single-numa-node, best-effort, and restricted.
The following table outlines which policies are supported for different VM configurations, and their effect on live migration.
- A small VM is defined as a VM with less total cores than half of cores in NUMA node.
- A large VM is defined as a VM with more total cores than half of cores in NUMA node.
- An extra large VM is defined as a VM with more cores than 1 NUMA node.
| VM size | Topology Manager policy | Tested support status |
|---|---|---|
| Any | single-numa-node | The VM fails to start because the pod requests more cpus than a single NUMA node on the host can provide. This triggers a topology affinity error during scheduling, which is expected behavior given the node’s hardware limits. |
| Any | None | Live migration does not work. This is a known issue. The process ends with an incorrect memnode allocation error, and libvirt rejects the XML manifest generated by KubeVirt. See release notes for additional information. |
| Small | None | Live migration works, as expected. |
| Small | single-numa-node | Live migration works, as expected. |
| Small | best-effort | Live migration works, as expected. |
| Small | restricted | Live migration works, as expected. |
| Large | single-numa-node | Live migration works, as expected. |
| Large | best-effort | Live migration works, as expected. |
| Large | restricted | Live migration works, as expected. |
| Extra large | None | Live migration works, as expected. |
| Extra large | best-effort | Live migration works, as expected. |
| Extra large | restricted | VMs do not work, as expected. |