VDI/DaaS Models
VDI/DaaS models are the core provisioning unit of Thinfinity® Cloud Manager for creating new virtual desktop or application infrastructure. A model is a reusable configuration that defines everything needed to deploy a virtual desktop or application instance: the cloud provider and credentials, the compute profile, the OS image, network and access settings, and the lifecycle rules that govern how instances are created, powered, and destroyed. To register existing VMs already running in your infrastructure rather than create new ones, see Managed VMs instead.
When a user connects through an Access Profile, Cloud Manager uses the associated model to provision or assign a matching instance automatically. This separation between the model definition and the running instance allows administrators to control the entire fleet from a single, consistent configuration.
Model State
Each model has a state that controls whether it can be operated on. Model state is shown in the header strip below the Instances and Deployments tabs — an Inactive model displays a forbidden-overlay icon next to its name. State can be changed in two places: through the contextual action button in the same header strip (its tooltip reads Activate or Inactivate depending on the current state) or through the State field in the General section of the model editor.
| State | Meaning |
|---|---|
| Active | The model is operational. New deployments can be created from it; pool instances can be scaled and managed normally. |
| Inactive | The model is paused. New deployments are blocked. Existing instances continue to run but the model is excluded from on-demand provisioning. |
| Error | The model has a structural problem (for example, an unreachable provider or a malformed template). Operations on it are paused until the error is resolved. |
Model state is independent of versioning. A model can have several versions in different states (Testing / Staging / Production) — see Model Versioning.
Model Types
A model captures the type of resource to create, the provider parameters, the pool sizing, and the lifecycle policies — when Cloud Manager runs the model, it produces the corresponding resources on demand or on a schedule.
Two creation paths are available from the wizard:
| Path | Resource Created | Notes |
|---|---|---|
| VDI/DaaS Model | New VMs in the selected provider | Default path. Uses a Built-in blueprint or a Custom Terraform template. |
| Kubernetes Model | New pods in a Kubernetes cluster | Defined through a Kubernetes YAML configuration in the wizard’s K8S Parameters step. |
For on-premises hypervisors (VMware, Hyper-V, Proxmox, Verge.IO, Oracle KVM), the VDI/DaaS Model path provisions VMs by cloning a Golden Image you have prepared in advance.
For a comparison of when to choose Built-in versus Custom Terraform within the VDI/DaaS Model path, see Custom Terraform Templates.
What’s in This Section
| Article | Description |
|---|---|
| Create a Model Using a Built-in Blueprint | Step-by-step wizard walkthrough |
| Kubernetes Models | Create a model that brokers sessions to Kubernetes pods, and manage those pods |
| Model Settings Reference | Index of model settings articles, with the wizard ↔ editor mapping |
| General Settings | Provider selection, compute profile, and provider-specific parameters |
| Provisioning and Pooling Options | Connection mode, pool mode, deployment trigger, and instance count |
| Power and Scheduling Settings | When instances power on and off |
| Destroy Settings | When instances are automatically destroyed |
| Custom Terraform Templates | Infrastructure-as-code model creation |
| Golden Images | Base VM images for on-premises providers |
| Model Versioning | Testing, Staging, and Production version workflow |
| Export and Import Models | Back up and migrate model definitions |
| Delete a Model | Remove a model and its deployment records |
See Also
- Managed VMs vs. VDI/DaaS Models — Decide which approach fits your use case
- Pooling Strategies — Session-based vs. 1:1 assignment
- Deploy an Instance — Start deploying instances from a model
- Credentials — Configure cloud provider credentials before creating a model