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=`
> >
> > 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:

    Bridge br-int
        fail_mode: secure
        Port "ovn-6bb62c-0"
            Interface "ovn-6bb62c-0"
                type: geneve
                options: {csum="true", key=flow, remote_ip=""}

This relates to Southbound database stored on the engine, see the following

    "Encap": {
        "6d4b8487-7256-44f9-87b3-c885c7f4352f": {
            "ip": "",
            "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", ""],
                ["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
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
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

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