Running a real-time operating system inside a virtual machine does not automatically create a deterministic environment. The virtual machine still depends on physical processors, memory, interrupts, and devices controlled by the host.

If those resources are shared or poorly placed, unrelated activity can interrupt the timing-sensitive workload. The system may function correctly most of the time but become less predictable when network traffic, storage activity, host services, or another virtual machine increases its use of the hardware.

CPU shielding, NUMA-aware configuration, and interrupt affinity help engineers control these sources of interference. They address different parts of the system, but they are most effective when planned together.

Virtual CPUs Still Depend on Physical Hardware

A virtual machine may be configured with a certain number of virtual CPUs, or vCPUs. These appear to the guest operating system as processors, but the vCPUs must ultimately run on physical processor cores.

In a general-purpose virtual environment, the hypervisor may move work among available cores to improve overall utilization. This approach is useful for workloads evaluated by average throughput, but it can create problems for applications that depend on consistent response times.

A vCPU may be delayed if its physical core is also handling:

• Host operating-system tasks
• Another virtual machine
• Device interrupts
• Background services
• Memory-management activity
• Power-management transitions

Assigning vCPUs is therefore only the first step. Engineers also need to determine which physical cores will execute them and what other activity is permitted on those cores.

What Is CPU Shielding?

CPU shielding reserves selected physical processor cores for designated workloads. The objective is to prevent the host scheduler from placing unrelated processes on cores assigned to timing-sensitive work.

In a virtualized system, shielded cores can be assigned to the vCPUs supporting a real-time guest. Host services and non-real-time virtual machines are directed to a separate set of cores.

A simplified allocation might look like this:

Processor resources	Primary use
Host cores	Host services, device management, and general system activity
Real-time VM cores	Timing-sensitive guest workloads
General-purpose VM cores	Operator interfaces, logging, analysis, or other non-real-time functions

The assignments should not overlap unless sharing is intentional and has been tested. If a real-time VM and a general-purpose VM can both run on the same physical core, activity in one environment may delay the other.

Shielding also does not mean that a core is completely isolated. Interrupts, kernel activity, and some hardware-related events may still reach it unless those sources are configured separately.

For that reason, CPU shielding should be treated as one part of resource isolation rather than a complete solution. If you want to learn more about CPU shielding see full break down What Is CPU Shielding (and Why It Matters for Real-Time Systems)

Why Physical Processor Topology Matters

Modern multiprocessor systems are not uniform collections of interchangeable cores. Cores may be grouped into sockets, NUMA nodes, cache domains, or chiplets. The location of a workload within that topology can affect how it accesses memory and devices.

Two CPU assignments may contain the same number of cores but behave differently if one keeps the workload within a single hardware locality and the other spreads it across several.

• When assigning cores to a real-time virtual machine, engineers should consider:
• Which socket or NUMA node contains each core
• Which cores share caches
• Whether simultaneous multithreading is enabled
• Where the VM’s memory will be allocated
• Which NUMA node is connected to the required I/O device
• Where device interrupts will be handled

Logical CPU numbers alone do not show these relationships. Configuration should be based on the host’s actual processor and I/O topology.

What Is NUMA?

Non-Uniform Memory Access, or NUMA, is an architecture in which processors have faster access to some areas of memory than others.

Each NUMA node typically contains a group of processor cores and locally attached memory. A core can access memory attached to another node, but doing so requires communication across an interconnect.

For general-purpose workloads, the operating system may balance activity across NUMA nodes to improve overall utilization. Timing-sensitive applications often benefit from a more deliberate arrangement.

Ideally, a real-time virtual machine’s processor cores and memory should be placed within the same NUMA node whenever the workload and available hardware allow it. This reduces dependence on remote memory access and helps make memory behavior more consistent.

NUMA Placement in a Virtualized System

NUMA configuration needs to be considered at both the host and guest levels.

