When you click “Deploy Virtual Machine” in Apache CloudStack, you trigger a cascade of intelligent placement decisions. Behind that single click, CloudStack evaluates every layer of the infrastructure — from zone to pod to cluster to host to storage — before choosing the most optimal location for your new instance.

This post is a storytelling walkthrough of that journey, inspired by the “Where’s My Instance?” session. We’ll explore the deployment planners, VM allocation algorithms, and the logical flow that guides CloudStack’s decision-making.

1. The Journey Begins: Deploying a Virtual Machine

Every VM deployment starts with a single API call — deployVirtualMachine. But what happens next isn’t random magic. CloudStack’s orchestration layer begins by asking a few fundamental questions:

Within the Zone, which cluster is the best fit?

Inside that cluster, which host can run the instance?

Finally, where should the volumes reside?

This process happens in three tightly linked steps:

Deploy Instance → Deployment Planner (Select Cluster) → Host Allocator (Select Host) → Volume Allocator (Select Storage)

Each of these steps can be influenced by configuration parameters and planner algorithms, allowing administrators to shape how CloudStack makes placement decisions.

2. Deployment Planner: The Brain of Cluster Selection

The Deployment Planner is CloudStack’s first major decision point. Its job: pick the right cluster within a zone. This planner evaluates capacity, affinity, dispersion, and sometimes even data locality.

The planner used can be set globally or overridden per Compute Offering:

vm.deployment.planner = FirstFitPlanner | UserDispersingPlanner | UserConcentratedPodPlanner

Let’s follow our fictional instance as it moves through this stage.

 

2.1 The FirstFitPlanner – Capacity-Oriented Placement

Our Instance starts by entering the FirstFitPlanner, the default and simplest planner in CloudStack.

The planner looks across all clusters in the selected zone and builds a sorted list ordered by total available capacity. The cluster with the most available capacity appears first. CloudStack then walks through this ordered list, checking each cluster’s suitability.

In short:

• Goal: Balance and predictability.
• Logic: Sort clusters by available capacity.
• Outcome: Cluster with highest free capacity gets the first chance.

This approach is ideal for balanced environments where fairness and predictable usage are more important than user affinity.

 

2.2. The UserDispersingPlanner – Resilience through Separation

In another scenario, our user runs several VMs already. CloudStack’s UserDispersingPlanner decides not to place all of them in the same cluster. Instead, it tries to spread VMs of a single account across different clusters.

The logic is simple yet effective:

• Count how many VMs each user has per cluster.
• Prefer clusters with fewer instances of that user.

This behaviour reduces blast radius — if one cluster fails, that user’s workload isn’t completely lost.

You can even adjust the balance between dispersion and capacity by tuning:

vm.user.dispersion.weight = 1  # < 1 means capacity gets higher priority

Best for: Multi-tenant environments that prioritise availability and resilience.

 

2.3 The UserConcentratedPodPlanner – Performance and Locality

Sometimes, performance is more important than dispersion. The UserConcentratedPodPlanner is designed to group a user’s VMs within the same pod to improve locality and reduce latency.

Instead of spreading VMs, it prefers pods where the user already has active instances. Within those pods, clusters are then evaluated.

This is useful for workloads like distributed databases or compute clusters that rely on low-latency east-west communication.

Best for: Performance-sensitive or network-local workloads.

 

3. VM Allocation Algorithm: Picking the Right Host

Once the Deployment Planner decides the cluster, CloudStack now zooms in to pick a host. This is where the VM Allocation Algorithm comes into play. It defines how CloudStack sorts or filters eligible hosts.

vm.allocation.algorithm = Random | FirstFit | UserDispersing | FirstFitLeastConsumed | UserConcentratedPod_Random | UserConcentratedPod_FirstFit

Let’s follow our VM again:

Our planner chose Cluster C4. Inside it are three hosts: H4, H5, and H6. The allocation algorithm determines which host CloudStack picks.

• Random:CloudStack randomly picks a host — simple, even distribution.
• FirstFit:CloudStack picks the first host that fits the requirement — fast and predictable.
• UserDispersing:CloudStack avoids placing multiple VMs of the same account on the same host.
• FirstFitLeastConsumed:CloudStack chooses the host with the least consumed capacity (CPU, RAM) — promoting load balancing.
• UserConcentratedPod_Random: same as Random.
• UserConcentratedPod_Random : same as FirstFit.

This layered logic ensures that CloudStack can adapt placement decisions to capacity, affinity, or performance — depending on what’s more important for your deployment model.

3.1 VM Allocation algorithm – Random

