As you may know, OpenNebula’s approach to cloud bursting (that is, its hybrid cloud model) is quite unique. The reason behind this uniqueness is the transparency to both end users and cloud administrators to use and maintain the cloud bursting functionality.
The transparency to cloud administrators comes from the fact that a an AWS EC2 region is modelled as any other host (albeit of potentially a much bigger capacity), so the scheduler can place VMs in EC2 as it will do in any other local host. Of course, the scheduler algorithm can be tuned so the EC2 host (or hosts, more on this below) is picked last, so it will be only used only if there is a real need (ie, the local infrastructure cannot cope with the demand). On the other hand, the transparency to end users is offered through the hybrid template functionality: the same VM template in OpenNebula can describe the VM if it is deployed locally and also if it gets deployed in Amazon EC2. So users just have to instantiate the template, and OpenNebula will transparently chose if that is executed locally or remotely. Very convenient, isn’t it?