This section outlines the scaling considerations for the VMware Integrated OpenStack (VIO) components including backup and restore.

VMware Integrated OpenStack Sizing

The sizing options for the OpenStack Control Plane, including the number of instances, sizes, and resources can be scaled horizontally.

The hardware that is required to run VMware Integrated OpenStack depends on the scale of your deployment and the size of the controller that you select.

The VIO manager comes only in a single flavor and requires 4 vCPUs, 16 GB memory, and two disks (40GB/30 GB).

For the production HA deployment, VIO supports the following controller form-factors:

Table 1. VIO Controller Form-Factors









Memory (GB)




Controller Disk (GB)




Scaling VMware Integrated OpenStack

VMware Integrated OpenStack supports scaling out nodes, services, clusters, and datastores. Hence, the control and workload planes can be scaled independently as the size of a VIO deployment increases over time.

The minimum count for a highly available deployment is 3 controller nodes. However, the controllers can be scaled up to 10 to provide additional capacity.


Controllers of different sizes are not supported in a VIO deployment

With VIO, the sizing of the control plane VMs is not fixed. Based on the real-world conditions for your cloud, you can add additional controller VMs as a day-2 operation. The more tasks the control plane perform, the more resources are required. We recommend that medium or large-size controllers are used for production deployments.

After the deployment, monitor the CPU and memory consumptions on the controller VMs. If three controllers are consistently running high, scale them horizontally by adding additional controllers and restarting pods that are consuming more resources. Pod restart does not impact the service availability as a redundant copy is always available for each service. Pod restart triggers the Kubernetes scheduler to reassign the Pod to the newly added controller.

Sizing and Scaling Recommendations for VMware Integrated OpenStack

Design Recommendation

Design Justification

Design Implication

Use HA for production deployments.

Avoid a single point of failure.

VIO HA deployment requires a minimum of three controller nodes.

A HA deployment requires 3-10 controllers.

Use the Medium or Large size for production deployment.

The amount of CPU and memory a control plane consumes is based on the number of API calls and the type of API calls that the control plane handles. Therefore, if you expect a high-churn environment with lots of API calls, move up to a larger size.


Deploy Large size if an optional service such as Ceilometer is used.

If the end-user never makes a call to Aodh/Gnocchi/Panko, Ceilometer uses more RAM and CPU compared to other OpenStack Services.

Increased CPU and memory.

Increase the number of Pod replicas if the API response is slow.

OpenStack Services run as Kubernetes deployments and can be scaled up/down to address application resource contention.

Kubernetes offers a built-in mechanism to load balance API requests to the newly added Pod replicas.


Add more controller nodes if existing controllers are consistently running high in CPU and memory.

Kubernetes scheduler reassigns high utilization Pods to the newly added controller to even out the usage across nodes.

  • Pod Restart is required to move OpenStack services.

  • Node scaleout cannot be undone.

Use the Kubernetes node cordon to control the Pod to Controller assignment.

Cordon removes a node from the Kubernetes scheduler when the scheduler is placed in the Cordon state.