We’re thrilled to announce a major update to OneFlow: the ability to deploy and manage Virtual Routers directly within OneFlow. This new feature seamlessly integrates Virtual Network Functions (VNF), significantly enhancing OneFlow’s capacity to handle dynamic network environments.

In this blog post, we’ll explore how the new Virtual Router (VR) functionality works, how it simplifies network management, and the overall improvements to OneFlow that enable these advancements.

Introducing the New Role Type: Virtual Router Role

OneFlow introduces a new role type attribute: type. This attribute specifies whether a role is designed to manage Virtual Machines (VM) or Virtual Routers (VR). By designating the role type as vr, OneFlow will treat the role as a Virtual Router, facilitating the integration of virtual networking components into your OneFlow services. The other possible value to this new type attribute is vm, which implements the existing functionalities for VM-based roles.

This new type attribute offers users the flexibility to define exactly what kind of component they’re deploying:

• VM Role (`type: “vm“): Represents a group of Virtual Machines responsible for performing compute tasks.
• VR Role (`type: “vr“): Represents a group of Virtual Routers that manage network traffic, routing, and floating IP management.

For example, defining a Virtual Router Role looks like this:

{
  "name": "VR_ROLE_EXAMPLE",
  "type": "vr",
  "template_id": 4,
  "cardinality": 1,
  "template_contents": {
	"NIC": [
  	  { "NETWORK_ID": "$Public" },
        { "NETWORK_ID": "$Private" },
	]
  }
}

Fig 1. Virtual Router Role with a VRouter attached to two different networks (Public & Private)

In this configuration:

• The type attribute is set to “vr”, indicating that the role is for Virtual Routers.
• Virtual Router (VR) Roles support features like floating IP assignment, dynamic network configurations, and role dependencies.

The introduction of this new role type not only provides greater flexibility and customization of OneFlow services but also enables a specialization of roles based on their purpose. Until now, adding a role that functioned as a Virtual Router within OneFlow required a series of steps that, while well described in a step-by-step guide in the documentation, demanded extra effort from cloud administrators. With this new functionality, use cases like deploying a service at the Edge with Virtual Routers in OneFlow have never been easier to configure.

Why Virtual Routers in OneFlow?

Virtual Routers are a crucial component for modern cloud infrastructures, where virtualized network services must scale dynamically. Previously, managing VRs required manual configuration outside of OneFlow’s workflow, adding complexity and overhead for users managing large-scale cloud environments.

With this new feature, OneFlow can now manage the full lifecycle of Virtual Routers, just like Virtual Machines (VMs). This capability allows cloud administrators to integrate VRs into OneFlow’s deployment models, simplifying the configuration, deployment, and scaling og VNFs.

Key Features of the Virtual Router Integration

1. Direct Deployment of Virtual Routers

Users can now create and manage Virtual Routers as part of their OneFlow services. By simply providing a Virtual Router template, OneFlow handles the deployment and lifecycle management. This streamlines the process of deploying network services and managing complex network architectures.

2. Role-Based VR Management

As mentioned earlier, OneFlow introduces a new type attribute in roles, enabling users to specify whether a role is for Virtual Machines (VMs) or Virtual Routers (VRs). By default, all roles are VM roles, but setting type:”vr” allows OneFlow to treat the role as a Virtual Router.

3. Automatic Floating IP Assignment

One of the most exciting features is the automatic assignment of floating IPs to Virtual Routers. This means users can dynamically create network configurations and assign floating IPs that are automatically managed by OpenNebula. The ability to configure dynamic networks directly in OneFlow drastically reduces manual intervention and automates network management for large-scale environments.

{
  “name”: “Example Service”
   …
  “roles”: [
   …
   {
     "name": "VR_ROLE_EXAMPLE",
     "type": "vr",
     "template_id": 4,
     "cardinality": 3,
     "template_contents": {
       "NIC": [
  	    {
    	      "NETWORK_ID": "$Public",
    	      "FLOATING_IP": "yes"
  	    },
         { “NETWORK_ID”: “$Private” }
	  ]
     },
     …
   ]
   “networks_values": [
     {
	  "Public": {
  	    "reserve_from": 1,
  	    "extra": "AR=[ IP=1.1.1.1,SIZE=10,TYPE=IP4]"
     }
    }
   ]
…
}

