# GPU Infrastructure

Phoeniqs Cloud provides NVIDIA H100 GPU acceleration for AI and high-performance workloads, delivered on HGX nodes (8×H100 per node) in our Swiss data centers. This page explains how GPUs are exposed to tenants today, how to schedule GPU workloads, and what is on the roadmap for GPU passthrough to virtual machines.

You do not need a nodeSelector or node label to place GPU workloads. Tenants cannot list nodes at tenant scope, and you don't have to. Instead, request the GPU resource in your pod spec and the Kubernetes scheduler will place the workload on a node that has the requested GPUs available.

apiVersion: v1
kind: Pod
metadata:
  name: gpu-workload
  namespace: my-project
spec:
  containers:
    - name: cuda-container
      image: nvidia/cuda:12.4.1-base-ubi9
      resources:
        limits:
          nvidia.com/gpu: 1   # number of H100 GPUs requested

Today, GPUs are exposed to tenants as the standard nvidia.com/gpu container resource. The NVIDIA GPU Operator runs on the bare-metal nodes (installed and managed by Phoeniqs) and advertises GPUs to the scheduler. This is the supported and tested path for AI training and inference workloads.

Dedicating GPU nodes to VM (vfio-pci) passthrough — not shared with container workloads — is a new feature that requires a different resource type and a different way of loading the NVIDIA operator on the affected nodes.

KubeVirt VM passthrough requires the H100 devices to be registered in the HyperConverged CR's permittedHostDevices with a deviceName that you then reference in the VM spec. The HyperConverged CR is not readable at tenant scope.

At the moment, GPU passthrough to VMs does not work, because using GPU passthrough requires the NVIDIA operator to be loaded in a different way than the current container-focused configuration. As a result, no tenant-facing deviceName is published yet.

Once VM passthrough is enabled for your namespace, the supported deviceNames and the corresponding VM spec snippet will be provided as part of the enablement process. To request enablement, open a service ticket.

GPU interconnect today is validated for container workloads. Intra-node GPUs on an HGX node are connected via NVSwitch/NVLink; an NVLink-Network fabric spanning nodes (e.g. connecting ~100 GPUs to a single VM) has not been tested or made available for VM workloads.

OpenShift ships without a cluster-level default-deny NetworkPolicy. East-west traffic between your VMs and pods is therefore allowed by default, including service ports such as MariaDB on TCP 3306 and DNS.

Because there is no default deny, you should add your own NetworkPolicy objects to block any services that must not be reachable from outside your namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: my-project
spec:
  podSelector: {}
  policyTypes:
    - Ingress

OpenShift's built-in monitoring stack (Prometheus/Grafana) is not currently exposed to tenant namespaces, and you cannot list ServiceMonitor objects or the gpu-operator namespace at tenant scope.

• IaaS Capacity and Node Provisioning
• OpenShift Architecture Overview
• Namespaces, Quotas and RBAC
• Access Your OpenShift AI
• Confidential Computing