How to manage OpenVSwitch Flows with OpenNebula?

Community Support
1

Hi everyone,

I look for a solution to make the flow pushed by OpenNebula persistent With OpenVSwitch.

I’m currently using opendaylight as flow controller but OpenNebula doesn’t include an OpenFlow Controller driver yet.
The configuration pushed by ovs-vsctl is persistent across restart but not the Flows (ovs-ofctl).
So, How can I do to make the Flow pushed by OpenNebula persistent ?

Sincerly,

2

Hi everyone,

To restart openvswitch when needed without losing active flows, I use the command “/etc/init.d/openvswitch-switch force-reload-kmod”. However, when a node crash, OpenVswitch flows are automaticaly discarded and the VM migrated to others nodes recreating all flows rules. So,with this fact, I don’t need persistent flows.

However when making test, I discover that when I attach or detach other nics on a VM, The flows of all NICs or created or removed. So, i can’t disconnect NICs without impacting other NICs Flows.

This is a bug planned on a new release roadmap ?

Sincerly,

3

The “opendaylight / SDN controller” driver should behave a bit different than the current Open vSwitch driver. I.e. it should not delete / re-create open flows when a VM gets migrated. It should only delete flows when a VM gets destroyed. If you want to handle ALL open flows yourselve (with the openflow controller of choice) you should be able to do it the following way:

  • Edit openvswitch drivers and disable all create / delete logic regarding open flow
  • setup a hook whenever a VM gets into RUNNING state to inform your (open)daylight controller that a new VM is active and Open Flow rules should be created (based on IP(v6) / MAC information from the VM template)
4

Good find. The Open vSwitch driver should be smart enough to only deactivate the flows associated with the attached /detached nic.

5

Yes, It appear that is a loop generated for each nics of th VM in the script “/var/lib/one/remotes/vnm/ovswitch/OpenvSwitch.rb” that is called without nic_id argument.

The solution would be to replace as below :

def activate(nic_id = nil)
     lock

     process do |nic|
        @nic = nic 
         ...
    end
    return 0
end
6

I’ve updated this http://dev.opennebula.org/issues/3807

7

Yes, this http://dev.opennebula.org/issues/3807

8

Hello everyone,

I was wondering, maybe it would be great to introduce a possibility to only recreate all flows for each vm nics by adding for example a “recreate flows” button ?

In facts, when I use the recreate button to recreate a VM from is template, I loose all the datas of non persistant disk and overload the VM with the template. So it’s not possible to only recreate all network flows of a VM and caused a complex state if a problem occurred with the network manager (OpenVSwitch in my case) losing all flows for example.

What do you think about this?

9

Hi

We have this issue http://dev.opennebula.org/issues/3204, which basically
will re-create the iptables rules when the security groups are changed. It
is the same feature as “recreate flows” you have mentioned. I’ve added a
link to this thread at the issue to have this in mind when we implement it.

Cheers

10

Hi,

Thanks Ruben for all your support,

I have one more question about OpenNebula and OpenVswitch.
There is a way to allow OpenNebula to define “ingress_policy_rate” and “ingress_policy_burst” using OpenVswitch driver ? In fact, When i define the policy directly in OpenVSwitch, I loose all the configuration when a VM Migrate to another host.

This is something planned into a next release ?

Regards,

11

Currently there are no plans in that direction, I’d suggest to hook on the
openvswitch driver to issue the ovsctl commands. Note that pre/post are
executed on the target/source host on migration, so you can make the same
configuration on the target host…

Cheers

Ruben

12

Thanks Ruben,

It’s OK to integrate this at the pre/post script but how can I give the value for each VM Nic from Sunstone ?
I would make something like a text field in the Network configuration Page and save the value into the OpenNebula database.

Sincerly,

13

Maybe you can just add the values in the network template and include the
name as one of INHERIT_VNET_ATTR in oned.conf. Then the VM will have the
attribute as part of the NIC and that can be consumed from the drivers…
For example, take a look to how MTU or VLAN_TAGGED_ID are managed; probably
you can follow the same approach

14

Yes, but that’s allow to define a rate_policing and burst_policing only for the Virtual Network but not for each NIC.
In facts, there is no attributes or context field to customize each specific VM Nics except by replacing each values inside the database directly for each VM template.

15

There is no option in Sunstone, but you can add the very same attribute to
the NIC in the VM Template… this will work for your users that just
instantiate the VM Template.

16

I succeed to create a rate limiting policy by Virtual Network but because there is no possibility to update a VM template. The only way to update the rate limiting with a specific value for each Nics is to update the field from the databases.

In a more efficient way, It would be more easier to give the possibility to update an instanciate VM Template and allow to recreate the VM with the updated fields.

What do you think about ?

17

you can do it from the cli, or fron the advanced mode in sunstone

18

I am sorry,

But I speak about when a VM is already running and instantiated.
In facts, there is no button on Sunstone to change the Running VM settings like (context, nics attributes, image size, …) and no possibility to change it by cli as well.

For example, If i use the same template for instantiate many VMs how to specify a specific bandwith for each of those running VM ?

Regards,

19

Sorry Sébastien, I was thinking of VM Templates. So, for changing running
VMs we have specific operations: resize (CPU, MEMORY); attach/detach disk
(for DISK attribute); attach/detach nic (for NIC); rename (NAME). Other
sections like OS, or GRAPHICS cannot be changed though.

However, I agree that we should provide a better and more convenient way to
instantiate a template with template modifications. From the CLI you can
just pass the new template parameters, and in Cloud view users can define
their own CPU/MEMORY or Networks.

The functionality in the core is implemented in one.template.instantiate;
the last parameter is a template to merge (replacing existing attributes).
I’d say the functionality is there… For your use-case the solution would
be to select the network and perf parametes…