When a new Virtual Machine is launched, OpenNebula will connect its network interfaces (defined in the NIC section of the template) to the bridge specified in the Virtual Network definition. This will allow the VMto have acess to different networks public or private.

The OpenNebula administrator must take into account that although this is a powerful setup, it should be complemented with mechanisms to restrict network access only to the expected Virtual Machines, to avoid situations in which an OpenNebula user interacts with another user's VM. This functionality is provided through network hooks that must be enabled in oned.conf, which aren't enabled by default.

The OpenNebula administrator may activate one of the following network types:

• Host-managed VLANs - Restrict network access through VLAN tagging, which also requires support from the hardware switches.
• Ebtables - Restrict network access through Ebtables rules. No special hardware configuration required.
• Open vSwitch - Restrict network access with Open vSwitch Virtual Switch.

Additionally the OpenNebula administrator may enable firewalling rules to allow a regular OpenNebula user to filter TCP, UDP or ICMP traffic:

• Configuring Firewalls for VMs

Since the previously mentioned functionality is implemented through the use of network hooks, these have the limitation that aren't triggered on a migration event. These means that the network configuration will not be restored in the target host after a Virtual Machine migration.

In future OpenNebula releases this limitation will be removed, meantime we suggest one of the following options:

• Create static network rules in all the hosts, either manually or by tweaking the network hooks.
• Disable migrations for non-administrator users.