Fig 2. Sample Service with a VRouter Role using a dynamic Floating IP in the Public Interface

4. Enhanced Role Dependencies

Virtual Routers are integrated with all of OneFlow’s powerful features, such as user inputs, automatic network creation, and role dependencies. By defining a VR role, you ensure that other VM roles in the service can communicate with the Virtual Router and benefit from its networking capabilities.

5. High Availability (HA)

Virtual Routers in OneFlow can be deployed with high availability (HA) by defining multiple instances in the role increasing the number of routers using the cardinality attribute. This ensures that the network service remains available even if one of the Virtual Routers fails, further enhancing the robustness of your cloud infrastructure.

For example, you can define a VR role with three instances to ensure HA:

{
  "name": "VR_ROLE_EXAMPLE",
  "type": "vr",
  "template_id": 4,
  "cardinality": 3,
  "template_contents": {
	"NIC": [
  	  { "NETWORK_ID": "$Public", “FLOATING_IP”: “yes”},
        { "NETWORK_ID": "$Private" },
	]
  }
}

Fig 3. VRouter Role using a dynamic Floating IP in the Public Interface with HA mode enable

Simplifying OneFlow’s Usability

In addition to the introduction of Virtual Routers, we’re also implementing several usability and quality-of-life (QoL) improvements to OneFlow.

Consistent Nomenclature

The naming of certain attributes has been refined for consistency with the OpenNebula core, making it easier to navigate and use OneFlow alongside other OpenNebula components.

Old Attribute Name	New Attribute Name
vm_template	template_id
vm_template_contents	template_contents
custom_attrs	user_inputs

The motivation behind these changes is to make attribute names more generic, as roles can now manage not only Virtual Machines but also Virtual Routers. Additionally, the name custom_attrs has been changed to user_inputs to align OneFlow with the concepts used in VM templates.

Note: It’s not necessary to manually update the Service templates; OpenNebula will automatically adjust all content to adapt to the new format through the Migrators.

Simplified Template Management

Overwriting VM templates in OneFlow has been streamlined, allowing users to modify templates and user inputs more easily. For instance, users no longer need to manually add user_inputs to template_contents. OneFlow now automatically handles this, ensuring that inputs are passed directly to the context.

Additionally, the template_contents field is now a JSON object instead of a KEY=VALUE string, making it much easier to read and manipulate the data contained within. Thanks to this attribute, you can modify and override the original values from the template referenced in the template_id field—and even add new ones. For example, a common use case is the ability to adjust the CPU or memory of a virtual machine at the time of instantiation using this feature.

Combined with the ability to request user-defined parameters via User Inputs, OneFlow offers tremendous flexibility when it comes to customizing various scenarios and services.

Here you can see a difference between the two Role definitions:

Old Role Body

{
   “name”: “old_role_example”,
   “vm_template”: 1,
   “cardinality”: 3,
   “vm_template_contents”:        
     "ATT A=\"$ATT A\"\n\"CONTEXT\"=[ATT A=\"$ATT A\"]\CPU=\"2\"\n",
   “custom_attrs”: {
   	“ATT_A”: “M|text|desc| |default”
   }
   … other attributes
}

Fig 4. Old Role Body

New Role Body

{
   “name”: “new_role_example”,
   “type”: “vm”,
   “template_id”: 1,
   “cardinality”: 3,
   “template_contents”: {
   	“CPU”: 2
   }
   “user_inputs”: {
   	“ATT_A”: “M|text|desc| |default”
   }
   … other attributes
}

Fig 5. New Role Body

A Practical Example: Deploying an HA Application with OneFlow

To showcase the power of the new Virtual Router functionality in OneFlow, let’s walk through an example where we deploy a highly available web application. In this scenario, Virtual Machines will run the web application, while Virtual Routers will manage network routing and ensure connectivity with floating IPs.

1. Defining the Service Template

We’ll begin by creating a OneFlow Service Template that includes:

