OpenShift Virtualization

This destination is in development and not yet generally available. What follows is what it will do.

Primcoat will upload the hardened image to your OpenShift Virtualization cluster through the Containerized Data Importer (CDI) and register it as a DataVolume. The QEMU guest agent is installed during the build, which is what gives the cluster visibility into the running guest.

The one destination with no conversion step

Primcoat’s hardened master is already a QCOW2 disk, and QCOW2 is what the CDI imports — so unlike AWS, Azure, Google Cloud, VMware and Hyper-V, there is no format conversion between the image that was scanned and signed and the image the cluster boots. The bytes that were hardened, scored, and signed are the bytes that land in the DataVolume.

What you will configure

A publish target holds the cluster API endpoint, the credentials, the destination namespace, and the storage class the DataVolume is created against.

The storage class is the field worth thinking about rather than accepting a default: it decides the access mode and provisioner behind the DataVolume, and a class that cannot support the access mode KubeVirt wants for a boot disk will fail at import rather than at configuration time.

Where this sits

OpenShift Virtualization is reached by a build worker inside your own cluster’s network rather than from Primcoat’s infrastructure, for the same reason as vSphere and Hyper-V: the alternative is exposing a cluster API endpoint to the internet. See the platform overview for how that worker is deployed, and the image pipeline for what runs before the upload.

Join the waitlist to hear when this destination lands.