vgpu-device-manager

packaged by Chainguard

Chainguard Container for vgpu-device-manager

The NVIDIA vGPU Device Manager declaratively configures vGPU devices on the GPUs of Kubernetes nodes.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/vgpu-device-manager:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

Chainguard's vgpu-device-manager image is comparable to the NVIDIA vGPU Device Manager image and is designed as a drop-in replacement for it in the NVIDIA GPU Operator. Like the upstream image, it:

• runs as root (UID and GID 0), because it creates vGPU devices through the host's /sys and the GPU Operator runs it as a privileged DaemonSet
• uses nvidia-k8s-vgpu-dm as its entrypoint and /app as its working directory
• sets NVIDIA_VISIBLE_DEVICES=void
• includes nvidia-vgpu-dm, nvidia-k8s-vgpu-dm, and nvidia-mig-parted, which the controller runs for MIG-backed vGPU types

It differs from the upstream image in the following ways:

• BusyBox applets, such as sh and chroot, are installed in /bin and /usr/bin rather than in a separate /busybox directory.
• The image doesn't set the upstream OPENSSL_CONF, OPENSSL_MODULES, and LD_LIBRARY_PATH variables, which point at files of NVIDIA's distroless base image.
• The image includes kubectl, nvidia-mig-manager, and nvidia-container-cli with its libnvidia-container libraries, which come with the mig-parted package.

Prerequisites

The vGPU Device Manager creates vGPU devices through the NVIDIA vGPU Manager, NVIDIA's licensed host driver, so every node it configures needs one. These are typically hypervisor nodes that run KubeVirt virtual machines. Install the vGPU Manager on the host, which needs GPU Operator v26.7.0 or later, or have the GPU Operator deploy it from a vGPU Manager image that you build from NVIDIA's driver package and set in the chart's vgpuManager block, as described in NVIDIA GPU Operator with KubeVirt. Until the vGPU Manager is ready, the GPU Operator's validation init container keeps the vGPU Device Manager waiting.

Getting Started

The NVIDIA GPU Operator deploys the vGPU Device Manager as a DaemonSet on nodes configured for vGPU workloads. Create a values file that enables sandbox workloads and points the vgpuDeviceManager component at the Chainguard image:

cat > values.yaml <<EOF
sandboxWorkloads:
  enabled: true
vgpuDeviceManager:
  enabled: true
  repository: cgr.dev/ORGANIZATION
  image: vgpu-device-manager
  version: latest
  config:
    name: ""
    default: "default"
EOF

Install the GPU Operator with this file:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator --create-namespace \
  --values values.yaml

Then configure a node that runs the vGPU Manager for vGPU workloads, replacing NODE_NAME with its name:

kubectl label node NODE_NAME nvidia.com/gpu.workload.config=vm-vgpu --overwrite

The operator deploys the nvidia-vgpu-device-manager DaemonSet to the node, which applies the default vGPU configuration from the operator's built-in ConfigMap. Its entries select GPUs by device ID. Check the outcome on the node's labels:

kubectl get node NODE_NAME -L nvidia.com/vgpu.config,nvidia.com/vgpu.config.state

The nvidia.com/vgpu.config.state label is success once the selected configuration is applied, and failed when it could not be applied. The DaemonSet pod's logs show the reason.

Configuration

A custom configuration file lets you choose which vGPU types each node gets. The following file defines two layouts for an NVIDIA L4, whose counts come from the upstream example configuration:

cat > config.yaml <<EOF
version: v1
vgpu-configs:
  default:
    - devices: all
      vgpu-devices:
        L4-4Q: 6
  L4-2Q:
    - devices: all
      vgpu-devices:
        L4-2Q: 12
EOF

Validate the file with the image before you deploy it:

docker run --rm -v "$PWD/config.yaml:/config.yaml" --entrypoint nvidia-vgpu-dm \
  cgr.dev/ORGANIZATION/vgpu-device-manager:latest \
  assert --valid-config -f /config.yaml -c L4-2Q

time="..." level=info msg="Selected vGPU device configuration is valid"

Store the file in a ConfigMap in the operator's namespace. The vGPU Device Manager reads it from the config.yaml key:

kubectl create configmap custom-vgpu-config -n gpu-operator --from-file=config.yaml

Point the chart at the ConfigMap by changing the config block of values.yaml:

vgpuDeviceManager:
  config:
    name: custom-vgpu-config
    default: "default"

Apply the change to the release:

helm upgrade gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator --values values.yaml

Nodes without an nvidia.com/vgpu.config label get the default layout. To give a node another layout, label it with the layout's name:

kubectl label node NODE_NAME nvidia.com/vgpu.config=L4-2Q --overwrite

The vGPU Device Manager watches the label, recreates the node's vGPU devices, and updates nvidia.com/vgpu.config.state.

Documentation and Resources

• NVIDIA GPU Operator with KubeVirt
• NVIDIA vGPU Device Manager on GitHub
• NVIDIA vGPU Device Manager on NGC
• GPU Operator Helm chart

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.