1. WebApp Role: This role represents the Virtual Machines running the web application.
2. MyAppDB Role: A database role where the Virtual Machines handle database functions.
3. VRouter Role: The Virtual Router role responsible for managing both public and private network traffic and assigning floating IPs.

Here’s an example of the Service Template:

{
  "name": "WebApp Service",
  "description": "My WebApp Service",
  "deployment": "straight",
  "roles": [
	{
  	  "name": "WebApp",
  	  "type": "vm",
  	  "template_id": 101,
  	  "cardinality": 3,
  	  "min_vms": 1,
  	  "max_vms": 5,
  	  "cooldown": 60,
  	  "elasticity_policies": [
    	    {
      	"type": "CHANGE",
      	"adjust": 1,
      	"cooldown": 60,
      	"expression": "CPU_USAGE > 80"
    	    }
  	  ],
  	  "template_contents": {
    	    "CPU": 2,
    	    "MEMORY": 4096,
    	    "NIC": [
      	{
        	"NETWORK_ID": "$Private"
      	}
    	    ]
  	  }
	},
	{
  	  "name": "MyAppDB",
  	  "type": "vm",
  	  "template_id": 302,
  	  "cardinality": 3,
  	  "template_contents": {
    	    "NIC": [
      	{
        	"NETWORK_ID": "$Private"
      	}
    	    ]
  	  },
  	  "user_inputs": {
    	    "DB_PASSWORD": "M|text|desc||default"
        }
	},
	{
  	  "name": "VRouter",
  	  "type": "vr",
  	  "template_id": 200,
  	  "cardinality": 3,
  	  "template_contents": {
    	    "NIC": [
      	{
        	  "NETWORK_ID": "$Public",
        	  "FLOATING_IP": "yes"
      	},
      	{
        	  "NETWORK_ID": "$Private"
      	}
    	    ]
  	  }
	}
  ],
  "networks_values": [
	{
  	  "Public": {
    	    "reserve_from": 1,
    	    "extra": "AR=[IP=1.1.1.1,SIZE=10,TYPE=IP4]"
  	  }
	},
	{
  	  "Private": { "template_id": 6 }
	}
  ]
}

Fig 6. Sample Service for a Web App deployment

2. Customize Network Configurations

In this example:

• WebApp Role: The role defines three Virtual Machines (VMs) running the web application with 2 CPUs and 4GB of memory each. The role includes elasticity policies that allow the service to scale automatically when CPU usage exceeds 80%. The role is also connected to the Private network.
• MyAppDB Role: Manages the database VMs, with an input field (DB_PASSWORD) allowing for dynamic configuration at deployment. The VMs of this role are also connected to the Private network, ensuring that they are isolated from external access but can communicate with the web application.
• VRouter Role: Manages the network traffic for the service. This role serves as the network gateway between the Public and Private networks. It manages traffic by:
  • Acting as the entry point from the public internet via the Public network, assigning a floating IP to ensure external accessibility.
  • Routing traffic internally between the WebApp and MyAppDB roles on the Private network.

This setup allows users to access the web application via the Virtual Router’s public IP, while all internal traffic between the application and database is routed through the private network, ensuring security and efficient traffic management.

3. Deploying the Service

Once the Service Template is defined, you can deploy it using the CLI or the Sunstone GUI:

# service.json is a file containing the above example from step one
 oneflow-template create service.json

# You can instantiate the service using name or service ID
oneflow-template instantiate "WebApp Service"

Fig 7. Instantiating a OneFlow Service

This will deploy:

• Three VMs running the web application.
• Three Virtual Routers in HA mode that route traffic between the public network and the private network.
• Three VMs running the database.

In this scenario, users access the web application through the public IP managed by the Virtual Router, while all sensitive database communication remains securely isolated within the private network. If you’d like to explore all the options available using OneFlow, we recommend checking out the documentation here.

What’s Next?

The new Virtual Router functionality makes OneFlow even more powerful and user-friendly for those deploying network services. By enabling the dynamic deployment of Virtual Routers alongside traditional Virtual Machine roles, OneFlow is expanding the possibilities for Virtual Network Functions in OpenNebula.

We’re incredibly excited to see how users leverage these features to simplify and elevate their operations. Don’t forget to share your thoughts with us on the OpenNebula Forum!

---

---