At the host level, physical cores and memory are associated with particular NUMA nodes. At the guest level, the virtual machine may see its own virtual NUMA topology. These views should be configured so that the guest’s resource layout reflects the physical resources supporting it.

Problems can occur when:

• A VM’s vCPUs run on one NUMA node while its memory resides on another
• The VM is distributed across nodes without a clear need
• Memory allocation changes after the system starts
• A passed-through device is attached to a different node from the VM’s cores
• The guest’s virtual topology does not match its physical placement

Cross-node access is not always avoidable or unacceptable. Large workloads may require resources from multiple nodes. The important point is to make that choice deliberately and validate the resulting behavior.

Engineers should also leave adequate memory for the host. Reserving most of a node’s memory for a guest without accounting for host requirements can create memory pressure or force allocations into less suitable locations.

What Is Interrupt Affinity?

Hardware devices use interrupts to request processor attention. Network adapters, storage controllers, timers, data-acquisition devices, and other hardware can generate interrupts as they operate.

By default, the host may distribute interrupts across available cores. If an interrupt is handled on a core reserved for a real-time workload, it can interrupt that workload even when CPU shielding is correctly configured.

Interrupt affinity controls which physical processors are permitted to handle particular interrupts.

For a real-time virtual machine, a typical objective is to:

• Direct unrelated host and device interrupts away from the VM’s cores
• Route required device interrupts to an appropriate, known core
• Keep interrupt handling close to the relevant device and memory
• Prevent automatic balancing services from changing assignments unexpectedly

Interrupt placement requires care. Moving every interrupt away from the real-time cores may not be correct if the VM uses a passed-through device whose interrupt activity is part of the timing-sensitive workload.

The appropriate assignment depends on the device, driver, I/O path, and application.

Device Placement Connects NUMA and Interrupt Configuration

PCIe devices are connected to particular parts of the system. A device may be physically closest to one processor socket or NUMA node.

When a device is assigned directly to a virtual machine, the VM’s CPU and memory placement should be evaluated in relation to that device. A configuration that places the device, processors, and memory within the same NUMA locality can reduce cross-node traffic.

This is particularly important for devices that generate frequent interrupts or transfer large amounts of data.

Before assigning a device to a real-time guest, engineers should determine:

1. Which NUMA node is physically connected to the device?
2. Which cores will run the guest workload and handle its interrupts?
3. Where will the guest’s memory be allocated?
4. Does the driver create additional processing threads?
5. Are any host services still involved in the I/O path?

This is one reason I/O strategy cannot be separated entirely from processor and memory configuration.

Common Configuration Problems

Assigning vCPUs Without Pinning Them

Giving a virtual machine four vCPUs does not necessarily reserve four physical cores. Without explicit placement, those vCPUs may compete with other host or guest work.

Overlapping CPU Assignments

Two virtual machines may be pinned to some of the same cores. This may improve hardware utilization, but it undermines isolation when both machines become active simultaneously.

Shielding CPUs but Ignoring Interrupts

A shielded core may still process device interrupts. The application can therefore experience interruptions even though no unrelated user process is scheduled there.

Separating CPU and Memory Placement

A VM may run on cores from one NUMA node while allocating memory from another. The system will operate, but memory access may depend more heavily on the interconnect.

Ignoring Device Locality

A passed-through device may be attached to a different NUMA node from the guest’s assigned cores. The resulting cross-node traffic can affect I/O behavior.

Allowing Automatic Services to Change the Configuration

Interrupt-balancing, workload-balancing, or power-management services may modify processor behavior after the initial setup. Teams should understand which services remain active and whether their behavior is appropriate for the real-time configuration.

A Practical Configuration Process

A useful process begins with the physical system rather than the virtual-machine settings.

1. Map the Hardware

Document the sockets, NUMA nodes, physical and logical CPUs, shared caches, memory, PCIe devices, and device-to-node relationships.

2. Reserve Resources for the Host

The host still needs adequate processor and memory resources for device management, system services, monitoring, and administration.

