We are working these weeks on improving one of OpenNebula’s most powerful components: OneFlow. OneFlow can be used to create, control and monitor complex services composed of groups of interconnected Virtual Machines that come with internal deployment dependencies. Each group of VMs is deployed and managed as a single entity, and is completely integrated with the advanced OpenNebula user and group management service. Once deployed, OpenNebula manages the elasticity rules defined by the users, making sure the different elements of a specific service react properly in response to, for instance, a scheduled allocation of additional resources or a sudden increase of workload.

In this post I’d like to share with you some of the new network features that the OpenNebula team is currently developing. These improvements are intended to be released as part of the next minor release of OpenNebula, version 5.12, so this is just an early taste of what’s to come in just a few weeks’ time 😉

Let’s start with an example: now, when a service template is created, OpenNebula lets you define as well a set of networks for that service. You can define, for instance, a Private and a Public network, which will be available to all the VMs that are part of that service. This is how you do it with the current version:

Pretty straightforward, right? When the service template is actually instantiated, the user can select then from the network pool which available network is going to be the “Public” one, and which one is going to be the “Private” one.

What we are doing now is implementing some more additional options in order to get the most out of the methods for self-provisioning virtual networks that were recently incorporated into OpenNebula. With the improved version of OneFlow we are working on at the moment, users will be able to choose whether they want to

• Use an existing network
• Create a reservation from an existing network
• Create a network from an existing virtual network template

You can see below how the prototype for that new interface looks like. You’ll be able to use it to select how Public and Private networks are defined at the instantiate view. Reservations and virtual networks will be automatically deleted as soon as the associated service terminates. This will allow users to easily create dedicated networks for each service instance which will be fully managed by OpenNebula.

In the end, the main objective of this improved version of OneFlow is to increase the flexibility of OpenNebula, allowing cloud administrators to easily cover all end-user’s use cases. Still, remember that this is a work in process, so feedback is more than welcome! 🙂