On Thu, Dec 12, 2019 at 12:20 PM Pavel Nakonechnyi <pavel@gremwell.com> wrote:
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?
This is all done by OVN. On every host runs the ovn-controller, which configures the tunnels according to the information he gets from ovn south db. Please find a good entry in http://www.openvswitch.org/support/dist-docs/ovn-architecture.7.html but all documentation about OVN should work.
I believe that it should be done by "ovirt-provider-ovn" (triggered by something from engine),
ovirt-provider-ovn is just a mapper from OpenStack Network API to OVN. The talk in https://archive.fosdem.org/2018/schedule/event/vai_leveraging_sdn_for_virtua... especially slide 26 explains more details. You are welcome to ask more questions on this list.
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.
This would be amazing!
-- WBR, Pavel