Networking 3.6
Before diving into Network configuration in OpenNebula make sure that you've followed the steps described in the Networking section of the Planning the Installation guide.
When a new Virtual Machine is launched, OpenNebula will connect its network interfaces (defined in the NIC section of the template) to the bridge or physical device specified in the Virtual Network definition. This will allow the VM to have access 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 Virtual Network Manager drivers. The OpenNebula administrator may associate one of the following drivers to each Host, when the hosts are created with the onehost command:
Note that some of these drivers also create the bridging device in the hosts.
The administrator must take into account the following matrix that shows the compatibility of the hypervisors with each networking driver:
Firewall | Open vSwitch | 802.1Q | ebtables | VMware | |
---|---|---|---|---|---|
KVM | Yes | Yes | Yes | Yes | No |
Xen | Yes | Yes | Yes | Yes | No |
VMware | No | No | No | No | Yes |
The network is dynamically configured in three diferent steps:
Each driver execute different actions (or even none at all) in these phases depending on the underlying switching fabric. Note that, if either Pre
or Post
fail, the VM will be shut down and will be placed in a FAIL
state.
You can easily customize the behavior of the driver for your infrastructure by modifying the files in located in /var/lib/one/remotes/vnm
. Each driver has its own folder that contains at least three programs pre
, post
and clean
. These programs are executed to perform the steps described above.
The default paths for the binaries/executables used during the network configuration
may change depending on the distro. OpenNebula ships with the most common paths,
however these may be wrong for your particular distro. In that case, please fix the
proper paths in the COMMANDS
hash of /var/lib/one/remotes/vnm/OpenNebulaNetwork.rb
:
COMMANDS = { :ebtables => "sudo /sbin/ebtables", :iptables => "sudo /sbin/iptables", :brctl => "sudo /sbin/brctl", :ip => "sudo /sbin/ip", :vconfig => "sudo /sbin/vconfig", :virsh => "virsh -c qemu:///system", :xm => "sudo /usr/sbin/xm", :ovs_vsctl=> "sudo /usr/local/bin/ovs-vsctl", :lsmod => "/sbin/lsmod" }