On Thursday, 12 December 2019 10:23:28 CET Dominik Holler wrote:
On Thu, Dec 12, 2019 at 10:06 AM Pavel Nakonechnyi <pavel@gremwell.com>
Could you direct me to the part of oVirt system which handles OVS tunnels creation?
It seems that at some point oVirt issues a command similar to the following one:
`ovs-vsctl add-port br-int ovn-xxx-0 -- set interface ovn-xxx-0 \
type=geneve options:csum=true key=flow options:remote_ip=1.1.1.1`
I was not able to identify were the corresponding code is located. :(
When I tried to do a bad thing, manual deletion of such tunnel interface:
`ovs-vsctl del-port br-int ovn-xxx-0`
it was immediately re-created or just was not deleted.. Still have to experiment with that..
Yes, for VM OVS networking, oVirt does not use OVS directly, instead, OVN is doing the work.
During adding or reinstalling a host, https://github.com/oVirt/ovirt-engine/tree/ovirt-engine-4.3/packaging/playbo oks/roles/ovirt-provider-ovn-driver is triggered. This triggers https://github.com/oVirt/ovirt-provider-ovn/blob/master/driver/vdsm_tool/ovn _config.py and https://github.com/oVirt/ovirt-provider-ovn/blob/master/driver/scripts/setup _ovn_controller.sh while the latter is really doing the work.
I expect that this file has to be extended by the call from http://docs.openvswitch.org/en/stable/tutorials/ovn-ipsec/#configuring-ovn-i psec
Maybe the http://docs.openvswitch.org/en/stable/tutorials/ovn-ipsec/#enabling-ovn-ipse c can be done in a first try manually.
The weak point I expect is that the package openvswitch-ipsec might be missing in our repos, details in http://docs.openvswitch.org/en/stable/tutorials/ipsec/#install-ovs-ipsec .
In a first step, this package can be built manually.
Any feedback on this would be very helpful, thanks for having a look!
Thank you, this was helpful. However, I am stuck with understanding how "tunnel" interfaces are created. For instance, if we execute `ovs-vsctl show` on some host, we get: ee590052-2dde-4635-94e0-a116511b9ba2 Bridge br-int fail_mode: secure Port "ovn-6bb62c-0" Interface "ovn-6bb62c-0" type: geneve options: {csum="true", key=flow, remote_ip="1.1.1.2"} ... This relates to Southbound database stored on the engine, see the following excerpt: "Encap": { .... "6d4b8487-7256-44f9-87b3-c885c7f4352f": { "ip": "172.18.53.202", "chassis_name": "6bb62cd8-6f97-47dd-8f0f-6bd1dbb73fd0", "options": ["map", [ ["csum", "true"] ]], "type": "geneve" } ... "Chassis": { ... "8e3bac24-ef13-476c-a79b-e2c3f5e3b152": { "name": "6bb62cd8-6f97-47dd-8f0f-6bd1dbb73fd0", "hostname": "ovirt-h2.example.com", "encaps": ["uuid", "6d4b8487-7256-44f9-87b3-c885c7f4352f"], "external_ids": ["map", [ ["datapath-type", ""], ["iface-types", "erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan"], ["ovn-bridge-mappings", ""] ]] } ... What creates all these chassis, mappings, encapsulations? I believe that it should be done by "ovirt-provider-ovn" (triggered by something from engine), however, I was not able to find any clues where in particular it is implemented... Once this is understood, it will be possible to consider altering the corresponding code to include ipsec-related options. -- WBR, Pavel