Dear oVirt Community, From my understanding oVirt does not support Open vSwitch IPSEC tunneling for GENEVE traffic (which is described on pages http://docs.openvswitch.org/en/latest/howto/ipsec/ and http://docs.openvswitch.org/en/latest/tutorials/ipsec/).

Are there plans to introduce such support? (or explicitly not to..)

Is it possible to somehow manually configure such tunneling for existing virtual networks? (even in a limited way)

Alternatively, is it possible to deploy oVirt on top of the tunneled (i.e. via VXLAN, IPSec) interfaces? This will allow to encrypt all management traffic. Such requirement arises when using oVirt deployment on third-party premises with untrusted network. Thank in advance for any clarifications. :) -- WBR, Pavel +32478910884 _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/PBLO4AQYZQQ...

On Wednesday, 11 December 2019 16:37:50 CET Dominik Holler wrote: > On Wed, Dec 11, 2019 at 1:21 PM Pavel Nakonechnyi <pavel(a)gremwell.com&gt; > > > Are there plans to introduce such support? (or explicitly not to..) > > The feature is tracked in > https://bugzilla.redhat.com/1782056 > > If you would comment on the bug about your use case and why the feature > would be helpful in your scenario, this might help to push the feature. > Great, thanks, added a comment.

> > Is it possible to somehow manually configure such tunneling for existing > > virtual networks? (even in a limited way) > > I would be interested to know, how far we are away from the flow described > in > http://docs.openvswitch.org/en/stable/tutorials/ovn-ipsec/ . > I expect that the openvswitch-ipsec package is missing. Any input on this > is welcome. > 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..

-- WBR, Pavel +32478910884

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&gt; > > 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

> > 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! I have added some notes on my attempts to the aforementioned bug (https:// bugzilla.redhat.com/show_bug.cgi?id=1782056). So, it appears to be almost working.