note that this problem occurs only on nodes where SMT is enabled (enabled by default on most Intel processors).

I'm closing it as not-a-bug, let me explain why.

There are 3 levels of resource allocations:
1) The guest's virtual topology
2) The Pod's resources
3) The host's resources

As part of our VM manifests, we support the first two levels. For example, a VM creator can decide to define the guest with 1 socket, 4 cores and 2 threads, and the pod to be defined with 4 CPUs. However, we do not have any support for deciding how the host will provide these resources to the pod.

Actually, the error comes from Kubernetes' CPU Manager's policies. I think it was added here [1][2][3]. In any case, components like CPU Manager and OpenShift's Performance Addon Operator are responsible of configuring how the pods will be allocated with host resources.

For this reason, this is outside of CNV's scope and needs to be fixed elsewhere. We can consider to reach out to upstream Kubernetes or Openshift's PAO for a fix from their side.
I would personally love to help pushing this into Kubernetes if we think it's the right path forward. But in any case, this is IMO a feature request more than a bug.

In the meantime, a workaround is simple: to allocate one more CPU. This is not a bad workaround IMO as (with the right policy from the other components I mentioned) it would just mean that the second hyperthread from the same core would stay empty, keeping the high performance needed for such VMs.

Another important note: there is no relation between the guest's virtual topology and the host's topology. These two are completely independent of one another.

[1] https://github.com/kubernetes/enhancements/issues/2625
[2] https://github.com/kubernetes/enhancements/pull/2626
[3] https://github.com/kubernetes/kubernetes/pull/101432

Under the justification that both RT workloads and DPDK will allocate an odd number of PCPUs by default, this issue is unavoidable. Thus our out-of-the-box behavior is problematic. Re-opening this BZ because of that.

High performance VMs, such as VMs using DPDK or realtime are sensitive to interference from neighboring workloads.

It is possible to define the kubelet’s CPU manager policy to static - `full-pcpus-only`[1], so it would only allocate full physical cores - in nodes with SMT enabled, that means allocating both threads.
The implication is that pods with an odd number of CPUs are rejected by the kubelet after being scheduled to the node - emitting the following event:

“SMT Alignment Error: requested 9 cpus not multiple cpus per core = 2”

We have created an automated test (kubevirt-dpdk-checkup) that creates two VirtualMachineInstance and runs DPDK traffic between them.

The two VMIs the checkup creates have an even number of CPUs.
Before we have started using KubeVirt’s IsolateEmulatorThread[2] option, the checkup had suffered from packet losses.

When adding the IsolateEmulatorThread option, KubeVirt adds an additional CPU to the virt-launcher pod’s requests and limits, to be used by QEMU.
This in combination with the full-pcpus-only CPU manager policy, causes the virt-launcher pod to be rejected.

As a workaround we have disabled SMT on our worker node.
This workaround is unacceptable by our stakeholders.

We wish to create a solution that will cause KubeVirt to add extra CPUs to the virt-launcher pod so that the total sum of CPUs will be even.
This behavior is wanted only when the full-pcpus-only CPU manager policy is enabled.


We use the following MCP:
```
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-dpdk
  labels:
    machineconfiguration.openshift.io/role: worker-dpdk
spec:
  machineConfigSelector:
    matchExpressions:
      - key: machineconfiguration.openshift.io/role
        operator: In
        values:
          - worker
          - worker-dpdk
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-dpdk: ""
```

We use the following PerformanceProfile:
```
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: profile-1
spec:
  cpu:
    isolated: 4-39,44-79
    reserved: 0-3,40-43
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 32
      node: 0
      size: 1G
  net:
    userLevelNetworking: true
  nodeSelector:
    node-role.kubernetes.io/worker-dpdk: ""
  numa:
    topologyPolicy: single-numa-node
```

[1] https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy-options

[2] https://kubevirt.io/user-guide/virtual_machines/dedicated_cpu_resources/#requesting-dedicated-cpu-for-qemu-emulator

design draft: https://github.com/kubevirt/community/pull/247

implementation PR draft: https://github.com/kubevirt/kubevirt/pull/10593

backport PR to 4.15
https://github.com/kubevirt/kubevirt/pull/10757