Azure Linux version
All currently supported versions used as the AKS Pod Sandboxing (Kata) host — reproduced on node image AKSAzureLinux-V3katagen2-202607.09.0 (July 2026).
Deployment / platform
Is your feature request related to a problem? Please describe.
The virtual CPU presented to the Kata guest by Cloud Hypervisor is limited to the x86-64-v2 feature level, even when the underlying host CPU fully supports x86-64-v3. As a result, any container image whose userspace is compiled for the x86-64-v3 microarchitecture baseline fails to start inside a sandboxed pod.
This is increasingly common: RHEL 10 / UBI10-based images ship a glibc compiled with -march=x86-64-v3, and glibc's dynamic loader performs a hard hardware-capability check at process startup. On a v2 guest it aborts immediately, before any application code runs:
Fatal glibc error: CPU does not support x86-64-v3
Concrete reproduction:
- Host node:
Standard_D4s_v6 — Intel Xeon Platinum 8573C (Emerald Rapids). The host supports x86-64-v3 (AVX2, FMA, etc.).
- Runtime: RuntimeClass
kata-vm-isolation (Cloud Hypervisor).
- Observed guest CPU (
/proc/cpuinfo from inside a sandboxed pod):
- Brand string passed through verbatim:
INTEL(R) XEON(R) PLATINUM 8573C
- Present:
avx, bmi1, bmi2, f16c, movbe
- Missing:
avx2, fma — exactly the two features that separate x86-64-v2 from x86-64-v3.
- A minimal RHEL10/UBI10-based image run under
kata-vm-isolation exits 127 with the glibc error above. The same image runs fine under the runc RuntimeClass on the same node (host CPUID passes through), but that sacrifices the VM isolation that Pod Sandboxing exists to provide — so runc is not an acceptable workaround for sandboxed workloads.
- Updating to the July 2026 node image did not change the exposed guest feature set; the guest remains at v2.
The core issue is that the guest CPUID is synthesized/normalized by the VMM and the host's genuine v3 capabilities never reach the guest, so workloads must be able to run at v2 or they cannot be sandboxed at all.
Describe the solution you'd like
On hosts whose physical CPU supports x86-64-v3, expose the corresponding CPU features (notably AVX2 and FMA, ideally the full v3 set: AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, OSXSAVE) to the Kata guest via the Cloud Hypervisor CPU model — either through host-model passthrough or a v3-capable CPU template. This would let v3-baseline container images run inside Pod Sandboxing without loss of isolation.
An opt-in mechanism (e.g. a supported RuntimeClass variant or a documented, allow-listed pod/hypervisor annotation) would be an acceptable alternative to changing the default, since not all nodes in a pool are guaranteed to be v3-capable.
Describe alternatives you've considered
- Run the workload under
runc — works because host CPUID passes through, but drops the VM isolation Pod Sandboxing provides. Not acceptable for workloads that require sandboxing.
- Rebuild every affected image on a v2 base (e.g. UBI9 / Azure Linux) — viable per-image, but does not scale to third-party/vendor images the user does not control, and is the opposite of the ecosystem's direction as more images rebase onto RHEL10/UBI10.
- Setting
cpu_features via Kata/Cloud Hypervisor config or pod annotations — not available on managed AKS: cpu_features is a QEMU-only setting (AKS uses Cloud Hypervisor), and hypervisor annotations are gated by enable_annotations / containerd pod_annotations allow-lists that are not user-editable on managed nodes.
Additional context
Related history in this repository shows the x86-64 baseline has been actively managed, and Azure Linux itself has standardized on v2 — which appears to align with (and effectively formalize) the v2 ceiling of the Kata guest:
This request is essentially the mirror image of that decision: rather than lowering all software to v2, allow the guest to expose v3 where the host hardware already supports it, so that v3-baseline images can be sandboxed.
Azure Linux version
All currently supported versions used as the AKS Pod Sandboxing (Kata) host — reproduced on node image
AKSAzureLinux-V3katagen2-202607.09.0(July 2026).Deployment / platform
kata-vm-isolationRuntimeClass, Cloud Hypervisor VMM)Is your feature request related to a problem? Please describe.
The virtual CPU presented to the Kata guest by Cloud Hypervisor is limited to the x86-64-v2 feature level, even when the underlying host CPU fully supports x86-64-v3. As a result, any container image whose userspace is compiled for the x86-64-v3 microarchitecture baseline fails to start inside a sandboxed pod.
This is increasingly common: RHEL 10 / UBI10-based images ship a glibc compiled with
-march=x86-64-v3, and glibc's dynamic loader performs a hard hardware-capability check at process startup. On a v2 guest it aborts immediately, before any application code runs:Concrete reproduction:
Standard_D4s_v6— Intel Xeon Platinum 8573C (Emerald Rapids). The host supports x86-64-v3 (AVX2, FMA, etc.).kata-vm-isolation(Cloud Hypervisor)./proc/cpuinfofrom inside a sandboxed pod):INTEL(R) XEON(R) PLATINUM 8573Cavx,bmi1,bmi2,f16c,movbeavx2,fma— exactly the two features that separate x86-64-v2 from x86-64-v3.kata-vm-isolationexits 127 with the glibc error above. The same image runs fine under theruncRuntimeClass on the same node (host CPUID passes through), but that sacrifices the VM isolation that Pod Sandboxing exists to provide — soruncis not an acceptable workaround for sandboxed workloads.The core issue is that the guest CPUID is synthesized/normalized by the VMM and the host's genuine v3 capabilities never reach the guest, so workloads must be able to run at v2 or they cannot be sandboxed at all.
Describe the solution you'd like
On hosts whose physical CPU supports x86-64-v3, expose the corresponding CPU features (notably
AVX2andFMA, ideally the full v3 set:AVX,AVX2,BMI1,BMI2,F16C,FMA,LZCNT,MOVBE,OSXSAVE) to the Kata guest via the Cloud Hypervisor CPU model — either through host-model passthrough or a v3-capable CPU template. This would let v3-baseline container images run inside Pod Sandboxing without loss of isolation.An opt-in mechanism (e.g. a supported RuntimeClass variant or a documented, allow-listed pod/hypervisor annotation) would be an acceptable alternative to changing the default, since not all nodes in a pool are guaranteed to be v3-capable.
Describe alternatives you've considered
runc— works because host CPUID passes through, but drops the VM isolation Pod Sandboxing provides. Not acceptable for workloads that require sandboxing.cpu_featuresvia Kata/Cloud Hypervisor config or pod annotations — not available on managed AKS:cpu_featuresis a QEMU-only setting (AKS uses Cloud Hypervisor), and hypervisor annotations are gated byenable_annotations/ containerdpod_annotationsallow-lists that are not user-editable on managed nodes.Additional context
Related history in this repository shows the x86-64 baseline has been actively managed, and Azure Linux itself has standardized on v2 — which appears to align with (and effectively formalize) the v2 ceiling of the Kata guest:
feat(azurelinux-rpm-config): set x86_64 cpu level to v2(hardcodes the x86_64 baseline to v2; notes v2 is the supported-hardware baseline). This same change removed the upstream RHEL macro%[0%{?rhel} > 9 ? "-v3"]that causes RHEL10-based builds to target v3.gcc: set baseline architectures to x86-64-v3 and armv8.1-a(earlier attempt to raise the baseline to v3).gcc: revert x86-64-v3 baseline(full revert of gcc: set baseline architectures to x86-64-v3 and armv8.1-a #8846).This request is essentially the mirror image of that decision: rather than lowering all software to v2, allow the guest to expose v3 where the host hardware already supports it, so that v3-baseline images can be sandboxed.