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
On Wed, Dec 11, 2019 at 1:21 PM Pavel Nakonechnyi <pavel@gremwell.com> wrote:
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/).
Correct, currently this is not supported.
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.
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.
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@ovirt.org To unsubscribe send an email to users-leave@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/PBLO4AQYZQQM2P...
On Wednesday, 11 December 2019 16:37:50 CET Dominik Holler wrote:
On Wed, Dec 11, 2019 at 1:21 PM Pavel Nakonechnyi <pavel@gremwell.com>
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 Thu, Dec 12, 2019 at 10:06 AM Pavel Nakonechnyi <pavel@gremwell.com> wrote:
On Wednesday, 11 December 2019 16:37:50 CET Dominik Holler wrote:
On Wed, Dec 11, 2019 at 1:21 PM Pavel Nakonechnyi <pavel@gremwell.com>
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.
Thanks for helping to adjust oVirt!
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..
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... is triggered. This triggers https://github.com/oVirt/ovirt-provider-ovn/blob/master/driver/vdsm_tool/ovn... and https://github.com/oVirt/ovirt-provider-ovn/blob/master/driver/scripts/setup... 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... Maybe the http://docs.openvswitch.org/en/stable/tutorials/ovn-ipsec/#enabling-ovn-ipse... 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!
-- 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@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
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
On Thursday, 12 December 2019 13:09:39 CET Dominik Holler wrote:
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>
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.
Thank you! Was incorrectly reading about Open vSwitch, not OpenVN. :)
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. -- WBR, Pavel +32478910884
Dear oVirt team, On Thursday, 12 December 2019 16:53:41 CET Pavel Nakonechnyi wrote:
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.
Could someone please clarify the status of the discussed issue? Bugzilla entry https://bugzilla.redhat.com/show_bug.cgi?id=1782056 recently received strange update with a link to Red-Hat knowledge base. Does this mean that the discussed functionality actually works or can be made working with some efforts? -- WBR, Pavel
participants (2)
-
Dominik Holler -
Pavel Nakonechnyi