%openstack; ]>

In some cases it is necessary to run OpenStack nested on top of another OpenStack cloud. This scenario enables you to manage and provision complete OpenStack cloud environments on instances running on hypervisors and servers that the underlying OpenStack cloud controls. Public cloud providers can use this technique to manage the upgrade and maintenance process on complete OpenStack-based clouds. Developers and those testing OpenStack can also use this guidance to provision their own OpenStack environments on available OpenStack Compute resources, whether public or private.

The network aspect of deploying a nested cloud is the most complicated aspect of this architecture. You must expose VLANs to the physical ports on which the underlying cloud runs, as the bare metal cloud owns all the hardware, but you must also expose them to the nested levels as well. Alternatively, you can use the network overlay technologies on the OpenStack cloud running on OpenStack to provide the required software defined networking for the deployment.

A key question to address in this scenario is which approach you should take to provide a nested hypervisor in OpenStack. This decision influences which operating systems you use for the deployment of the nested OpenStack deployments.

Deployment of a full stack can be challenging but you can mitigate this difficulty by creating a Heat template to deploy the entire stack or a configuration management system. After creating the Heat template, you can automate the deployment of additional stacks. The OpenStack-on-OpenStack project (TripleO) addresses this issue. Currently, however, the project does not completely cover nested stacks. For more information, see https://wiki.openstack.org/wiki/TripleO.

In the case of running TripleO, the underlying OpenStack cloud deploys the Compute nodes as bare-metal. You then deploy OpenStack on these Compute bare-metal servers with the appropriate hypervisor, such as KVM. In the case of running smaller OpenStack clouds for testing purposes, where performance is not a critical factor, you can use QEMU instead. It is also possible to run a KVM hypervisor in an instance (see http://davejingtian.org/2014/03/30/nested-kvm-just-for-fun/), though this is not a supported configuration, and could be a complex solution for such a use case.