How can I assign different VLANS automatically to each group?

Hi,

I would like to know how VLANs are asigned to the VMs without setting up them on the template.

For example, if I create 2 different projects (groups) with 2 different users for each group, are different VLANs assigned to each group?

I would expect that the VMs launched by user1 and user2 belonging to project1 (group1) get a different VLAN that the VMs launched by user1 and user2 belonging to project2 (group2). Therefore, my question is, is there a way to assign automatically different VLANs for each project (group) without needing to set up them on each template?

I hope I have explained myself correctly but in any case, please let me know any question/doubt about it :smile:

Thanks in advance,
Esteban

Esteban Freire forum@opennebula.org writes:

Hi,

Hello,

I would like to know how VLANs are asigned to the VMs without setting up them on the template.

For example, if I create 2 different projects (groups) with 2
different users for each group, are different VLANs assigned to each
group?

I would expect that the VMs launched by user1 and user2 belonging to
project1 (group1) get a different VLAN that the VMs launched by user1
and user2 belonging to project2 (group2). Therefore, my question is,
is there a way to assign automatically different VLANs for each
project (group) without needing to set up them on each template?

I hope I have explained myself correctly but in any case, please let
me know any question/doubt about it :smile:

We have something like this in our testing environment but at user level:

  • each user must be able to deploy a complete target infrastructure:
    networks, routers, servers, workstations, etc.

  • template of each server is shared for all our users (images updates
    managed by jenkins).
    This requires the NIC to not have the UNAME, in which case OpenNebula
    will lookup the network NAME in the list of the networks owned by the
    user starting the VM.

  • Each user has all the networks used by the templates, with VLAN=YES
    but without the “VLAN_ID[1]” set, in which case OpenNebula will use
    “:start_vlan[2]” + ”network ID” as the “VLAN_ID”.

In practice, each user has the following networks:

Template for Internet network:

NAME            = "INTERNET"
BRIDGE          = "ovs-br0"
VLAN            = "YES"
NETWORK_ADDRESS = "10.0.0.0"
NETWORK_MASK    = "255.255.255.0"
DNS             = "10.0.0.1"
GATEWAY         = "10.0.0.1"
AR              = [
                   TYPE = "IP4",
                   IP   = "10.0.0.10",
                   SIZE = "100",
                  ]

Template for the DMZ:

NAME            = "DMZ"
BRIDGE          = "ovs-br0"
VLAN            = "YES"
NETWORK_ADDRESS = "10.0.1.0"
NETWORK_MASK    = "255.255.255.0"
DNS             = "10.0.1.1"
GATEWAY         = "10.0.1.1"
AR              = [
                   TYPE = "IP4",
                   IP   = "10.0.1.10",
                   SIZE = "100",
                  ]

Template for the LAN:

NAME            = "LAN"
BRIDGE          = "ovs-br0"
VLAN            = "YES"
NETWORK_ADDRESS = "10.0.2.0"
NETWORK_MASK    = "255.255.255.0"
DNS             = "10.0.2.1"
GATEWAY         = "10.0.2.1"
AR              = [
                   TYPE = "IP4",
                   IP   = "10.0.2.10",
                   SIZE = "100",
                  ]

and the VM template for router has the following NICs:

NIC = [
       MODEL = "virtio",
       NETWORK = "INTERNET",
      ]
NIC = [
       MODEL = "virtio",
       NETWORK = "DMZ",
      ]
NIC = [
       MODEL = "virtio",
       NETWORK = "LAN",
      ]

I’m not sure if this can work with networks owned by the group-admin
with the USE permission set for the group.

Footnotes:
[1] Open vSwitch — OpenNebula 4.12.1 documentation

[2] Networking Overview — OpenNebula 4.12.1 documentation

Hi,

Adding to @DaD’s suggestion, there is an alternative way if you are using the cloud view. You can create your templates without any NIC, and let the users choose the network to use when a new VM is instantiated.
Each user will only see the virtual networks added to their VDC.