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 ?
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.
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)
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.
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.
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.
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…
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.
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
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.
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.
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 ?
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…