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