%openstack; ]>

In some cases it is necessary to run OpenStack nested on top of another OpenStack cloud. This scenario allows for complete OpenStack cloud environments to be managed and provisioned on instances running on hypervisors and servers controlled by the underlying OpenStack cloud. Public cloud providers can use this technique to effectively manage the upgrade and maintenance process on complete OpenStack-based clouds. Developers and those testing OpenStack can also use the 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. When using VLANs, these will need to be exposed to the physical ports on which the undercloud runs, as the bare metal cloud owns all the hardware, but they also need to be exposed to the nested levels as well. Alternatively, network overlay technologies can be used on the overcloud (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 the decision about which approach should be taken to provide a nested hypervisor in OpenStack. This decision influences which operating systems can be used for the deployment of the nested OpenStack deployments.

Deployment of a full stack can be challenging but this difficulty can be readily be mitigated by creating a Heat template to deploy the entire stack or a configuration management system. Once the Heat template is created, deploying additional stacks will be a trivial thing and can be performed in an automated fashion. 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. OpenStack would then be deployed on these Compute bare-metal servers with the appropriate hypervisor, such as KVM. In the case of running smaller OpenStack clouds for testing purposes, and performance would not be a critical factor, QEMU can be utilized 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.