3. Assign Physical Cores to the Real-Time VM

Use non-overlapping CPU assignments and keep related cores within an appropriate hardware locality where practical.

4. Place Memory Deliberately

Allocate the guest’s memory in relation to its assigned processors. Avoid unintended remote allocation or migration.

5. Configure Interrupts

Identify the interrupts generated by relevant and unrelated devices. Assign them according to the intended CPU and I/O architecture.

6. Review Device Placement

For passed-through devices, check their NUMA locality and confirm that the guest operating system has the necessary driver support.

7. Control Background Activity

Review host services, power settings, balancing services, scheduled tasks, and other activity that could use the reserved resources.

8. Test the Complete Configuration

Measure the application under representative CPU, memory, network, storage, and I/O loads. Testing only an idle system can hide resource conflicts that appear during normal operation.

9. Record the Configuration

Document CPU assignments, NUMA placement, interrupt affinity, device allocation, firmware settings, and relevant host configuration. This makes the system easier to reproduce and helps identify changes during troubleshooting.

Monitoring Matters After Deployment

Resource isolation should not be treated as a one-time configuration exercise.

Firmware changes, device replacements, operating-system updates, new virtual machines, or changes to host services can affect the system. Even moving a PCIe card to another slot may change its relationship to processors and NUMA nodes.

Monitoring and tracing tools can help engineers examine:

• Which processors are running each workload
• Whether interrupts reach reserved cores
• How processes and threads are scheduled
• Where memory is allocated
• Whether activity crosses NUMA boundaries
• Which system events correspond with an observed application delay

This visibility is particularly important in a virtualized environment because the cause of a delay may exist outside the guest where the application runs.

Resource Isolation Is a System-Level Task

CPU shielding reduces competition for processor time. NUMA-aware placement controls the relationship among processors, memory, and devices. Interrupt affinity determines where device activity is handled.

Each technique addresses a different source of timing variation. Applying only one can leave the others uncontrolled.

A well-configured real-time virtual machine should therefore be evaluated as part of the complete physical system. The guest operating system, host, hypervisor, processor topology, memory architecture, interrupt routing, and I/O devices all contribute to its behavior.

RedHawk KVM-RT provides mechanisms for assigning and controlling these resources, while NightTune can help engineers examine processor use, shielding, interrupt assignments, memory, and NUMA behavior. The final configuration still needs to be designed and tested against the requirements of the specific application.

Related Reading

These principles apply differently depending on the system: Native Real-Time Linux vs. Real-Time Virtualization covers when the added configuration is worth it, Choosing an I/O Strategy for Real-Time Virtual Machines applies interrupt and NUMA placement to specific device paths, and Preserving Legacy Real-Time Applications Through Virtualization addresses it in the context of migrating an existing system.

Frequently Asked Questions:

Does assigning dedicated vCPUs isolate a real-time virtual machine?

Not necessarily. vCPUs must be mapped to physical processor cores, and those cores should be protected from unrelated host and guest activity. Interrupts, memory placement, and I/O resources must also be considered.

Is CPU pinning the same as CPU shielding?

No. CPU pinning associates a process, thread, or vCPU with selected physical CPUs. CPU shielding prevents general system activity from being scheduled on reserved CPUs. Real-time configurations commonly use both.

Does a real-time VM need to fit within one NUMA node?

Not always. Keeping processors and memory within one node can simplify locality and reduce remote access, but larger workloads may require multiple nodes. Any cross-node design should be intentional and tested.

Should all interrupts be moved away from real-time cores?

No. Unrelated interrupts should generally be kept away, but interrupts associated with a device used by the real-time workload may need a deliberate assignment near that workload. The correct placement depends on the device and I/O path.

How can engineers verify that resource isolation is working?

Test the complete system under representative load while monitoring processor assignments, scheduling, interrupt activity, memory placement, and application timing. Repeat the evaluation after material hardware or software changes.