Preparing a Golden Image for Cloud Manager
Image preparation happens in your hypervisor or cloud provider’s console; Cloud Manager references the resulting image when provisioning new instances. This article covers the Thinfinity-specific aspects of Golden Image preparation for on-premises hypervisors — VMware vCenter, Hyper-V Manager, the Proxmox UI, oVirt Engine, and Verge.IO: what the image must contain to be compatible with Cloud Manager, which model fields reference it, and best practices to make the image safe to clone at scale. For the hypervisor procedure itself (snapshot, template conversion, VM Recipe creation), refer to your vendor’s documentation — links are provided at the end of this article.
For conceptual background, see Golden Images: Concept and Role.
What Cloud Manager Requires Inside the Image
The image must satisfy four requirements before it can be cloned into working Cloud Manager instances:
| Requirement | Why it matters |
|---|---|
| Thinfinity® Workspace Virtualization Agent installed and running | Clones without the agent boot but never register with the broker, so users cannot connect. See Configuring the Thinfinity Agent for Workspace. |
| Hypervisor guest tools / drivers | VMware Tools (VMware), Hyper-V Integration Services (Hyper-V), QEMU Guest Agent (Proxmox, Oracle KVM, Verge.IO), and VirtIO drivers (Proxmox, Oracle KVM, Verge.IO) are required for the hypervisor to communicate cleanly with each clone. Install before capture. |
| OS generalization | Each clone must boot with a unique machine identity. On Windows, run sysprep /generalize /oobe /shutdown and capture without powering back on. On Linux, use cloud-init --clean or reset /etc/machine-id. Without generalization, every clone receives the same SID/hostname and the pool behaves unpredictably. |
| No machine-bound state | Domain-joined state, machine-licensed software, locally cached user data, and unique credentials must be applied after clone, not baked into the image. Configure these via Group Policy, MDM, or post-deploy scripts. |
After running sysprep /generalize, do not power the VM on before capturing the snapshot or template. Booting a sysprepped VM completes its OOBE pass and consumes the generalization — the resulting image will produce non-unique clones. If this happens, you must re-run sysprep or rebuild the image.
How Cloud Manager Identifies the Image
After the image is captured in your hypervisor, Cloud Manager references it through one or two text fields in the Parameters tab of the model editor (or Parameters step of the wizard). The exact field names depend on the provider’s built-in:
| Provider | Field(s) in the wizard | What you enter |
|---|---|---|
| VMware (ESXi / Horizon) | VM Name to clone (host_template) |
The name of the VM template registered in vCenter. |
| Microsoft Hyper-V | Image Location (image_location) + Image Name (image_name) |
Host path containing the source VHDX and the VHDX filename (without extension). Default location is D:\MODELS. |
| Proxmox VE | VM name to clone (host_template) |
The name of the VM template registered in the Proxmox node. |
| Oracle KVM (oVirt / OLVM) | Custom Terraform only — define inputs in your template | No built-in available; reference the oVirt Template by name in your own Custom Terraform Templates. |
| Verge.IO | Custom Terraform only — define inputs in your template | No built-in available; the Verge.IO model clones from a VM Recipe — reference the Recipe through the input variables in your own Custom Terraform Templates. |
The credential account configured in Cloud Manager must have read access to the datastore, cluster, host, or storage domain where the image is registered. See the credentials article for your hypervisor under Manage Credentials.
Best Practices
- Treat the image as immutable. Once an image is in use by a model in Production, do not edit it in place. Build a new image, register it in your hypervisor under a new name/version, and roll the model forward through a new Testing/Staging version. See Model Versioning.
- Version the image name. Use a naming convention that includes a version or date (for example,
Win11-Office-2026-05orRHEL9-base-v3) so administrators can identify the image at a glance in both the hypervisor console and the Cloud Manager model editor. - Disable scheduled tasks that race at first boot. Windows Update, antivirus initial scans, and OEM startup tasks running simultaneously across dozens of clones at boot can saturate the hypervisor. Defer or disable them in the base image and trigger them on a staggered schedule post-clone.
Failures from skipping generalization, omitting the Workspace Agent, or referencing an image the credential account cannot read surface only at deployment time — usually as instances that boot but never become Available.
Per-Hypervisor Reference
For the procedure to build, generalize, and capture an image, refer to your hypervisor vendor’s documentation — the mechanism and on-disk format differ enough that the vendor docs are the authoritative source.
| Hypervisor | Capture mechanism | Vendor documentation |
|---|---|---|
| VMware (ESXi / Horizon) | Convert VM to Template in vCenter | VMware Docs |
| Microsoft Hyper-V | Export VM or copy generalized VHDX to the host path | Microsoft Learn — Hyper-V |
| Proxmox VE | Convert VM to Template | Proxmox VE Documentation |
| Oracle KVM (oVirt / OLVM) | Make Template from a prepared VM | oVirt Documentation |
| Verge.IO | Create a VM Recipe | Verge.IO Documentation |
What’s Next
- Update a Model to Use a New Golden Image — Point an existing model at a refreshed image
- Create a Model Using a Built-in Blueprint — Wire the image into a new model
- General Settings — Full field reference for each provider’s built-in
See Also
- Golden Images: Concept and Role
- Model Versioning — Roll out a new image safely through Testing → Staging → Production
- Custom Terraform Templates — How to reference an image in a custom template (required for Oracle KVM)