In this guide you'll learn how to define and use virtual networks. For the sake of simplicity the following examples assume that the hosts are attached to two physical networks:

• A private network, through the virtual bridge vbr0
• A network with Internet connectivity, through vbr1

This guide uses the CLI command onevnet, but you can also manage your virtual networks using Sunstone. Select the Network tab, and there you will be able to create and manage your virtual networks in a user friendly way.

To set up a virtual network you just need to know the name of the bridge to bind the virtual machines to, and decide the IP addresses (the leases) that the VNet will contain.

New Virtual Networks are defined in a Virtual Network template file. The onevnet command is used to create a VNet from that template.

As an example, we will create two new VNets, Blue and Red. Lets assume we have two files, blue.net and red.net.

Blue.net file:

NAME    = "Blue LAN"
TYPE    = FIXED
 
# We have to bind this network to ''virbr1'' for Internet Access
BRIDGE  = vbr1
 
LEASES  = [IP=130.10.0.1]
LEASES  = [IP=130.10.0.2, MAC=50:20:20:20:20:21]
LEASES  = [IP=130.10.0.3]
LEASES  = [IP=130.10.0.4]
 
# Custom Attributes to be used in Context
GATEWAY = 130.10.0.1
DNS     = 130.10.0.1
 
LOAD_BALANCER = 130.10.0.4

And red.net file:

NAME    = "Red LAN"
TYPE    = RANGED
 
# This vnet can be only used by the owner user
PUBLIC  = NO
 
# Now we'll use the host private network (physical)
BRIDGE  = vbr0
 
NETWORK_SIZE    = C
NETWORK_ADDRESS = 192.168.0.0
 
# Custom Attributes to be used in Context
GATEWAY = 192.168.0.1
DNS     = 192.168.0.1
 
LOAD_BALANCER = 192.168.0.3

Once the files have been created, we can create the VNets executing:

<xterm> $ onevnet create blue.net ID: 0 $ onevnet create red.net ID: 1 </xterm>

Also, onevnet can be used to query OpenNebula about available VNets: <xterm> $ onevnet list

ID USER     GROUP    NAME              TYPE BRIDGE PUB  LEASES
 0 oneadmin oneadmin Blue LAN             F   vbr1  No       0
 1 oneadmin oneadmin Red LAN              R   vbr0  No       0

</xterm>

In the output above, USER is the owner of the network and LEASES the number of IP-MACs assigned to a VM from this network.

To delete a virtual network just use onevnet delete. For example to delete the previous networks:

<xterm> $ onevnet delete 2 $ onevnet delete 'Red LAN' </xterm>

You can also check the IPs leased in a network with the onevnet show command

Check the onevnet command help or the reference guide for more options to list the virtual networks.

You can add and remove leases to existing FIXED virtual networks (see the template file reference for more info on the network types). To do so, use the onevnet addleases and onevnet rmleases commands.

The new lease can be added specifying its IP and, optionally, its MAC. If the lease already exists, the action will fail.

<xterm> $ onevnet addleases 0 130.10.0.10 $ onevnet addleases 0 130.10.0.11 50:20:20:20:20:31 $ $ onevnet addleases 0 130.10.0.1 [VirtualNetworkAddLeases] Error modifiying network leases. Error inserting lease, IP 130.10.0.1 already exists </xterm>

To remove existing leases from the network, they must be free (i.e., not used by any VM).

<xterm> $ onevnet rmleases 0 130.10.0.3 </xterm>

A lease from a virtual network can be obtained by simply specifying the virtual network name in the NIC attribute.

For example, to define VM with two network interfaces, one connected to Red LAN and other connected to Blue LAN just include in the template:

NIC = [ NETWORK_ID = 0 ]
NIC = [ NETWORK_ID = 1 ]

You can also request a specific address just by adding the IP or MAC attributes to NIC:

NIC = [ NETWORK_ID = 1, IP = 192.168.0.3 ]

When the VM is submitted, OpenNebula will look for available IPs in the Blue LAN and Red LAN virtual networks. If successful, the onevm show command should return information about the machine, including network information.

<xterm> $ onevm show 12 VIRTUAL MACHINE 12 INFORMATION ID : 12 NAME : server STATE : PENDING LCM_STATE : LCM_INIT START TIME : 07/15 15:30:53 END TIME : - DEPLOY ID: : -

VIRTUAL MACHINE TEMPLATE NAME=server NIC=[

BRIDGE=vbr1,
IP=130.10.0.1,
MAC=50:20:20:20:20:20,
NETWORK=Blue LAN,
NETWORK_ID=0 ]

NIC=[

BRIDGE=eth0,
IP=192.168.0.1,
MAC=00:03:c0:a8:00:01,
NETWORK=Red LAN,
NETWORK_ID=1 ]

VMID=12 </xterm>

Note that if OpenNebula is not able to obtain a lease from a network the submission will fail.

Now we can query OpenNebula with onevnet show to find out about given leases and other VNet information:

<xterm> $ onevnet list

ID USER     GROUP    NAME              TYPE BRIDGE PUB  LEASES
 0 oneadmin oneadmin Blue LAN             F   vbr1  No       1
 1 oneadmin oneadmin Red LAN              R   vbr0  No       1

</xterm>

Note that there is one LEASE active in each network

<xterm> $ onevnet show 1 VIRTUAL NETWORK 1 INFORMATION ID : 1 USER : oneadmin GROUP : oneadmin PUBLIC : No USED LEASES : 1

VIRTUAL NETWORK TEMPLATE BRIDGE=vbr0 DNS=192.168.0.1 GATEWAY=192.168.0.1 LOAD_BALANCER=192.168.0.3 NAME=“Red LAN” NETWORK_ADDRESS=192.168.0.0 NETWORK_SIZE=C TYPE=RANGED

LEASES INFORMATION LEASE=[ IP=192.168.0.1, MAC=02:00:c0:a8:00:01, USED=1, VID=0 ] </xterm>

IP 192.168.0.1 is in use by Virtual Machine 0

You can apply firewall rules on your VMs, to filter TCP and UDP ports, and to define a policy for ICMP connections.

Read more about this feature here.

The users can list all the VNets in their group with the onevnet list g command. Public VNets in their group can be shown (onevnet show <id>), and used in Virtual Machines.

To share a VNet with other users in the same group, use the onevnet publish and onevnet unpublish commands to manage the public flag.

In previous 2.x versions, the public flag allowed all users in the system to see and use resources. In 3.0, the public flag scope is limited only to the users in the resource's group.

Hypervisors can attach a specific MAC address to a virtual network interface, but Virtual Machines need to obtain an IP address. Please visit the contextualization guide to learn how to configure your Virtual Machines to automatically obtain an IP derived from the MAC.