live wire
▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸SECURITY · Red Hat Hardened Images fixes Moderate libpng denial-of-service flawRed Hat▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸SECURITY · Red Hat Hardened Images fixes Moderate libpng denial-of-service flawRed Hat
upstreambeat.ai
guidePLATFORM

Red Hat validates 64 MI300X GPU slices on OpenStack Services on OpenShift

Eight MI300X GPUs exposed 64 schedulable SR-IOV virtual functions, while Red Hat documented performance, topology and production-support boundaries.

Eight GPUs branching into 64 virtual functions on OpenShift.
Chart: figures from the story
By The News Desk· Oct 1, 2026the quick take — two AI hosts go live when you do

Red Hat has validated a high-density AMD Instinct MI300X virtualization design for Red Hat OpenStack Services on OpenShift, showing that eight physical accelerators can become 64 schedulable SR-IOV virtual functions for tenant virtual machines.

What changed

The test system ran Red Hat OpenStack Services on OpenShift 18.0 FR5 with RHEL 9.6 compute nodes. AMD GPU-IOV Manager placed each MI300X in CPX mode, exposing eight virtual functions per device. Nova and Placement inventoried those VFs as PCI resources, while VFIO and libvirt attached them directly to guests.

Red Hat exercised the maximum-density layout of 64 VMs with one VF each. It also passed configurations with eight, 16 and as many as 32 VFs assigned to one VM; a single VM with all 64 VFs remains under investigation because of virtual-IOMMU behavior at very high PCI passthrough counts.

For the primary BabelStream operations, the virtualized configurations delivered about 96% to 99% of the bare-metal memory-bandwidth baseline. Repeated lifecycle runs also passed: the 64-VM layout completed 100 boot-and-shutdown cycles, with VF allocation and reclamation verified and no VF leaks observed in completed tests.

Who it affects

The design targets OpenStack platform teams that want better utilization and hardware-backed isolation for independent AI and HPC workloads. Each CPX VF exposes about 24 GB of VRAM, making the pattern a fit for inference services, embedding generation, retrieval-augmented generation and isolated research jobs that do not need an entire 192 GB MI300X.

The boundary is just as important as the density result. In the tested configuration, IOMMU isolation blocked direct peer-to-peer DMA between VFs. CPU-to-GPU transfers remained available, but tightly coupled multi-GPU applications that depend on high-bandwidth P2P communication may need physical-GPU assignment or bare metal. Placement also matters: VFs sharing one physical GPU contend for its resources.

What to do

Red Hat points operators to the MI300X Validated Architecture in the OpenStack K8s Operators repository and recommends beginning with one GPU-backed VM before scaling. Configure Nova with the VF product ID 74b5, not the physical-function ID, and validate the application's memory, topology and communication requirements.

Do not turn the lab procedure into a production shortcut. The validation used a lab-built DKMS GIM package, and Red Hat says installing GIM with DKMS directly on EDPM hosts is not a supported production workflow. Production deployments should use the documented Red Hat and AMD driver-delivery and support path.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk