Pooling Strategies

Thinfinity® Cloud Manager uses a pooling system to determine how virtual machine instances are allocated to users at connection time. Choosing the right pooling strategy directly impacts user experience, resource utilization, and cost efficiency.

This article explains the available pooling strategies, how they interact with the model’s assignment configuration, and when to use each one.

Pooling Concepts

Three settings work together to define how a model serves users:

These settings are configured in the General tab of the model editor. Allow Pool Mode is the master toggle; when it is enabled, the Pool Mode dropdown appears with the available pooling strategies. Allow Dynamic Assignment sits below Connection Mode as a separate toggle. For the full reference on these and related options, see Provisioning and Pooling Options.

Sharing Modes

The combination of Allow Pool Mode, Pool Mode, and Allow Dynamic Assignment produces three practical sharing modes.

Session-Based (Shared Pool)

Allow Pool Mode = ON, Pool Mode = Breadth First or Depth First. When Allow Pool Mode is ON, the Allow Dynamic Assignment toggle is automatically disabled in the model editor and its value is ignored by the broker — session-based pooling owns the routing decision.

Instances are shared across users. When a user connects, Cloud Manager assigns them to an available instance from the pool. Multiple sessions can run on the same instance, up to the Max users per instance limit configured on the model.

Best for:

• Task workers with consistent, lightweight workloads.
• Environments where personalization is not required.
• Maximizing VM density and reducing cloud spend.

Key behavior:

• Multiple sessions run on the same instance, subject to the per-instance capacity.
• No persistent user state is stored on the VM between sessions.
• The number of running instances is governed by the model’s deployment trigger and (optionally) by the Staged Power On/Off policy, which scales running instances up and down based on user occupancy.

Dedicated Dynamic (1:1, Automated)

Allow Pool Mode = OFF, Allow Dynamic Assignment = ON.

Each user is assigned a dedicated instance the first time they connect, and the broker remembers the assignment. The same user always returns to the same VM, but the initial choice is automatic.

Best for:

• Knowledge workers who require a personalized desktop environment.
• Use cases where application state, user profiles, or local data must persist between sessions.
• Compliance scenarios requiring user-to-VM traceability.

Key behavior:

• Each instance is reserved for one user once assigned.
• The pool grows by one instance per new user (subject to Max Instances).
• A user cannot be served by another instance even if their assigned one is unavailable.

Dedicated Manual (1:1, Pre-pinned)

Allow Pool Mode = OFF, Allow Dynamic Assignment = OFF.

An administrator explicitly binds users to instances using the Manage Users dialog. The broker only routes users to instances they have been bound to.

Best for:

• Strictly governed access where every user-to-VM mapping is decided up front.
• Specialized hardware or licensed software that must remain on a specific VM.
• Audit-driven environments.

Key behavior:

• Users not bound to an instance receive a connection error.
• Pool size is fixed by the administrator; no dynamic growth.

For the manual binding procedure, see Manually Assign an Instance to a User.

Pool Modes (Session-Based)

When Allow Pool Mode is enabled, the Pool Mode dropdown becomes available with two options — Breadth First and Depth First — that determine which available instance receives the next session.

Breadth First

Distributes users across all available instances as evenly as possible. Each new connection goes to the instance with the fewest active sessions.

Use when:

• You want to spread load evenly across all running VMs.
• Fault isolation is a priority — limiting the blast radius if a single VM fails.
• Workloads are consistent and do not benefit from session co-location.

Example: With 3 instances and 6 users, Breadth First assigns 2 sessions to each instance.

Depth First

Fills each instance to capacity before moving to the next. New connections go to the instance with the most active sessions that still has capacity.

Use when:

• Minimizing the number of running instances is the priority (cost optimization).
• You want to keep some instances idle so they can be powered off.
• Workloads are compatible with higher session density per VM.

Example: With 3 instances (capacity 4 each) and 6 users, Depth First fills the first instance with 4 sessions before using the second.

Pooling Disabled

When Allow Pool Mode is OFF, the Pool Mode dropdown is not shown — there is no session-based pooling. Each instance serves at most one user. Disabling Allow Pool Mode is the prerequisite for 1:1 dedicated assignment, in both the Dynamic and Manual variants described above.

Choosing a Strategy

Use the following table as a quick reference.

When Allow Pool Mode is ON, the Allow Dynamic Assignment toggle is greyed out and its value is ignored — pool routing supersedes per-user assignment.

Pool Sizing

The pool size — the number of instances running at any given time — is not fixed. It is shaped by:

• Initial Instances, Lazy Instances, and Max Instances in the model’s Deploy tab — see Provisioning and Pooling Options.
• The Deployment Trigger — On Demand, Scheduled, or Both.
• The Staged Power On/Off policy (available when Allow Pool Mode is enabled) — keeps a calibrated number of instances running based on per-VM occupancy. See Power and Scheduling Settings.

The interaction between pool mode and these sizing controls determines both performance (response time when a new user connects) and cost (how many instances are running when demand is low).

See Also

• Choosing a Compute Path
• Core Entities
• Provisioning and Pooling Options
• Power and Scheduling Settings — Staged Power On/Off
• Manually Assign an Instance to a User