Golden Images: Concept and Role
In Thinfinity® Cloud Manager, a Golden Image is a pre-prepared base virtual machine that Cloud Manager clones to provision new instances on on-premises hypervisors. Rather than installing and configuring each VM individually at deployment time, administrators prepare a single reference VM — the Golden Image — and Cloud Manager uses it to stamp out consistent, identical instances on demand.
Golden Images apply to on-premises hypervisors only. Public cloud providers and Kubernetes use different mechanisms (provider images and container images, respectively).
What Is a Golden Image?
A Golden Image is a fully configured, production-ready VM captured as a template or snapshot in your hypervisor. It typically includes:
- The operating system, fully patched and configured.
- All required applications pre-installed.
- Security policies, registry settings, and system configurations applied.
- The Thinfinity® Workspace Virtualization Agent — required so that cloned instances register with the broker.
The Thinfinity Virtualization Agent must be installed and running inside the source VM before the image is captured. Instances provisioned from a Golden Image without the agent will not register with the broker and will not be available for user sessions.
When a VDI/DaaS Model that points at a Golden Image is deployed, Cloud Manager instructs the hypervisor to clone the image for each new instance. All instances derived from the same Golden Image share the same baseline configuration. Managed VMs do not use Golden Images — they register pre-existing VMs as-is, with no clone step.
Where Golden Images Apply
| Path | Uses Golden Images? | Notes |
|---|---|---|
| Cloud providers • (AWS, Azure, GCP, IONOS, Oracle Cloud) | No | Models reference provider-managed images (AMIs, Azure images, GCP images, etc.) directly through template parameters. These are not Golden Images in the Cloud Manager sense. |
| On-premises hypervisors • (VMware, Hyper-V, Proxmox, Oracle KVM, Verge.IO) | Yes | A Golden Image must be prepared in the hypervisor before a model can be created. The model references the Golden Image by name or path. |
| Kubernetes | No | Pods are defined via YAML and use container images, not VM Golden Images. |
For the per-hypervisor preparation procedure, see Create a Golden Image.
Golden Images vs. Snapshots
Golden Images and VM snapshots are related concepts but serve different purposes.
| Concept | Purpose | Scope |
|---|---|---|
| Golden Image | Base for creating new VM instances | Used at provisioning time — defines what new VMs look like |
| Snapshot | Point-in-time restore point for an existing VM | Used for backup or rollback of a running instance |
A Golden Image is a source, not a backup. Taking a snapshot of a running instance does not produce a Golden Image. Conversely, updating a Golden Image has no effect on instances already running — only new instances provisioned after the update use the new image.
Modifying a running instance (installing software, changing settings) does not update the Golden Image. Changes made to live instances are not automatically reflected in new deployments. To update the standard environment, prepare a new Golden Image, point a new model version at it, and roll the model forward. See Update a Model to Use a New Golden Image.
The Role of Golden Images in the Model Lifecycle
Golden Images are referenced at the model level — in the model’s provider-specific parameters (the Parameters step of the creation wizard). The relationship between a Golden Image and the model lifecycle is:
Hypervisor Template / VM Recipe (Golden Image)
└── referenced by → Model (a specific version)
└── produces → Deployment
└── contains → Instances
When you create a model on an on-premises hypervisor, you choose a Golden Image as the clone source. When the model is deployed, every instance is provisioned by cloning that image.
When you need to update the standard environment, the recommended workflow is:
- Boot a reference VM from the current Golden Image and apply your updates (patches, new applications, configuration changes).
- Generalize the VM (sysprep on Windows, equivalent on Linux) and capture a new Golden Image in the hypervisor.
- Create a new version of the model pointing at the new Golden Image.
- Test the new version using the Testing or Staging state.
- Promote the version to Production to apply the new image to future deployments.
This workflow ensures that running instances are not disrupted while the update is validated. See Model Versioning for the version state machine.
Provider Considerations
Each on-premises hypervisor uses a slightly different format for Golden Images.
| Hypervisor | Golden Image format |
|---|---|
| VMware (ESXi / Horizon) | VM template on the vSphere datastore (created via Convert to Template in vCenter). |
| Microsoft Hyper-V | VHD or VHDX file exported or referenced by path on the Hyper-V host. |
| Proxmox VE | Proxmox VM template (a VM converted to template status). Referenced by name. |
| Oracle KVM (oVirt / OLVM) | oVirt Template entry created from a prepared VM in the cluster. Referenced by name. |
| Verge.IO | VM Recipe registered in the Verge.IO environment. |
The image must be registered in your hypervisor before it can be referenced in a Cloud Manager model. Cloud Manager does not upload or store raw disk files — it references images that already exist in your hypervisor.
Ensure the Golden Image is accessible to the credential account configured in Cloud Manager. Images stored in a datastore, cluster, or host that the credential account cannot read will cause provisioning failures.
Update Strategy
Golden Images themselves are not versioned in Cloud Manager — versioning lives at the model level. The recommended pattern is:
- Treat Golden Images as immutable. Once an image is in use, do not edit it in place. Capture a new Golden Image instead.
- Use model versioning to roll out changes. Create a Testing model version pointing at the new image, validate it, then promote through Staging to Production.
- Roll back by reverting the model. If the new image causes issues, revert the model version (or import a previously exported version) to point at the previous image.
For step-by-step procedures, see:
What’s Next
With the Golden Image concept in mind, you can proceed to:
- Supported Providers and Hypervisors — understand the full list of environments where Cloud Manager can provision compute resources.
- Create a Model Using a Built-in Blueprint — the fastest path to a working VDI model.
- Create a Golden Image — step-by-step guide to preparing and capturing a Golden Image.