Mini Content Journey

Who is your target persona?

[Answer] A user, typically an Advanced VM Administrator, managing Virtual Machines (VMs) in OpenShift Virtualization (CNV) who utilizes advanced configurations like vNUMA for performance tuning. This persona requires detailed visibility into resource allocation to ensure optimal performance and compatibility with host-level policies, such as the Kubelet Topology Manager.

What stage of the user journey are you targeting?

[Answer] Adopt / Learn. The user is verifying the configuration of an already deployed VM. The addition of the vNUMA badge enables the user to quickly verify the complex configuration setting related to NUMA enablement.

Why is this content important?

[Answer] This content is important because it was currently not possible to see in VM details that NUMA is enabled. The feature (CNV-63573) addresses this by adding a vNUMA badge to the VM details overview tab and the VM configuration details tab. This visibility makes the status of the spec.domain.cpu.numa attribute clear (as a read-only attribute), which is crucial since vNUMA usage highly impacts the VM's behavior, particularly concerning live migration and CPU pinning via Topology Manager policies.

What is the main user goal aka job to be done?

[Answer] As an Advanced VM Administrator, I want to quickly confirm whether vNUMA (Non-uniform memory access) is configured on a Virtual Machine so that I can verify the VM's resource allocation setup for high-performance, latency-sensitive workloads that rely on memory locality.

What high level steps does the user need to take to accomplish the goal?

1. Navigate to the Virtual Machine (VM) details page in the UI.
2. View the VM details overview tab or the VM configuration details tab.
3. Observe the presence of the vNUMA badge/string next to the CPU/Memory section (or InstanceType section, depending on creation method).

(Optional) What pain points are the user likely to encounter when accomplishing this goal?

[Answer] The primary pain point addressed by this UI addition was the initial lack of visibility of NUMA enablement within the VM details. A secondary pain point is that once vNUMA is visible and enabled, its behavior (especially regarding live migration) is complex and depends on the Kubelet Topology Manager policy. For example, a VM with vNUMA enabled using the None Topology Manager policy might encounter issues during live migration.

Links to existing content

• [Link 1] GitHub Pull Request implementing the badge (CNV-63573): https://github.com/kubevirt-ui/kubevirt-plugin/pull/2833
• [Link 2] NUMA general definition: https://en.wikipedia.org/wiki/Non-uniform_memory_access
• [Link 3] Document detailing vNUMA live migration use cases and dependency on Topology Manager policies: https://docs.google.com/document/d/169adfy9QFd3YsiyXtzaEA3NE9jSBEoneCYL0mWw2gt8

People:

SME: Dominik Holler, Fabian Deutsch, Martin Tessun, Karel Simon (involved in technical discussions regarding vNUMA behavior).

QE: Karel Simon (mentioned testing).

Release Note: Yes (The issue regarding live migration failure with policy=none is planned to be mentioned in release notes as a known issue).

Documentation Outline

• Module Title (Reference): Identifying vNUMA Configuration in VM Details
    ◦ Outline the location of the read-only vNUMA badge/string (next to CPU/Memory or InstanceType section).

Original Jira description

UI updated to show NUMA badge.

See screen shot and info in: https://github.com/kubevirt-ui/kubevirt-plugin/pull/2833

Background

When VM uses NUMA (https://en.wikipedia.org/wiki/Non-uniform_memory_access), it is currently not possible to see in VM details, that the NUMA is enabled.

We were thinking about making it visible with `vNUMA` string next to CPU | Memory section (if vm was created without instance type, attachment image.png)
or in InstanceType section (if vm was created with instance type , attachment instancetype.png) of the VM detail page.

The attribute should be read only.
The string should be visible only is VM has defined attribute

spec.domain.cpu.numa