Rob Pankow 
“What replaces the VM template?”
The question usually arrives in the first fortnight of an exit project, from whoever owns provisioning rather than whoever owns storage, and it has three defensible answers. Which one is correct for a given estate is not a matter of taste. It follows from four things a team already knows: how large the images are, how often somebody makes a new machine from one, how many clusters need the same picture, and whether there is already a registry or a build pipeline in the building.
What makes the question harder than it looks is that a VMware® vSphere template was never a single object doing a single job. It was three jobs bundled into one inventory item, sitting on top of a storage behaviour that nobody had to think about. Pull the bundle apart and the decision gets much easier, because the three paths below are good at different parts of it.
What a VM template was actually made of
Three separate jobs, and they separate cleanly once you look for them.
The catalog. A template in vSphere was a published, versioned artifact with a distribution story attached. The content library was the mechanism: publish an image once at one site, subscribe to it from the others, and let the platform push updates outward. Later versions added proper check-in and check-out semantics so a template could be revised without anyone cloning it to a scratch VM and back. This is the job that people miss most and notice last, because it is invisible until the second site needs the same image.
The envelope. OVF and OVA were the portable form: a descriptor that carried the virtual hardware definition, the disk layout, and a set of configurable properties, plus the disks themselves. OVA was the same thing in a single archive. This is what made an image a unit you could hand to somebody, archive, or import somewhere else.
The identity step. A template is by definition not a working machine. Guest customization is what turned one image into many distinct machines: hostname, network configuration, domain join, SSH keys, and on Windows the sysprep pass that gives each clone its own security identifiers. In vCenter this was a stored, named, reusable specification applied at clone time, which is a detail worth holding onto, because the specification being a managed object is the part that does not travel.
Underneath all three sat the thing that actually made the model usable: you could instantiate without copying. Linked clones ran a machine off a delta disk against a read-only base. Instant clones went further and shared memory state too. Nobody described this as a storage feature, because the hypervisor presented it and the datastore just went along with it. It was a storage feature the whole time. That is the sentence this post exists to make, and it is the reason the three paths below differ so much in cost: they differ almost entirely in what the storage layer is asked to do.
Two of the three jobs travel without much argument. The envelope survives as a conversion step, since the tooling that moves machines onto Kubernetes already ingests OVF and OVA and writes the disks into volumes. The identity step survives as cloud-init on Linux and a sysprep answer file on Windows, both of which KubeVirt accepts directly as volumes attached at first boot. What does not survive intact is the stored customization specification as a managed object; it becomes a ConfigMap or a Secret plus whatever templating you already use, which is fine, but it is now yours to version.
The catalog is where the real choice is.
Path one: the image becomes a registry artifact
Package the disk inside a container image, push it to a registry, and let the VM pull from there at start. KubeVirt calls this a containerDisk, and on Red Hat® OpenShift® Virtualization it is the path the shipped templates already use.
The appeal is that the catalog problem disappears into infrastructure you already run. Tags are versions. Registry replication is the subscribed-library behaviour, without vCenter. Image signing, vulnerability scanning, retention policy and RBAC are whatever your registry already enforces, which is usually a good deal more than the old content library offered. For a team that has spent three years building supply-chain controls around container images, extending them to VM images is close to free.
The cost is in the copies. A containerDisk boots ephemerally: the pulled image is read-only and writes land in a disposable layer, which is correct for a stateless appliance and wrong for anything that must survive a reboot. For a persistent machine you import the registry image into a volume first, using the containerized data importer with a registry source, and that import is a full copy of the image for every machine you create. A 12 GB appliance image copied forty times is 480 GB of capacity that used to be one base disk and forty small deltas. It also takes import time per machine rather than the near-instant appearance people were used to.
Registries also dislike very large blobs. A trimmed Linux image is comfortable. A 120 GB Windows image with three years of accumulated software in it is going to make the registry, the node disk cache and everybody’s patience unhappy.
Working out what your image catalog will actually cost after the exit? Talk to us before you pick a path, particularly if the estate has large Windows images or a high instantiation rate, because that is where the capacity maths changes the answer. Talk to a storage architect
The decision has a shape, and it is worth seeing it before reading the other two paths.
Path two: the image stays a volume and you clone it
Keep one master volume per image and make every new machine a clone of it. In Kubernetes terms that is a PVC used as a dataSource, or a VolumeSnapshot of it used the same way, wrapped by a KubeVirt DataVolume so the machine definition stays declarative.
This is the closest thing to what vSphere was doing, and when the storage layer underneath does clones properly it behaves the same way: the clone is a metadata operation, it completes in about as long as the API call takes, and the new volume consumes capacity only as it diverges from the base. Forty machines off one 12 GB image cost 12 GB plus forty sets of changed blocks, not 480 GB. The zero-copy clone is the mechanism, and the detailed storage behaviour of clone-from-base fan-out is covered in the VDI storage post rather than repeated here.
The important caveat is that this property is not guaranteed by the Kubernetes API. dataSource is an interface, not a promise about implementation. A CSI driver is free to satisfy a clone request by reading every block of the source and writing it to a new volume, which is a correct implementation and a slow, expensive one. Two estates running identical manifests can get instant metadata clones on one and a full byte-for-byte copy on the other. If this path is the plan, the question to put to the storage layer is specific: is a clone a metadata operation, and is capacity charged on divergence or on the full volume? The manifests will not tell you.
Where this path is weakest is precisely where path one is strongest. A PVC is not a published artifact. It has no tag, no signature, no subscription mechanism, and no natural way to appear in another cluster. Teams end up building the catalog themselves out of naming conventions, labels and a spreadsheet, or they lean on storage-level replication to get the master volume into the second cluster. That works, but it is a distribution model owned by the storage layer rather than by a registry, and somebody has to decide that is what they want.
This is also the path where simplyblock’s behaviour is most of the argument. Clones are metadata operations against a thin-provisioned pool, capacity is charged on divergence rather than per copy, and the same primitive serves container volumes and VM disks out of one pool, so a mixed estate is not running two storage systems with two capacity models. Cross-cluster replication moves the master volume to the second site without a re-import. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price, which matters here because a clone-heavy catalog is a design that deliberately creates a great many volumes.
One practical note for teams not refreshing hardware this year: the pool’s backing devices are not restricted to local NVMe, so LUNs an existing array already presents can be taken in as capacity underneath simplyblock. Two things must travel with that. Support for non-NVMe devices is newer than the NVMe path and local NVMe remains the production performance recommendation, so treat it as a transition option rather than a greenfield design. And simplyblock formats what it takes in, so the capacity is reused but the data is still migrated. Consuming the array’s capacity, yes; re-presenting its existing LUNs in place, no.
Path three: you stop storing images and build them
The third answer is to keep no image catalog at all. A declarative build definition lives in git, a pipeline turns it into a disk when somebody needs one, and the artifact is discarded afterwards or cached briefly. The catalog becomes the set of build definitions, which is a thing your existing review process already knows how to handle.
For teams that arrived at the exit with a working GitOps practice, this is often the honest answer, and it solves a problem the other two only manage. Images drift. A template that has been revised eleven times over four years contains decisions nobody remembers making, and “rebuild it from source and diff the result” is not a question either of the first two paths can answer. Where a regulator, an auditor or a security team wants provenance for what is on a running machine, a definition in version control is a better answer than a blob with a tag on it.
The cost is time and moving parts. Instantiation goes from seconds to however long a build takes, which is minutes at best, so this path is wrong wherever machines are created on demand by people who are waiting. It also needs build infrastructure that is itself maintained, and the storage layer does almost nothing for you here: every machine gets a freshly written disk, so capacity is consumed per machine exactly as in path one, without path one’s cached pulls.
Most estates that choose this do not choose it for everything. They build the base layers on a schedule, land the output as a master volume or a registry tag, and then use path one or path two for the actual fan-out. The three paths are not mutually exclusive, and the sanest large estates run two of them.
Which leaves the decision itself:
| Path | Capacity per machine | What the catalog is | Choose it when |
|---|---|---|---|
| Registry artifact | Full copy per persistent machine | Registry tags, signing and replication | Images are small, several clusters need them, supply-chain control matters |
| Clone from a master volume | Divergence only, if clones are metadata operations | Naming conventions plus storage replication | Images are large, machines are created often, one or few clusters |
| Build from a definition | Full copy, written fresh each time | Build definitions in version control | Instantiation is rare and predictable, provenance is required |
Table 1: The three paths, and the condition that makes each one correct.
Read the middle column before the last one. The catalog question is the one that gets skipped in planning and then owns somebody’s Thursdays for a year afterwards, because the machinery that published images across sites was part of the platform being switched off and nothing replaces it by default. The capacity column is the one that decides whether the plan survives contact with a large Windows image. And the storage behaviour underneath path two is the only part of this that a manifest will not tell you, which makes it the one worth asking about explicitly while there is still time to choose differently.
Questions and Answers
What actually replaces the vSphere content library after a migration?
Nothing replaces it as a single feature, which is why this needs a decision rather than a lookup. The publishing and distribution job goes either to a container registry, where tags are versions and registry replication distributes images, or to the storage layer, where a master volume is replicated to the other cluster and cloned locally. For estates with large images and frequent instantiation, simplyblock is the better fit for that second model: clones are metadata operations against a thin-provisioned pool, capacity is charged on divergence rather than per copy, and cross-cluster replication moves the master volume without a re-import.
Do OVF and OVA templates still work after the exit?
As an import format, yes. The migration tooling that moves machines onto Kubernetes ingests OVF and OVA, converts the disks, and writes them into volumes, and the storage decisions in that conversion step are worth planning deliberately. What OVF stops being is a live catalog format. After the migration it is a way of getting an image in, not a way of running an image library.
Will a Kubernetes volume clone be as fast as a linked clone was?
That depends entirely on the CSI driver, and the API will not tell you. A clone request expressed as a dataSource can be satisfied by a metadata operation that completes in seconds, or by copying every block of the source volume. Both are correct implementations of the same manifest. Ask the storage vendor directly whether clones are metadata operations and how capacity is charged against them, because this single answer changes the capacity plan and the provisioning experience more than any other choice in the catalog design.
Where does guest customization go?
Onto the machine, at first boot. Linux uses cloud-init and Windows uses a sysprep answer file, both supplied to KubeVirt as volumes attached to the machine definition. The part that does not survive is the stored customization specification as a managed vCenter object. There is no equivalent registry of reusable specifications, so the spec becomes a ConfigMap or a Secret rendered by whatever templating the team already runs, and versioning it is now the team’s responsibility rather than the platform’s.
Is ODF a reasonable choice for a clone-heavy image catalog?
Ceph is a good option when performance is not the main goal, and that fairness applies here too. The thing to check is the shape of the cost rather than the capability: replication-based data protection means a raw-to-effective ratio around 3:1 at FTT1 against roughly 1.25:1 for erasure coding, and a catalog design that deliberately creates many volumes multiplies whatever that ratio is. Those figures come from simplyblock’s own capability comparison, based on publicly available information as of September 2026, and are not independently verified. For a low-churn catalog on an existing cluster the difference may not justify a change; for high fan-out it usually shows up in the hardware bill.
