Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

Currently CloudStack has following 3 deployment planners available out-of-the-box:

  • FirstFitPlanner
  • UserDispersingPlanner
  • UserConcentratedPodPlanner
  • BareMetalPlanner

Each of these planners implements some heuristics that provide ordering of resources on some basis, while choosing resources for VM deployment. All the planners work on the available set of resources in a given datacenter that are shared across various accounts. Currently in a CloudStack deployment, only one of these planners is used for VM deployments. The global parameter 'vm.allocation.algorithm' decides which planner will be used.

However there could be a need to be able to choose different planning strategies within a single CS deployment. So letting Admin choose a deployment planner for a set of VMs will be helpful. To enable this, we can expose deployment planner as part of a ServiceOffering.

By default, the value will be set to the default CS FirstFitPlanner, but admin can override it and set some other strategy as per needs.

Resource reservation between planners

When the Deployment planner gets exposed per ServiceOffering, then in a CS deployment multiple planners will have to But if deployment planner is exposed per ServiceOffering then multiple planners can co-exist. In such case, we will might need resource reservation between planners, so that planner executions do not step onto each other's resource choice.

The existing planners work on the available set of resources in a given datacenter that are shared across various accounts. So all of them can co-exist without an issue since they do not need to book resources exclusively.

However if a planner is added that needs to use resources exclusively for an account, then we will need some kind of resource reservation between planners.

e.g Refer to the Implicit Dedication Planner being added as part of this 4.2 release.