On Thursday, 12 December 2019 10:23:28 CET Dominik Holler wrote:
On Thu, Dec 12, 2019 at 10:06 AM Pavel Nakonechnyi
<pavel(a)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