The Random VM allocation algorithm works at the host level. It first identifies all eligible hosts within the selected cluster that meet the required capacity and compatibility criteria. It then creates a list of these hosts and shuffles (randomises) the list to avoid bias toward any particular host. After shuffling, it evaluates each host in that random order and selects the first host that satisfies all allocation checks. This approach ensures a simple and even distribution of VMs across hosts without performing any capacity-based sorting or scoring.

3.2 VM Allocation algorithm – FirstFit

FirstFit, picks the first host in the first cluster that has enough CPU and RAM (otherwise it proceeds to the next cluster), with no ordering based on capacity.

3.3 VM Allocation algorithm – Userdispersing

Selects the host running least instances for the account, aims to spread out the instances belonging to a single user account. The UserDispersing VM allocation algorithm works at the host level to spread a user’s VMs across different hosts within a cluster. It first identifies all eligible hosts for deployment and then queries how many VMs the user already has running on each host. The host list is then reordered in ascending order of that count — meaning hosts where the user has fewer VMs are placed first.

The allocator then checks hosts in that order and selects the first host that has enough CPU and RAM to deploy the VM. This ensures that a user’s VMs are distributed more evenly across hosts, improving resilience and avoiding concentration on a single host.

3.4 VM Allocation algorithm – FirstFitLeastConsumed

Selects the first host after sorting eligible hosts by the least allocated resources (such as CPU or RAM). This is a load-balanced placement method when you want CloudStack to prioritise hosts with the most available resources to maintain even utilisation. Collects all eligible hosts in the selected cluster (hosts that meet CPU, RAM, and compatibility requirements).Evaluates each host’s current resource utilisation — typically based on used vs total CPU and memory capacity.Sorts the host list in ascending order of resource consumption (i.e., hosts that are least loaded come first). Selects the first host in that ordered list that has enough available capacity to deploy the VM. If the first host cannot accommodate the VM due to a race condition or updated capacity, it moves to the next one.

 

4. Volume Allocation: The Final Piece of the Puzzle

In CloudStack 4.21, a new layer of control was introduced: the Volume Allocation Algorithm. Until 4.21 vm.allocation.algorithm was used for both VM and volume allocation.

This controls how and where volumes are placed when a VM is deployed. Similar to the VM allocation algorithm, it allows the same flexibility in choosing between Random, FirstFit, UserDispersing, and FirstFitLeastConsumed strategies.

volume.allocation.algorithm = Random | FirstFit | UserDispersing | FirstFitLeastConsumed | UserConcentratedPod_Random | UserConcentratedPod_FirstFit

This provides additional control for storage administrators who want to ensure balanced or affinity-based volume distribution.

 

5. Advanced Placement Controls and Metrics

CloudStack’s placement logic can be fine-tuned through several advanced configuration parameters:

5.1 Host and Storage Tags

You can use host and storage tags to control the Instance and Volume placement in a zone.

5.2 apply.allocation.algorithm.to.pods

When this flag is set to true, CloudStack applies the allocation algorithm at the pod level first. That means the planner first ranks pods by capacity before drilling down to clusters and hosts.

This ensures that capacity-based placement decisions occur earlier, preventing situations where an overused pod gets more load simply because one cluster inside it still has resources.

5.3 host.capacityType.to.order.clusters

This parameter controls how clusters are sorted — based on CPU, memory, or a combined weighted metric.

From version 4.21 onwards, you can configure CloudStack to use a combined capacity score:

host.capacityType.to.order.clusters = COMBINED

host.capacityType.to.order.clusters.cputomemoryweight = 0.5

The metric becomes:

Score = (CPU * weight) + (RAM * (1 – weight))

This provides a more balanced approach to evaluating overall cluster capacity.

Other factors and configurations that influence the instance placement are the Hypervisor Type, Cluster State, CPU Architecture, GPU ( if configured on the Compute Offering), Resource dedication, Affinity Groups, Hardware-specific resource limits, OS preference, etc.

 

6. Beyond the First Placement

The initial placement is just the start. CloudStack continuously manages VMs post-deployment using features such as:

• Live Migration for load balancing and maintenance.
• HA (High Availability) to restart VMs on other hosts if a failure occurs.
• DRS (Dynamic Resource Scheduling) to adapt placement based on changing load patterns.

These ensure that even after your VM is running, CloudStack keeps optimising its location and resource utilisation.

 

In Summary:

CloudStack’s deployment decisions are a blend of intelligent heuristics, configurable algorithms, and capacity-aware logic. Understanding the Deployment Planner and Allocation Algorithms empowers operators to design and tune their environments for efficiency, resilience, and predictability

We encourage you to engage with the Apache CloudStack community to share your feedback, report any bugs, and suggest improvements:

Email: users@cloudstack.apache.org

GitHub: Apache CloudStack Repository