Virtual Machine Lifecycle & Saving Billing Units

This article explains the different states that virtual machine instances can have and their effect on resource usage.

Similar to other cloud providers, Pouta also has a lifecycle for its Virtual Machines. Different states of virtual machines have different resource requirements for the underlying hardware and therefore are billed differently. Knowing about these different states in Pouta will help you make better decisions on how to maintain your infrastructure. This could help you in saving some billing units. The main states of virtual machines in Pouta are:


A virtual machine is said to be in an active state when it is in the power on state. It will remain in the active state irrespective of the fact you are using it or not. Virtual machines in the active state consume computing resources on one of our compute nodes and are thus billed normally as mentioned in Pouta flavors and billing.

Shut Off

The virtual machine is not running and is in a powered off state. However a shut off virtual machine still consumes billing units in the same way as an Active virtual machine. This is because active/powered off virtual machine consume same computing resources on one of our compute nodes as mentioned in Pouta flavors and billing.


A shut off virtual machine still consumes billing units. To stop consuming, select shelved state.


Pausing a virtual machine pauses all the processes running in the virtual machine and saves the entire state of the machine (memory, application state, etc.) on the host compute node. You are not able to access your virtual machine or hosted applications when the virtual machine is in a paused state. Some applications may suffer from side effects when paused, thus this sate is not recommended for production systems. Some legacy computational tasks may benefit from the paused state but modern workflows generally do not use this state. Pausing of a virtual machine is billed in the same way as an Active state virtual machine.


Suspending a virtual machine saves its current state on the virtual machine's host compute node. The virtual machine could be resumed again to the same state as it was before the suspension, but compute resources (actual cores, compute node etc.) maybe different from the ones which you had before suspending the virtual machine. You are not able to access your machine when it is in a suspended state. Virtual machines in the Suspended state are billed normally as Active state virtual machines. Suspending is not generally used in modern workflows.


Shelving a virtual machine is the shutting down of a virtual machine and removing it from the host compute node. It is like shutting down your home computer and relocating it somewhere new. This frees up all the computing resources which were reserved for it. However it saves the state of all other associated resources, for example file system, floating ip's, network configuration etc. in our central storage. Shelving works best for our standard flavors that are already backed by our central storage service. Shelving can be slow for flavors that are using local storage, especially bigger flavors since the data needs to be copied between local storage and the central storage. Virtual machine in the shelved state do not consume billing units. In a rare occasion, if all of our compute resources are being used up, we won't be able to un-shelve your virtual machine until someone frees up compute resources. N.B. that your floating-ips, volumes and so on can't be removed from the virtual machine before it has been un-shelved. If you have a floating-ips quota of two and one of them is attached to an shelved virtual machine you have only one left for use. Note that ephemeral storage in the IO, GPU or TB flavor's will not get shelved.


Termination (or deletion) removes the virtual machine from your project and frees up compute resources that were in use. These cannot be recovered and all data stored in the virtual machine gets deleted excluding any attached volumes. Once the virtual machine is deleted, you are no longer billed for that virtual machine.

The figure below tries to illustrate state transitions between these states.

Virtual machine lifecycle

In the above section, we have discussed main states of virtual machines in Pouta. However, theoretically there are other states too, full list of states and their behaviors could be found at OpenStack Documentation.

Save Your Billing Units

There are many practices which could help you save billing units such as:

Automated provisioning

Automated provisioning and configuration of your virtual machines could help you to save billing units. For example, you can tear down your unused virtual machines with automatic provisioning and configuration when you don't need them. Later when you need them you can provision new virtual machines from scratch. Your data should always be stored on a volume, and virtual machines should be launched when you need computation done. Here is an example on how to automate a workflow with Heat, Ansible and Docker to deploy Etherpad containing both clustered database and Load balancing in


This type of scaling is not recommended for IO, GPU or TB flavors since ephemeral storage data is lost in this process.

Select suitable state of your virtual machine

Depending upon your project requirements you can change the state of your virtual machines for example, 

You can transition between different states via the Pouta dashboard, command line tools or REST APIs depending upon your project setup. The most common states for your virtual machines are Active, Shut Down, Shelved or Deleted. There maybe occasions when your virtual machine goes into Error state, virtual machines in Error state are still billed. In case your virtual machine goes into Error state and you are unable to recover it, please contact

Resize your virtual machine

Resizing a virtual machine is a good utility in Pouta, which could help you to save billing units. Based upon on your project requirements you could scale up or scale down your virtual machine to other flavors. Scaling down your virtual machine when it has less computational workload will free up compute resources and result in saving your billing units. Later on, depending on your computational workload you can scale up your virtual machines. Please note that you can only resize to the flavors of the same family only, i.e. for example if you are using the standard. family flavor you can only resize it to another standard family flavor. When the resize is complete, the virtual machine status first displays verify resize. At this point, you need to confirm again if your virtual machine has been resized as expected. Resizing will have downtime for the virtual machine until the whole resize process has been completed. Note that resizing is not as elegant as using the boot from volume option explained above. If you know beforehand that you want change the size of the virtual machines at some point, using the boot from volume when launching the virtual machine will give you more flexibility.