[ovirt-users] Re: Ovirt OVN help needed
On January 17, 2020 10:58:00 AM GMT+02:00, Miguel Duarte de Mora Barroso
wrote:
>On Fri, Jan 10, 2020 at 4:45 PM Strahil wrote:
>>
>> Hi Miguel,
>>
>> It seems the Cluster's switch is of type 'Linux Bridge'.
>
>I apologize, but for some reason, this thread does not have the whole
>conversation; I lost track of what we're trying to solve here.
>
>What exactly is your problem ?
>
>>
>> Best Regards,
>> Strahil NikolovOn Jan 10, 2020 12:37, Miguel Duarte de Mora Barroso
> wrote:
>> >
>> > On Mon, Jan 6, 2020 at 9:21 PM Strahil Nikolov
> wrote:
>> > >
>> > > Hi Miguel,
>> > >
>> > > I had read some blogs about OVN and I tried to collect some data
>that might hint where the issue is.
>> > >
>> > > I still struggle to "decode" that , but it may be easier for you
>or anyone on the list.
>> > >
>> > > I am eager to receive your reply.
>> > > Thanks in advance and Happy New Year !
>> >
>> > Hi,
>> >
>> > Sorry for not noticing your email before. Hope late is better than
>never ..
>> >
>> > >
>> > >
>> > > Best Regards,
>> > > Strahil Nikolov
>> > >
>> > > В сряда, 18 декември 2019 г., 21:10:31 ч. Гринуич+2, Strahil
>Nikolov написа:
>> > >
>> > >
>> > > That's a good question.
>> > > ovirtmgmt is using linux bridge, but I'm not so sure about the
>br-int.
>> > > 'brctl show' is not understanding what type is br-int , so I
>guess openvswitch.
>> > >
>> > > This is still a guess, so you can give me the command to verify
>that :)
>> >
>> > You can use the GUI for that; access "Compute > clusters" , choose
>the
>> > cluster in question, hit 'edit', then look for the 'Swtich type'
>> > entry.
>> >
>> >
>> > >
>> > > As the system was first build on 4.2.7 , most probably it never
>used anything except openvswitch.
>> > >
>> > > Thanks in advance for your help. I really appreciate that.
>> > >
>> > > Best Regards,
>> > > Strahil Nikolov
>> > >
>> > >
>> > > В сряда, 18 декември 2019 г., 17:53:31 ч. Гринуич+2, Miguel
>Duarte de Mora Barroso написа:
>> > >
>> > >
>> > > On Wed, Dec 18, 2019 at 6:35 AM Strahil Nikolov
> wrote:
>> > > >
>> > > > Hi Dominik,
>> > > >
>> > > > sadly reinstall of all hosts is not helping.
>> > > >
>> > > > @ Miguel,
>> > > >
>> > > > I have 2 clusters
>> > > > 1. Default (amd-based one) -> ovirt1 (192.168.1.90) & ovirt2
>(192.168.1.64)
>> > > > 2. Intel (intel-based one and a gluster arbiter) -> ovirt3
>(192.168.1.41)
>> > >
>> > > But what are the switch types used on the clusters: openvswitch
>*or*
>> > > legacy / linux bridges ?
>> > >
>> > >
>> > >
>> > > >
>> > > > The output of the 2 commands (after I run reinstall on all
>hosts ):
>> > > >
>> > > > [root@engine ~]# ovn-sbctl list encap
>> > > > _uuid : d4d98c65-11da-4dc8-9da3-780e7738176f
>> > > > chassis_name: "baa0199e-d1a4-484c-af13-a41bcad19dbc"
>> > > > ip : "192.168.1.90"
>> > > > options: {csum="true"}
>> > > > type: geneve
>> > > >
>> > > > _uuid : ed8744a5-a302-493b-8c3b-19a4d2e170de
>> > > > chassis_name: "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
>> > > > ip : "192.168.1.64"
>> > > > options: {csum="true"}
>> > > > type: geneve
>> > > >
>> > > > _uuid : b72ff0ab-92fc-450c-a6eb-ab2869dee217
>> > > > chassis_name: "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
>> > > > ip : "192.168.1.41"
>> > > > options: {csum="true"}
>> > > > type: geneve
>> > > >
>> > > >
>> > > > [root@engine ~]# ovn-sbctl list chassis
>> > > > _uuid : b1da5110-f477-4c60-9963-b464ab96c644
>> > > > encaps : [ed8744a5-a302-493b-8c3b-19a4d2e170de]
>> > > > external_ids: {datapath-type="",
>iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
>ovn-bridge-mappings=""}
>> > > > hostname: "ovirt2.localdomain"
>> > > > name: "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
>> > > > nb_cfg : 0
>> > > > transport_zones: []
>> > > > vtep_logical_switches: []
>> > > >
>> > > > _uuid : dcc94e1c-bf44-46a3-b9d1-45360c307b26
>> > > > encaps : [b72ff0ab-92fc-450c-a6eb-ab2869dee217]
>> > > > external_ids: {datapath-type="",
>iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
>ovn-bridge-mappings=""}
>> > > > hostname: "ovirt3.localdomain"
>> > > > name: "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
>> > > > nb_cfg : 0
>> > > > transport_zones: []
>> > > > vtep_logical_switches: []
>> > > >
>> > > > _uuid : 897b34c5-d1d1-41a7-b2fd-5f1fa203c1da
>> > > > encaps : [d4d98c65-11da-4dc8-9da3-780e7738176f]
>> > > > external_ids: {datapath-type="",
>iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
>ovn-bridge-mappings=""}
>> > > > hostname: "ovirt1.localdomain"
>> > > > name:
[ovirt-users] Re: Ovirt OVN help needed
On Fri, Jan 10, 2020 at 4:45 PM Strahil wrote:
>
> Hi Miguel,
>
> It seems the Cluster's switch is of type 'Linux Bridge'.
I apologize, but for some reason, this thread does not have the whole
conversation; I lost track of what we're trying to solve here.
What exactly is your problem ?
>
> Best Regards,
> Strahil NikolovOn Jan 10, 2020 12:37, Miguel Duarte de Mora Barroso
> wrote:
> >
> > On Mon, Jan 6, 2020 at 9:21 PM Strahil Nikolov
> > wrote:
> > >
> > > Hi Miguel,
> > >
> > > I had read some blogs about OVN and I tried to collect some data that
> > > might hint where the issue is.
> > >
> > > I still struggle to "decode" that , but it may be easier for you or
> > > anyone on the list.
> > >
> > > I am eager to receive your reply.
> > > Thanks in advance and Happy New Year !
> >
> > Hi,
> >
> > Sorry for not noticing your email before. Hope late is better than never ..
> >
> > >
> > >
> > > Best Regards,
> > > Strahil Nikolov
> > >
> > > В сряда, 18 декември 2019 г., 21:10:31 ч. Гринуич+2, Strahil Nikolov
> > > написа:
> > >
> > >
> > > That's a good question.
> > > ovirtmgmt is using linux bridge, but I'm not so sure about the br-int.
> > > 'brctl show' is not understanding what type is br-int , so I guess
> > > openvswitch.
> > >
> > > This is still a guess, so you can give me the command to verify that :)
> >
> > You can use the GUI for that; access "Compute > clusters" , choose the
> > cluster in question, hit 'edit', then look for the 'Swtich type'
> > entry.
> >
> >
> > >
> > > As the system was first build on 4.2.7 , most probably it never used
> > > anything except openvswitch.
> > >
> > > Thanks in advance for your help. I really appreciate that.
> > >
> > > Best Regards,
> > > Strahil Nikolov
> > >
> > >
> > > В сряда, 18 декември 2019 г., 17:53:31 ч. Гринуич+2, Miguel Duarte de
> > > Mora Barroso написа:
> > >
> > >
> > > On Wed, Dec 18, 2019 at 6:35 AM Strahil Nikolov
> > > wrote:
> > > >
> > > > Hi Dominik,
> > > >
> > > > sadly reinstall of all hosts is not helping.
> > > >
> > > > @ Miguel,
> > > >
> > > > I have 2 clusters
> > > > 1. Default (amd-based one) -> ovirt1 (192.168.1.90) & ovirt2
> > > > (192.168.1.64)
> > > > 2. Intel (intel-based one and a gluster arbiter) -> ovirt3
> > > > (192.168.1.41)
> > >
> > > But what are the switch types used on the clusters: openvswitch *or*
> > > legacy / linux bridges ?
> > >
> > >
> > >
> > > >
> > > > The output of the 2 commands (after I run reinstall on all hosts ):
> > > >
> > > > [root@engine ~]# ovn-sbctl list encap
> > > > _uuid : d4d98c65-11da-4dc8-9da3-780e7738176f
> > > > chassis_name: "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> > > > ip : "192.168.1.90"
> > > > options: {csum="true"}
> > > > type: geneve
> > > >
> > > > _uuid : ed8744a5-a302-493b-8c3b-19a4d2e170de
> > > > chassis_name: "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> > > > ip : "192.168.1.64"
> > > > options: {csum="true"}
> > > > type: geneve
> > > >
> > > > _uuid : b72ff0ab-92fc-450c-a6eb-ab2869dee217
> > > > chassis_name: "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> > > > ip : "192.168.1.41"
> > > > options: {csum="true"}
> > > > type: geneve
> > > >
> > > >
> > > > [root@engine ~]# ovn-sbctl list chassis
> > > > _uuid : b1da5110-f477-4c60-9963-b464ab96c644
> > > > encaps : [ed8744a5-a302-493b-8c3b-19a4d2e170de]
> > > > external_ids: {datapath-type="",
> > > > iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> > > > ovn-bridge-mappings=""}
> > > > hostname: "ovirt2.localdomain"
> > > > name: "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> > > > nb_cfg : 0
> > > > transport_zones: []
> > > > vtep_logical_switches: []
> > > >
> > > > _uuid : dcc94e1c-bf44-46a3-b9d1-45360c307b26
> > > > encaps : [b72ff0ab-92fc-450c-a6eb-ab2869dee217]
> > > > external_ids: {datapath-type="",
> > > > iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> > > > ovn-bridge-mappings=""}
> > > > hostname: "ovirt3.localdomain"
> > > > name: "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> > > > nb_cfg : 0
> > > > transport_zones: []
> > > > vtep_logical_switches: []
> > > >
> > > > _uuid : 897b34c5-d1d1-41a7-b2fd-5f1fa203c1da
> > > > encaps : [d4d98c65-11da-4dc8-9da3-780e7738176f]
> > > > external_ids: {datapath-type="",
> > > > iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> > > > ovn-bridge-mappings=""}
> > > > hostname: "ovirt1.localdomain"
> > > > name: "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> > > > nb_cfg : 0
> > > > transport_zones: []
> >
[ovirt-users] Re: Ovirt OVN help needed
Hi Miguel,
It seems the Cluster's switch is of type 'Linux Bridge'.
Best Regards,
Strahil NikolovOn Jan 10, 2020 12:37, Miguel Duarte de Mora Barroso
wrote:
>
> On Mon, Jan 6, 2020 at 9:21 PM Strahil Nikolov wrote:
> >
> > Hi Miguel,
> >
> > I had read some blogs about OVN and I tried to collect some data that might
> > hint where the issue is.
> >
> > I still struggle to "decode" that , but it may be easier for you or anyone
> > on the list.
> >
> > I am eager to receive your reply.
> > Thanks in advance and Happy New Year !
>
> Hi,
>
> Sorry for not noticing your email before. Hope late is better than never ..
>
> >
> >
> > Best Regards,
> > Strahil Nikolov
> >
> > В сряда, 18 декември 2019 г., 21:10:31 ч. Гринуич+2, Strahil Nikolov
> > написа:
> >
> >
> > That's a good question.
> > ovirtmgmt is using linux bridge, but I'm not so sure about the br-int.
> > 'brctl show' is not understanding what type is br-int , so I guess
> > openvswitch.
> >
> > This is still a guess, so you can give me the command to verify that :)
>
> You can use the GUI for that; access "Compute > clusters" , choose the
> cluster in question, hit 'edit', then look for the 'Swtich type'
> entry.
>
>
> >
> > As the system was first build on 4.2.7 , most probably it never used
> > anything except openvswitch.
> >
> > Thanks in advance for your help. I really appreciate that.
> >
> > Best Regards,
> > Strahil Nikolov
> >
> >
> > В сряда, 18 декември 2019 г., 17:53:31 ч. Гринуич+2, Miguel Duarte de Mora
> > Barroso написа:
> >
> >
> > On Wed, Dec 18, 2019 at 6:35 AM Strahil Nikolov
> > wrote:
> > >
> > > Hi Dominik,
> > >
> > > sadly reinstall of all hosts is not helping.
> > >
> > > @ Miguel,
> > >
> > > I have 2 clusters
> > > 1. Default (amd-based one) -> ovirt1 (192.168.1.90) & ovirt2
> > > (192.168.1.64)
> > > 2. Intel (intel-based one and a gluster arbiter) -> ovirt3 (192.168.1.41)
> >
> > But what are the switch types used on the clusters: openvswitch *or*
> > legacy / linux bridges ?
> >
> >
> >
> > >
> > > The output of the 2 commands (after I run reinstall on all hosts ):
> > >
> > > [root@engine ~]# ovn-sbctl list encap
> > > _uuid : d4d98c65-11da-4dc8-9da3-780e7738176f
> > > chassis_name : "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> > > ip : "192.168.1.90"
> > > options : {csum="true"}
> > > type : geneve
> > >
> > > _uuid : ed8744a5-a302-493b-8c3b-19a4d2e170de
> > > chassis_name : "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> > > ip : "192.168.1.64"
> > > options : {csum="true"}
> > > type : geneve
> > >
> > > _uuid : b72ff0ab-92fc-450c-a6eb-ab2869dee217
> > > chassis_name : "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> > > ip : "192.168.1.41"
> > > options : {csum="true"}
> > > type : geneve
> > >
> > >
> > > [root@engine ~]# ovn-sbctl list chassis
> > > _uuid : b1da5110-f477-4c60-9963-b464ab96c644
> > > encaps : [ed8744a5-a302-493b-8c3b-19a4d2e170de]
> > > external_ids : {datapath-type="",
> > > iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> > > ovn-bridge-mappings=""}
> > > hostname : "ovirt2.localdomain"
> > > name : "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> > > nb_cfg : 0
> > > transport_zones : []
> > > vtep_logical_switches: []
> > >
> > > _uuid : dcc94e1c-bf44-46a3-b9d1-45360c307b26
> > > encaps : [b72ff0ab-92fc-450c-a6eb-ab2869dee217]
> > > external_ids : {datapath-type="",
> > > iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> > > ovn-bridge-mappings=""}
> > > hostname : "ovirt3.localdomain"
> > > name : "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> > > nb_cfg : 0
> > > transport_zones : []
> > > vtep_logical_switches: []
> > >
> > > _uuid : 897b34c5-d1d1-41a7-b2fd-5f1fa203c1da
> > > encaps : [d4d98c65-11da-4dc8-9da3-780e7738176f]
> > > external_ids : {datapath-type="",
> > > iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> > > ovn-bridge-mappings=""}
> > > hostname : "ovirt1.localdomain"
> > > name : "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> > > nb_cfg : 0
> > > transport_zones : []
> > > vtep_logical_switches: []
> > >
> > >
> > > If you know an easy method to reach default settings will be best, as I'm
> > > currently not using OVN in production (just for tests and to learn more
> > > about how it works) and I can afford any kind of downtime.
> > >
> > > Best Regards,
> > > Strahil Nikolov
> > >
> > > В вторник, 17 декември 2019 г., 11:28:25 ч. Гринуич+2,
[ovirt-users] Re: Ovirt OVN help needed
On Mon, Jan 6, 2020 at 9:21 PM Strahil Nikolov wrote:
>
> Hi Miguel,
>
> I had read some blogs about OVN and I tried to collect some data that might
> hint where the issue is.
>
> I still struggle to "decode" that , but it may be easier for you or anyone on
> the list.
>
> I am eager to receive your reply.
> Thanks in advance and Happy New Year !
Hi,
Sorry for not noticing your email before. Hope late is better than never ..
>
>
> Best Regards,
> Strahil Nikolov
>
> В сряда, 18 декември 2019 г., 21:10:31 ч. Гринуич+2, Strahil Nikolov
> написа:
>
>
> That's a good question.
> ovirtmgmt is using linux bridge, but I'm not so sure about the br-int.
> 'brctl show' is not understanding what type is br-int , so I guess
> openvswitch.
>
> This is still a guess, so you can give me the command to verify that :)
You can use the GUI for that; access "Compute > clusters" , choose the
cluster in question, hit 'edit', then look for the 'Swtich type'
entry.
>
> As the system was first build on 4.2.7 , most probably it never used anything
> except openvswitch.
>
> Thanks in advance for your help. I really appreciate that.
>
> Best Regards,
> Strahil Nikolov
>
>
> В сряда, 18 декември 2019 г., 17:53:31 ч. Гринуич+2, Miguel Duarte de Mora
> Barroso написа:
>
>
> On Wed, Dec 18, 2019 at 6:35 AM Strahil Nikolov wrote:
> >
> > Hi Dominik,
> >
> > sadly reinstall of all hosts is not helping.
> >
> > @ Miguel,
> >
> > I have 2 clusters
> > 1. Default (amd-based one) -> ovirt1 (192.168.1.90) & ovirt2 (192.168.1.64)
> > 2. Intel (intel-based one and a gluster arbiter) -> ovirt3 (192.168.1.41)
>
> But what are the switch types used on the clusters: openvswitch *or*
> legacy / linux bridges ?
>
>
>
> >
> > The output of the 2 commands (after I run reinstall on all hosts ):
> >
> > [root@engine ~]# ovn-sbctl list encap
> > _uuid : d4d98c65-11da-4dc8-9da3-780e7738176f
> > chassis_name: "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> > ip : "192.168.1.90"
> > options: {csum="true"}
> > type: geneve
> >
> > _uuid : ed8744a5-a302-493b-8c3b-19a4d2e170de
> > chassis_name: "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> > ip : "192.168.1.64"
> > options: {csum="true"}
> > type: geneve
> >
> > _uuid : b72ff0ab-92fc-450c-a6eb-ab2869dee217
> > chassis_name: "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> > ip : "192.168.1.41"
> > options: {csum="true"}
> > type: geneve
> >
> >
> > [root@engine ~]# ovn-sbctl list chassis
> > _uuid : b1da5110-f477-4c60-9963-b464ab96c644
> > encaps : [ed8744a5-a302-493b-8c3b-19a4d2e170de]
> > external_ids: {datapath-type="",
> > iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> > ovn-bridge-mappings=""}
> > hostname: "ovirt2.localdomain"
> > name: "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> > nb_cfg : 0
> > transport_zones: []
> > vtep_logical_switches: []
> >
> > _uuid : dcc94e1c-bf44-46a3-b9d1-45360c307b26
> > encaps : [b72ff0ab-92fc-450c-a6eb-ab2869dee217]
> > external_ids: {datapath-type="",
> > iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> > ovn-bridge-mappings=""}
> > hostname: "ovirt3.localdomain"
> > name: "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> > nb_cfg : 0
> > transport_zones: []
> > vtep_logical_switches: []
> >
> > _uuid : 897b34c5-d1d1-41a7-b2fd-5f1fa203c1da
> > encaps : [d4d98c65-11da-4dc8-9da3-780e7738176f]
> > external_ids: {datapath-type="",
> > iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> > ovn-bridge-mappings=""}
> > hostname: "ovirt1.localdomain"
> > name: "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> > nb_cfg : 0
> > transport_zones: []
> > vtep_logical_switches: []
> >
> >
> > If you know an easy method to reach default settings will be best, as I'm
> > currently not using OVN in production (just for tests and to learn more
> > about how it works) and I can afford any kind of downtime.
> >
> > Best Regards,
> > Strahil Nikolov
> >
> > В вторник, 17 декември 2019 г., 11:28:25 ч. Гринуич+2, Miguel Duarte de
> > Mora Barroso написа:
> >
> >
> > On Tue, Dec 17, 2019 at 10:19 AM Miguel Duarte de Mora Barroso
> > wrote:
> > >
> > > On Tue, Dec 17, 2019 at 9:17 AM Dominik Holler wrote:
> > > >
> > > >
> > > >
> > > > On Tue, Dec 17, 2019 at 6:28 AM Strahil wrote:
> > > >>
> > > >> Hi Dominik,
> > > >>
> > > >> Thanks for your reply.
> > > >>
> > > >> On ovirt1 I got the following:
> > > >> [root@ovirt1 openvswitch]# less ovn-controller.log-20191216.gz
> > > >> 2019-12-15T01:49:02.988Z|00032|vlog|INFO|opened log file
> > > >>
[ovirt-users] Re: Ovirt OVN help needed
Hi Miguel,
I had read some blogs about OVN and I tried to collect some data that might
hint where the issue is.
I still struggle to "decode" that , but it may be easier for you or anyone on
the list.
I am eager to receive your reply.
Thanks in advance and Happy New Year !
Best Regards,Strahil Nikolov
В сряда, 18 декември 2019 г., 21:10:31 ч. Гринуич+2, Strahil Nikolov
написа:
That's a good question.ovirtmgmt is using linux bridge, but I'm not so sure
about the br-int.'brctl show' is not understanding what type is br-int , so I
guess openvswitch.
This is still a guess, so you can give me the command to verify that :)
As the system was first build on 4.2.7 , most probably it never used anything
except openvswitch.
Thanks in advance for your help. I really appreciate that.
Best Regards,Strahil Nikolov
В сряда, 18 декември 2019 г., 17:53:31 ч. Гринуич+2, Miguel Duarte de Mora
Barroso написа:
On Wed, Dec 18, 2019 at 6:35 AM Strahil Nikolov wrote:
>
> Hi Dominik,
>
> sadly reinstall of all hosts is not helping.
>
> @ Miguel,
>
> I have 2 clusters
> 1. Default (amd-based one) -> ovirt1 (192.168.1.90) & ovirt2 (192.168.1.64)
> 2. Intel (intel-based one and a gluster arbiter) -> ovirt3 (192.168.1.41)
But what are the switch types used on the clusters: openvswitch *or*
legacy / linux bridges ?
>
> The output of the 2 commands (after I run reinstall on all hosts ):
>
> [root@engine ~]# ovn-sbctl list encap
> _uuid : d4d98c65-11da-4dc8-9da3-780e7738176f
> chassis_name : "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> ip : "192.168.1.90"
> options : {csum="true"}
> type : geneve
>
> _uuid : ed8744a5-a302-493b-8c3b-19a4d2e170de
> chassis_name : "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> ip : "192.168.1.64"
> options : {csum="true"}
> type : geneve
>
> _uuid : b72ff0ab-92fc-450c-a6eb-ab2869dee217
> chassis_name : "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> ip : "192.168.1.41"
> options : {csum="true"}
> type : geneve
>
>
> [root@engine ~]# ovn-sbctl list chassis
> _uuid : b1da5110-f477-4c60-9963-b464ab96c644
> encaps : [ed8744a5-a302-493b-8c3b-19a4d2e170de]
> external_ids : {datapath-type="",
> iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> ovn-bridge-mappings=""}
> hostname : "ovirt2.localdomain"
> name : "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> nb_cfg : 0
> transport_zones : []
> vtep_logical_switches: []
>
> _uuid : dcc94e1c-bf44-46a3-b9d1-45360c307b26
> encaps : [b72ff0ab-92fc-450c-a6eb-ab2869dee217]
> external_ids : {datapath-type="",
> iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> ovn-bridge-mappings=""}
> hostname : "ovirt3.localdomain"
> name : "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> nb_cfg : 0
> transport_zones : []
> vtep_logical_switches: []
>
> _uuid : 897b34c5-d1d1-41a7-b2fd-5f1fa203c1da
> encaps : [d4d98c65-11da-4dc8-9da3-780e7738176f]
> external_ids : {datapath-type="",
> iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> ovn-bridge-mappings=""}
> hostname : "ovirt1.localdomain"
> name : "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> nb_cfg : 0
> transport_zones : []
> vtep_logical_switches: []
>
>
> If you know an easy method to reach default settings will be best, as I'm
> currently not using OVN in production (just for tests and to learn more about
> how it works) and I can afford any kind of downtime.
>
> Best Regards,
> Strahil Nikolov
>
> В вторник, 17 декември 2019 г., 11:28:25 ч. Гринуич+2, Miguel Duarte de Mora
> Barroso написа:
>
>
> On Tue, Dec 17, 2019 at 10:19 AM Miguel Duarte de Mora Barroso
> wrote:
> >
> > On Tue, Dec 17, 2019 at 9:17 AM Dominik Holler wrote:
> > >
> > >
> > >
> > > On Tue, Dec 17, 2019 at 6:28 AM Strahil wrote:
> > >>
> > >> Hi Dominik,
> > >>
> > >> Thanks for your reply.
> > >>
> > >> On ovirt1 I got the following:
> > >> [root@ovirt1 openvswitch]# less ovn-controller.log-20191216.gz
> > >> 2019-12-15T01:49:02.988Z|00032|vlog|INFO|opened log file
> > >> /var/log/openvswitch/ovn-controller.log
> > >> 2019-12-16T01:18:02.114Z|00033|vlog|INFO|closing log file
> > >> ovn-controller.log-20191216.gz (END)
> > >>
> > >> Same is on the other node:
> > >>
> > >> [root@ovirt2 openvswitch]# less ovn-controller.log-20191216.gz
> > >> 2019-12-15T01:26:03.477Z|00028|vlog|INFO|opened log file
> > >> /var/log/openvswitch/ovn-controller.log
> > >> 2019-12-16T01:30:01.718Z|00029|vlog|INFO|closing log file
> > >> ovn-controller.log-20191216.gz (END)
> > >>
> > >> The strange thing is that the geneve tunnels are
[ovirt-users] Re: Ovirt OVN help needed
That's a good question.ovirtmgmt is using linux bridge, but I'm not so sure
about the br-int.'brctl show' is not understanding what type is br-int , so I
guess openvswitch.
This is still a guess, so you can give me the command to verify that :)
As the system was first build on 4.2.7 , most probably it never used anything
except openvswitch.
Thanks in advance for your help. I really appreciate that.
Best Regards,Strahil Nikolov
В сряда, 18 декември 2019 г., 17:53:31 ч. Гринуич+2, Miguel Duarte de Mora
Barroso написа:
On Wed, Dec 18, 2019 at 6:35 AM Strahil Nikolov wrote:
>
> Hi Dominik,
>
> sadly reinstall of all hosts is not helping.
>
> @ Miguel,
>
> I have 2 clusters
> 1. Default (amd-based one) -> ovirt1 (192.168.1.90) & ovirt2 (192.168.1.64)
> 2. Intel (intel-based one and a gluster arbiter) -> ovirt3 (192.168.1.41)
But what are the switch types used on the clusters: openvswitch *or*
legacy / linux bridges ?
>
> The output of the 2 commands (after I run reinstall on all hosts ):
>
> [root@engine ~]# ovn-sbctl list encap
> _uuid : d4d98c65-11da-4dc8-9da3-780e7738176f
> chassis_name : "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> ip : "192.168.1.90"
> options : {csum="true"}
> type : geneve
>
> _uuid : ed8744a5-a302-493b-8c3b-19a4d2e170de
> chassis_name : "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> ip : "192.168.1.64"
> options : {csum="true"}
> type : geneve
>
> _uuid : b72ff0ab-92fc-450c-a6eb-ab2869dee217
> chassis_name : "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> ip : "192.168.1.41"
> options : {csum="true"}
> type : geneve
>
>
> [root@engine ~]# ovn-sbctl list chassis
> _uuid : b1da5110-f477-4c60-9963-b464ab96c644
> encaps : [ed8744a5-a302-493b-8c3b-19a4d2e170de]
> external_ids : {datapath-type="",
> iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> ovn-bridge-mappings=""}
> hostname : "ovirt2.localdomain"
> name : "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> nb_cfg : 0
> transport_zones : []
> vtep_logical_switches: []
>
> _uuid : dcc94e1c-bf44-46a3-b9d1-45360c307b26
> encaps : [b72ff0ab-92fc-450c-a6eb-ab2869dee217]
> external_ids : {datapath-type="",
> iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> ovn-bridge-mappings=""}
> hostname : "ovirt3.localdomain"
> name : "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> nb_cfg : 0
> transport_zones : []
> vtep_logical_switches: []
>
> _uuid : 897b34c5-d1d1-41a7-b2fd-5f1fa203c1da
> encaps : [d4d98c65-11da-4dc8-9da3-780e7738176f]
> external_ids : {datapath-type="",
> iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> ovn-bridge-mappings=""}
> hostname : "ovirt1.localdomain"
> name : "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> nb_cfg : 0
> transport_zones : []
> vtep_logical_switches: []
>
>
> If you know an easy method to reach default settings will be best, as I'm
> currently not using OVN in production (just for tests and to learn more about
> how it works) and I can afford any kind of downtime.
>
> Best Regards,
> Strahil Nikolov
>
> В вторник, 17 декември 2019 г., 11:28:25 ч. Гринуич+2, Miguel Duarte de Mora
> Barroso написа:
>
>
> On Tue, Dec 17, 2019 at 10:19 AM Miguel Duarte de Mora Barroso
> wrote:
> >
> > On Tue, Dec 17, 2019 at 9:17 AM Dominik Holler wrote:
> > >
> > >
> > >
> > > On Tue, Dec 17, 2019 at 6:28 AM Strahil wrote:
> > >>
> > >> Hi Dominik,
> > >>
> > >> Thanks for your reply.
> > >>
> > >> On ovirt1 I got the following:
> > >> [root@ovirt1 openvswitch]# less ovn-controller.log-20191216.gz
> > >> 2019-12-15T01:49:02.988Z|00032|vlog|INFO|opened log file
> > >> /var/log/openvswitch/ovn-controller.log
> > >> 2019-12-16T01:18:02.114Z|00033|vlog|INFO|closing log file
> > >> ovn-controller.log-20191216.gz (END)
> > >>
> > >> Same is on the other node:
> > >>
> > >> [root@ovirt2 openvswitch]# less ovn-controller.log-20191216.gz
> > >> 2019-12-15T01:26:03.477Z|00028|vlog|INFO|opened log file
> > >> /var/log/openvswitch/ovn-controller.log
> > >> 2019-12-16T01:30:01.718Z|00029|vlog|INFO|closing log file
> > >> ovn-controller.log-20191216.gz (END)
> > >>
> > >> The strange thing is that the geneve tunnels are there:
> > >
> > >
> > >
> > > Miguel, do you know how to remove and re-add the chassis to the
> > > southbound db?
> > > (We have to check this to address bug https://bugzilla.redhat.com/1758289
> > > )
> >
> > "ovn-sbctl chassis-del CHASSIS" will get rid of the chassis / encap.
> >
> > Afterwards, the ovn-controller will re-register itself on OVN southbound.
> >
> > There's something weird
[ovirt-users] Re: Ovirt OVN help needed
On Wed, Dec 18, 2019 at 6:35 AM Strahil Nikolov wrote:
>
> Hi Dominik,
>
> sadly reinstall of all hosts is not helping.
>
> @ Miguel,
>
> I have 2 clusters
> 1. Default (amd-based one) -> ovirt1 (192.168.1.90) & ovirt2 (192.168.1.64)
> 2. Intel (intel-based one and a gluster arbiter) -> ovirt3 (192.168.1.41)
But what are the switch types used on the clusters: openvswitch *or*
legacy / linux bridges ?
>
> The output of the 2 commands (after I run reinstall on all hosts ):
>
> [root@engine ~]# ovn-sbctl list encap
> _uuid : d4d98c65-11da-4dc8-9da3-780e7738176f
> chassis_name: "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> ip : "192.168.1.90"
> options : {csum="true"}
> type: geneve
>
> _uuid : ed8744a5-a302-493b-8c3b-19a4d2e170de
> chassis_name: "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> ip : "192.168.1.64"
> options : {csum="true"}
> type: geneve
>
> _uuid : b72ff0ab-92fc-450c-a6eb-ab2869dee217
> chassis_name: "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> ip : "192.168.1.41"
> options : {csum="true"}
> type: geneve
>
>
> [root@engine ~]# ovn-sbctl list chassis
> _uuid : b1da5110-f477-4c60-9963-b464ab96c644
> encaps : [ed8744a5-a302-493b-8c3b-19a4d2e170de]
> external_ids: {datapath-type="",
> iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> ovn-bridge-mappings=""}
> hostname: "ovirt2.localdomain"
> name: "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> nb_cfg : 0
> transport_zones : []
> vtep_logical_switches: []
>
> _uuid : dcc94e1c-bf44-46a3-b9d1-45360c307b26
> encaps : [b72ff0ab-92fc-450c-a6eb-ab2869dee217]
> external_ids: {datapath-type="",
> iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> ovn-bridge-mappings=""}
> hostname: "ovirt3.localdomain"
> name: "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> nb_cfg : 0
> transport_zones : []
> vtep_logical_switches: []
>
> _uuid : 897b34c5-d1d1-41a7-b2fd-5f1fa203c1da
> encaps : [d4d98c65-11da-4dc8-9da3-780e7738176f]
> external_ids: {datapath-type="",
> iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
> ovn-bridge-mappings=""}
> hostname: "ovirt1.localdomain"
> name: "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> nb_cfg : 0
> transport_zones : []
> vtep_logical_switches: []
>
>
> If you know an easy method to reach default settings will be best, as I'm
> currently not using OVN in production (just for tests and to learn more about
> how it works) and I can afford any kind of downtime.
>
> Best Regards,
> Strahil Nikolov
>
> В вторник, 17 декември 2019 г., 11:28:25 ч. Гринуич+2, Miguel Duarte de Mora
> Barroso написа:
>
>
> On Tue, Dec 17, 2019 at 10:19 AM Miguel Duarte de Mora Barroso
> wrote:
> >
> > On Tue, Dec 17, 2019 at 9:17 AM Dominik Holler wrote:
> > >
> > >
> > >
> > > On Tue, Dec 17, 2019 at 6:28 AM Strahil wrote:
> > >>
> > >> Hi Dominik,
> > >>
> > >> Thanks for your reply.
> > >>
> > >> On ovirt1 I got the following:
> > >> [root@ovirt1 openvswitch]# less ovn-controller.log-20191216.gz
> > >> 2019-12-15T01:49:02.988Z|00032|vlog|INFO|opened log file
> > >> /var/log/openvswitch/ovn-controller.log
> > >> 2019-12-16T01:18:02.114Z|00033|vlog|INFO|closing log file
> > >> ovn-controller.log-20191216.gz (END)
> > >>
> > >> Same is on the other node:
> > >>
> > >> [root@ovirt2 openvswitch]# less ovn-controller.log-20191216.gz
> > >> 2019-12-15T01:26:03.477Z|00028|vlog|INFO|opened log file
> > >> /var/log/openvswitch/ovn-controller.log
> > >> 2019-12-16T01:30:01.718Z|00029|vlog|INFO|closing log file
> > >> ovn-controller.log-20191216.gz (END)
> > >>
> > >> The strange thing is that the geneve tunnels are there:
> > >
> > >
> > >
> > > Miguel, do you know how to remove and re-add the chassis to the
> > > southbound db?
> > > (We have to check this to address bug https://bugzilla.redhat.com/1758289
> > > )
> >
> > "ovn-sbctl chassis-del CHASSIS" will get rid of the chassis / encap.
> >
> > Afterwards, the ovn-controller will re-register itself on OVN southbound.
> >
> > There's something weird about your chassis, I see you have listed 3
> > different chassis IDs on your port IDs:
> > - ovn-chassis-id="5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3@192.168.1.41"
> > - ovn-chassis-id="25cc77b3-046f-45c5-af0c-ffb2f77d73f1@192.168.1.64"
> > - ovn-chassis-id="baa0199e-d1a4-484c-af13-a41bcad19dbc@192.168.1.90"
> >
> > From your 'ovs-vsctl show' I can see the IP encaps 192.168.1.41 and
> > 192.168.1.64 are 'expected'.
> >
> > I would expect to see a duplicate chassis entry in the same IP . Who
> > has this 192.168.1.90 IP ?
>
[ovirt-users] Re: Ovirt OVN help needed
Hi Dominik,
sadly reinstall of all hosts is not helping.
@ Miguel,
I have 2 clusters1. Default (amd-based one) -> ovirt1 (192.168.1.90) & ovirt2
(192.168.1.64)2. Intel (intel-based one and a gluster arbiter) -> ovirt3
(192.168.1.41)
The output of the 2 commands (after I run reinstall on all hosts ):
[root@engine ~]# ovn-sbctl list encap_uuid :
d4d98c65-11da-4dc8-9da3-780e7738176fchassis_name :
"baa0199e-d1a4-484c-af13-a41bcad19dbc"ip :
"192.168.1.90"options : {csum="true"}type : geneve
_uuid : ed8744a5-a302-493b-8c3b-19a4d2e170dechassis_name :
"25cc77b3-046f-45c5-af0c-ffb2f77d73f1"ip :
"192.168.1.64"options : {csum="true"}type : geneve
_uuid : b72ff0ab-92fc-450c-a6eb-ab2869dee217chassis_name :
"5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"ip :
"192.168.1.41"options : {csum="true"}type : geneve
[root@engine ~]# ovn-sbctl list chassis_uuid :
b1da5110-f477-4c60-9963-b464ab96c644encaps :
[ed8744a5-a302-493b-8c3b-19a4d2e170de]external_ids : {datapath-type="",
iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
ovn-bridge-mappings=""}hostname : "ovirt2.localdomain"name
: "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"nb_cfg :
0transport_zones : []vtep_logical_switches: []
_uuid : dcc94e1c-bf44-46a3-b9d1-45360c307b26encaps :
[b72ff0ab-92fc-450c-a6eb-ab2869dee217]external_ids : {datapath-type="",
iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
ovn-bridge-mappings=""}hostname : "ovirt3.localdomain"name
: "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"nb_cfg :
0transport_zones : []vtep_logical_switches: []
_uuid : 897b34c5-d1d1-41a7-b2fd-5f1fa203c1daencaps :
[d4d98c65-11da-4dc8-9da3-780e7738176f]external_ids : {datapath-type="",
iface-types="erspan,geneve,gre,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan",
ovn-bridge-mappings=""}hostname : "ovirt1.localdomain"name
: "baa0199e-d1a4-484c-af13-a41bcad19dbc"nb_cfg :
0transport_zones : []vtep_logical_switches: []
If you know an easy method to reach default settings will be best, as I'm
currently not using OVN in production (just for tests and to learn more about
how it works) and I can afford any kind of downtime.
Best Regards,Strahil Nikolov
В вторник, 17 декември 2019 г., 11:28:25 ч. Гринуич+2, Miguel Duarte de
Mora Barroso написа:
On Tue, Dec 17, 2019 at 10:19 AM Miguel Duarte de Mora Barroso
wrote:
>
> On Tue, Dec 17, 2019 at 9:17 AM Dominik Holler wrote:
> >
> >
> >
> > On Tue, Dec 17, 2019 at 6:28 AM Strahil wrote:
> >>
> >> Hi Dominik,
> >>
> >> Thanks for your reply.
> >>
> >> On ovirt1 I got the following:
> >> [root@ovirt1 openvswitch]# less ovn-controller.log-20191216.gz
> >> 2019-12-15T01:49:02.988Z|00032|vlog|INFO|opened log file
> >> /var/log/openvswitch/ovn-controller.log
> >> 2019-12-16T01:18:02.114Z|00033|vlog|INFO|closing log file
> >> ovn-controller.log-20191216.gz (END)
> >>
> >> Same is on the other node:
> >>
> >> [root@ovirt2 openvswitch]# less ovn-controller.log-20191216.gz
> >> 2019-12-15T01:26:03.477Z|00028|vlog|INFO|opened log file
> >> /var/log/openvswitch/ovn-controller.log
> >> 2019-12-16T01:30:01.718Z|00029|vlog|INFO|closing log file
> >> ovn-controller.log-20191216.gz (END)
> >>
> >> The strange thing is that the geneve tunnels are there:
> >
> >
> >
> > Miguel, do you know how to remove and re-add the chassis to the southbound
> > db?
> > (We have to check this to address bug https://bugzilla.redhat.com/1758289 )
>
> "ovn-sbctl chassis-del CHASSIS" will get rid of the chassis / encap.
>
> Afterwards, the ovn-controller will re-register itself on OVN southbound.
>
> There's something weird about your chassis, I see you have listed 3
> different chassis IDs on your port IDs:
> - ovn-chassis-id="5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3@192.168.1.41"
> - ovn-chassis-id="25cc77b3-046f-45c5-af0c-ffb2f77d73f1@192.168.1.64"
> - ovn-chassis-id="baa0199e-d1a4-484c-af13-a41bcad19dbc@192.168.1.90"
>
> From your 'ovs-vsctl show' I can see the IP encaps 192.168.1.41 and
> 192.168.1.64 are 'expected'.
>
> I would expect to see a duplicate chassis entry in the same IP . Who
> has this 192.168.1.90 IP ?
>
> A couple of further questions:
> - did you upgrade recently your environment ? If so, from which
> version to which version ?
> - what is the switch type of the cluster where you are running OVN ?
- what is the output of "ovn-sbctl list chassis" and "ovn-sbctl list
encap" on your engine node ?
>
> >
> >>
> >> [root@ovirt1 ~]# ovs-vsctl show
> >> c0e938f1-b5b5-4d5a-9cda-29dae2986f29
> >> Bridge br-int
> >>
[ovirt-users] Re: Ovirt OVN help needed
On Tue, Dec 17, 2019 at 10:19 AM Miguel Duarte de Mora Barroso
wrote:
>
> On Tue, Dec 17, 2019 at 9:17 AM Dominik Holler wrote:
> >
> >
> >
> > On Tue, Dec 17, 2019 at 6:28 AM Strahil wrote:
> >>
> >> Hi Dominik,
> >>
> >> Thanks for your reply.
> >>
> >> On ovirt1 I got the following:
> >> [root@ovirt1 openvswitch]# less ovn-controller.log-20191216.gz
> >> 2019-12-15T01:49:02.988Z|00032|vlog|INFO|opened log file
> >> /var/log/openvswitch/ovn-controller.log
> >> 2019-12-16T01:18:02.114Z|00033|vlog|INFO|closing log file
> >> ovn-controller.log-20191216.gz (END)
> >>
> >> Same is on the other node:
> >>
> >> [root@ovirt2 openvswitch]# less ovn-controller.log-20191216.gz
> >> 2019-12-15T01:26:03.477Z|00028|vlog|INFO|opened log file
> >> /var/log/openvswitch/ovn-controller.log
> >> 2019-12-16T01:30:01.718Z|00029|vlog|INFO|closing log file
> >> ovn-controller.log-20191216.gz (END)
> >>
> >> The strange thing is that the geneve tunnels are there:
> >
> >
> >
> > Miguel, do you know how to remove and re-add the chassis to the southbound
> > db?
> > (We have to check this to address bug https://bugzilla.redhat.com/1758289 )
>
> "ovn-sbctl chassis-del CHASSIS" will get rid of the chassis / encap.
>
> Afterwards, the ovn-controller will re-register itself on OVN southbound.
>
> There's something weird about your chassis, I see you have listed 3
> different chassis IDs on your port IDs:
> - ovn-chassis-id="5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3@192.168.1.41"
> - ovn-chassis-id="25cc77b3-046f-45c5-af0c-ffb2f77d73f1@192.168.1.64"
> - ovn-chassis-id="baa0199e-d1a4-484c-af13-a41bcad19dbc@192.168.1.90"
>
> From your 'ovs-vsctl show' I can see the IP encaps 192.168.1.41 and
> 192.168.1.64 are 'expected'.
>
> I would expect to see a duplicate chassis entry in the same IP . Who
> has this 192.168.1.90 IP ?
>
> A couple of further questions:
>- did you upgrade recently your environment ? If so, from which
> version to which version ?
> - what is the switch type of the cluster where you are running OVN ?
- what is the output of "ovn-sbctl list chassis" and "ovn-sbctl list
encap" on your engine node ?
>
> >
> >>
> >> [root@ovirt1 ~]# ovs-vsctl show
> >> c0e938f1-b5b5-4d5a-9cda-29dae2986f29
> >> Bridge br-int
> >> fail_mode: secure
> >> Port "ovn-25cc77-0"
> >> Interface "ovn-25cc77-0"
> >> type: geneve
> >> options: {csum="true", key=flow, remote_ip="192.168.1.64"}
> >> Port "ovn-566849-0"
> >> Interface "ovn-566849-0"
> >> type: geneve
> >> options: {csum="true", key=flow, remote_ip="192.168.1.41"}
> >> Port br-int
> >> Interface br-int
> >> type: internal
> >> Port "vnet2"
> >> Interface "vnet2"
> >> ovs_version: "2.11.0"
> >> [root@ovirt1 ~]# ovs-vsctl list ports
> >> ovs-vsctl: unknown table "ports"
> >> [root@ovirt1 ~]# ovs-vsctl list port
> >> _uuid : fbf40569-925e-4430-a7c5-c78d58979bbc
> >> bond_active_slave : []
> >> bond_downdelay : 0
> >> bond_fake_iface : false
> >> bond_mode : []
> >> bond_updelay: 0
> >> cvlans : []
> >> external_ids: {}
> >> fake_bridge : false
> >> interfaces : [3207c0cb-3000-40f2-a850-83548f76f090]lacp
> >> : []
> >> mac : []
> >> name: "vnet2"
> >> other_config: {}
> >> protected : false
> >> qos : []
> >> rstp_statistics : {}
> >> rstp_status : {}
> >> statistics : {}
> >> status : {}
> >> tag : []
> >> trunks : []
> >> vlan_mode : []
> >>
> >> _uuid : 8947f82d-a089-429b-8843-71371314cb52
> >> bond_active_slave : []
> >> bond_downdelay : 0
> >> bond_fake_iface : false
> >> bond_mode : []
> >> bond_updelay: 0
> >> cvlans : []
> >> external_ids: {}
> >> fake_bridge : false
> >> interfaces : [ec6a6688-e5d6-4346-ac47-ece1b8379440]lacp
> >> : []
> >> mac : []
> >> name: br-int
> >> other_config: {}
> >> protected : false
> >> qos : []
> >> rstp_statistics : {}
> >> rstp_status : {}
> >> statistics : {}
> >> status : {}
> >> tag : []
> >> trunks : []
> >> vlan_mode : []
> >>
> >> _uuid : 72d612be-853e-43e9-8f5c-ce66cef0bebe
> >> bond_active_slave : []
> >> bond_downdelay : 0
> >> bond_fake_iface : false
> >> bond_mode : []
> >> bond_updelay: 0
> >> cvlans : []
> >> external_ids:
> >> {ovn-chassis-id="5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3@192.168.1.41"}
> >> fake_bridge : false
> >>
[ovirt-users] Re: Ovirt OVN help needed
On Tue, Dec 17, 2019 at 9:17 AM Dominik Holler wrote:
>
>
>
> On Tue, Dec 17, 2019 at 6:28 AM Strahil wrote:
>>
>> Hi Dominik,
>>
>> Thanks for your reply.
>>
>> On ovirt1 I got the following:
>> [root@ovirt1 openvswitch]# less ovn-controller.log-20191216.gz
>> 2019-12-15T01:49:02.988Z|00032|vlog|INFO|opened log file
>> /var/log/openvswitch/ovn-controller.log
>> 2019-12-16T01:18:02.114Z|00033|vlog|INFO|closing log file
>> ovn-controller.log-20191216.gz (END)
>>
>> Same is on the other node:
>>
>> [root@ovirt2 openvswitch]# less ovn-controller.log-20191216.gz
>> 2019-12-15T01:26:03.477Z|00028|vlog|INFO|opened log file
>> /var/log/openvswitch/ovn-controller.log
>> 2019-12-16T01:30:01.718Z|00029|vlog|INFO|closing log file
>> ovn-controller.log-20191216.gz (END)
>>
>> The strange thing is that the geneve tunnels are there:
>
>
>
> Miguel, do you know how to remove and re-add the chassis to the southbound db?
> (We have to check this to address bug https://bugzilla.redhat.com/1758289 )
"ovn-sbctl chassis-del CHASSIS" will get rid of the chassis / encap.
Afterwards, the ovn-controller will re-register itself on OVN southbound.
There's something weird about your chassis, I see you have listed 3
different chassis IDs on your port IDs:
- ovn-chassis-id="5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3@192.168.1.41"
- ovn-chassis-id="25cc77b3-046f-45c5-af0c-ffb2f77d73f1@192.168.1.64"
- ovn-chassis-id="baa0199e-d1a4-484c-af13-a41bcad19dbc@192.168.1.90"
From your 'ovs-vsctl show' I can see the IP encaps 192.168.1.41 and
192.168.1.64 are 'expected'.
I would expect to see a duplicate chassis entry in the same IP . Who
has this 192.168.1.90 IP ?
A couple of further questions:
- did you upgrade recently your environment ? If so, from which
version to which version ?
- what is the switch type of the cluster where you are running OVN ?
>
>>
>> [root@ovirt1 ~]# ovs-vsctl show
>> c0e938f1-b5b5-4d5a-9cda-29dae2986f29
>> Bridge br-int
>> fail_mode: secure
>> Port "ovn-25cc77-0"
>> Interface "ovn-25cc77-0"
>> type: geneve
>> options: {csum="true", key=flow, remote_ip="192.168.1.64"}
>>Port "ovn-566849-0"
>> Interface "ovn-566849-0"
>> type: geneve
>> options: {csum="true", key=flow, remote_ip="192.168.1.41"}
>>Port br-int
>> Interface br-int
>> type: internal
>> Port "vnet2"
>> Interface "vnet2"
>> ovs_version: "2.11.0"
>> [root@ovirt1 ~]# ovs-vsctl list ports
>> ovs-vsctl: unknown table "ports"
>> [root@ovirt1 ~]# ovs-vsctl list port
>> _uuid : fbf40569-925e-4430-a7c5-c78d58979bbc
>> bond_active_slave : []
>> bond_downdelay : 0
>> bond_fake_iface : false
>> bond_mode : []
>> bond_updelay: 0
>> cvlans : []
>> external_ids: {}
>> fake_bridge : false
>> interfaces : [3207c0cb-3000-40f2-a850-83548f76f090]lacp
>>: []
>> mac : []
>> name: "vnet2"
>> other_config: {}
>> protected : false
>> qos : []
>> rstp_statistics : {}
>> rstp_status : {}
>> statistics : {}
>> status : {}
>> tag : []
>> trunks : []
>> vlan_mode : []
>>
>> _uuid : 8947f82d-a089-429b-8843-71371314cb52
>> bond_active_slave : []
>> bond_downdelay : 0
>> bond_fake_iface : false
>> bond_mode : []
>> bond_updelay: 0
>> cvlans : []
>> external_ids: {}
>> fake_bridge : false
>> interfaces : [ec6a6688-e5d6-4346-ac47-ece1b8379440]lacp
>>: []
>> mac : []
>> name: br-int
>> other_config: {}
>> protected : false
>> qos : []
>> rstp_statistics : {}
>> rstp_status : {}
>> statistics : {}
>> status : {}
>> tag : []
>> trunks : []
>> vlan_mode : []
>>
>> _uuid : 72d612be-853e-43e9-8f5c-ce66cef0bebe
>> bond_active_slave : []
>> bond_downdelay : 0
>> bond_fake_iface : false
>> bond_mode : []
>> bond_updelay: 0
>> cvlans : []
>> external_ids:
>> {ovn-chassis-id="5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3@192.168.1.41"}
>> fake_bridge : false
>> interfaces : [a31574fe-515b-420b-859d-7f2ac729638f]lacp
>>: []
>> mac : []
>> name: "ovn-566849-0"
>> other_config: {}
>> protected : false
>> qos : []
>> rstp_statistics : {}
>> rstp_status : {}
>> statistics : {}
>> status : {}
>> tag : []
>> trunks : []
>> vlan_mode : []
[ovirt-users] Re: Ovirt OVN help needed
On Tue, Dec 17, 2019 at 6:28 AM Strahil wrote:
> Hi Dominik,
>
> Thanks for your reply.
>
> On ovirt1 I got the following:
> [root@ovirt1 openvswitch]# less ovn-controller.log-20191216.gz
> 2019-12-15T01:49:02.988Z|00032|vlog|INFO|opened log file
> /var/log/openvswitch/ovn-controller.log
> 2019-12-16T01:18:02.114Z|00033|vlog|INFO|closing log file
> ovn-controller.log-20191216.gz (END)
>
> Same is on the other node:
>
> [root@ovirt2 openvswitch]# less ovn-controller.log-20191216.gz
> 2019-12-15T01:26:03.477Z|00028|vlog|INFO|opened log file
> /var/log/openvswitch/ovn-controller.log
> 2019-12-16T01:30:01.718Z|00029|vlog|INFO|closing log file
> ovn-controller.log-20191216.gz (END)
>
> The strange thing is that the geneve tunnels are there:
>
Miguel, do you know how to remove and re-add the chassis to the southbound
db?
(We have to check this to address bug https://bugzilla.redhat.com/1758289 )
> [root@ovirt1 ~]# ovs-vsctl show
> c0e938f1-b5b5-4d5a-9cda-29dae2986f29
> Bridge br-int
> fail_mode: secure
> Port "ovn-25cc77-0"
> Interface "ovn-25cc77-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="192.168.1.64"}
> Port "ovn-566849-0"
> Interface "ovn-566849-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="192.168.1.41"}
> Port br-int
> Interface br-int
> type: internal
> Port "vnet2"
> Interface "vnet2"
> ovs_version: "2.11.0"
> [root@ovirt1 ~]# ovs-vsctl list ports
> ovs-vsctl: unknown table "ports"
> [root@ovirt1 ~]# ovs-vsctl list port
> _uuid : fbf40569-925e-4430-a7c5-c78d58979bbc
> bond_active_slave : []
> bond_downdelay : 0
> bond_fake_iface : false
> bond_mode : []
> bond_updelay: 0
> cvlans : []
> external_ids: {}
> fake_bridge : false
> interfaces :
> [3207c0cb-3000-40f2-a850-83548f76f090]lacp: []
> mac : []
> name: "vnet2"
> other_config: {}
> protected : false
> qos : []
> rstp_statistics : {}
> rstp_status : {}
> statistics : {}
> status : {}
> tag : []
> trunks : []
> vlan_mode : []
>
> _uuid : 8947f82d-a089-429b-8843-71371314cb52
> bond_active_slave : []
> bond_downdelay : 0
> bond_fake_iface : false
> bond_mode : []
> bond_updelay: 0
> cvlans : []
> external_ids: {}
> fake_bridge : false
> interfaces :
> [ec6a6688-e5d6-4346-ac47-ece1b8379440]lacp: []
> mac : []
> name: br-int
> other_config: {}
> protected : false
> qos : []
> rstp_statistics : {}
> rstp_status : {}
> statistics : {}
> status : {}
> tag : []
> trunks : []
> vlan_mode : []
>
> _uuid : 72d612be-853e-43e9-8f5c-ce66cef0bebe
> bond_active_slave : []
> bond_downdelay : 0
> bond_fake_iface : false
> bond_mode : []
> bond_updelay: 0
> cvlans : []
> external_ids: {ovn-chassis-id="
> 5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3@192.168.1.41"}
> fake_bridge : false
> interfaces :
> [a31574fe-515b-420b-859d-7f2ac729638f]lacp: []
> mac : []
> name: "ovn-566849-0"
> other_config: {}
> protected : false
> qos : []
> rstp_statistics : {}
> rstp_status : {}
> statistics : {}
> status : {}
> tag : []
> trunks : []
> vlan_mode : []
>
> _uuid : 2043a15f-ec39-4cc3-b875-7be00423dd7a
> bond_active_slave : []
> bond_downdelay : 0
> bond_fake_iface : false
> bond_mode : []
> bond_updelay: 0
> cvlans : []
> external_ids: {ovn-chassis-id="
> 25cc77b3-046f-45c5-af0c-ffb2f77d73f1@192.168.1.64"}
> fake_bridge : false
> interfaces :
> [f9a9e3ff-070e-4044-b601-7f7394dc295f]lacp: []
> mac : []
> name: "ovn-25cc77-0"
> other_config: {}
> protected : false
> qos : []
> rstp_statistics : {}
> rstp_status : {}
> statistics : {}
> status : {}
> tag : []
> trunks : []
> vlan_mode : []
> [root@ovirt1 ~]#
>
> [root@ovirt2 ~]# ovs-vsctl show
> 3dbab138-6b90-44c5-af05-b8a944c9bf20
> Bridge br-int
> fail_mode: secure
> Port "ovn-baa019-0"
> Interface "ovn-baa019-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="192.168.1.90"}
> Port br-int
> Interface br-int
>
[ovirt-users] Re: Ovirt OVN help needed
Hi Dominik,
Thanks for your reply.
On ovirt1 I got the following:
[root@ovirt1 openvswitch]# less ovn-controller.log-20191216.gz
2019-12-15T01:49:02.988Z|00032|vlog|INFO|opened log file
/var/log/openvswitch/ovn-controller.log
2019-12-16T01:18:02.114Z|00033|vlog|INFO|closing log file
ovn-controller.log-20191216.gz (END)
Same is on the other node:
[root@ovirt2 openvswitch]# less ovn-controller.log-20191216.gz
2019-12-15T01:26:03.477Z|00028|vlog|INFO|opened log file
/var/log/openvswitch/ovn-controller.log
2019-12-16T01:30:01.718Z|00029|vlog|INFO|closing log file
ovn-controller.log-20191216.gz (END)
The strange thing is that the geneve tunnels are there:
[root@ovirt1 ~]# ovs-vsctl show
c0e938f1-b5b5-4d5a-9cda-29dae2986f29
Bridge br-int
fail_mode: secure
Port "ovn-25cc77-0"
Interface "ovn-25cc77-0"
type: geneve
options: {csum="true", key=flow, remote_ip="192.168.1.64"}
Port "ovn-566849-0"
Interface "ovn-566849-0"
type: geneve
options: {csum="true", key=flow, remote_ip="192.168.1.41"}
Port br-int
Interface br-int
type: internal
Port "vnet2"
Interface "vnet2"
ovs_version: "2.11.0"
[root@ovirt1 ~]# ovs-vsctl list ports
ovs-vsctl: unknown table "ports"
[root@ovirt1 ~]# ovs-vsctl list port
_uuid : fbf40569-925e-4430-a7c5-c78d58979bbc
bond_active_slave : []
bond_downdelay : 0
bond_fake_iface : false
bond_mode : []
bond_updelay: 0
cvlans : []
external_ids: {}
fake_bridge : false
interfaces : [3207c0cb-3000-40f2-a850-83548f76f090]lacp
: []
mac : []
name: "vnet2"
other_config: {}
protected : false
qos : []
rstp_statistics : {}
rstp_status : {}
statistics : {}
status : {}
tag : []
trunks : []
vlan_mode : []
_uuid : 8947f82d-a089-429b-8843-71371314cb52
bond_active_slave : []
bond_downdelay : 0
bond_fake_iface : false
bond_mode : []
bond_updelay: 0
cvlans : []
external_ids: {}
fake_bridge : false
interfaces : [ec6a6688-e5d6-4346-ac47-ece1b8379440]lacp
: []
mac : []
name: br-int
other_config: {}
protected : false
qos : []
rstp_statistics : {}
rstp_status : {}
statistics : {}
status : {}
tag : []
trunks : []
vlan_mode : []
_uuid : 72d612be-853e-43e9-8f5c-ce66cef0bebe
bond_active_slave : []
bond_downdelay : 0
bond_fake_iface : false
bond_mode : []
bond_updelay: 0
cvlans : []
external_ids:
{ovn-chassis-id="5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3@192.168.1.41"}
fake_bridge : false
interfaces : [a31574fe-515b-420b-859d-7f2ac729638f]lacp
: []
mac : []
name: "ovn-566849-0"
other_config: {}
protected : false
qos : []
rstp_statistics : {}
rstp_status : {}
statistics : {}
status : {}
tag : []
trunks : []
vlan_mode : []
_uuid : 2043a15f-ec39-4cc3-b875-7be00423dd7a
bond_active_slave : []
bond_downdelay : 0
bond_fake_iface : false
bond_mode : []
bond_updelay: 0
cvlans : []
external_ids:
{ovn-chassis-id="25cc77b3-046f-45c5-af0c-ffb2f77d73f1@192.168.1.64"}
fake_bridge : false
interfaces : [f9a9e3ff-070e-4044-b601-7f7394dc295f]lacp
: []
mac : []
name: "ovn-25cc77-0"
other_config: {}
protected : false
qos : []
rstp_statistics : {}
rstp_status : {}
statistics : {}
status : {}
tag : []
trunks : []
vlan_mode : []
[root@ovirt1 ~]#
[root@ovirt2 ~]# ovs-vsctl show
3dbab138-6b90-44c5-af05-b8a944c9bf20
Bridge br-int
fail_mode: secure
Port "ovn-baa019-0"
Interface "ovn-baa019-0"
type: geneve
options: {csum="true", key=flow, remote_ip="192.168.1.90"}
Port br-int
Interface br-int
type: internal
Port "vnet5"
Interface "vnet5"
Port "ovn-566849-0"
Interface "ovn-566849-0"
type: geneve
options: {csum="true", key=flow, remote_ip="192.168.1.41"}
ovs_version: "2.11.0"
[root@ovirt2 ~]# ovs-vsctl list port
_uuid :
[ovirt-users] Re: Ovirt OVN help needed
On Sat, Dec 14, 2019 at 11:36 AM Strahil Nikolov
wrote:
> Hi Dominik,
>
> yes I was looking for those settings.
>
> I have added again the external provider , but I guess the mess is even
> bigger as I made some stupid decisions (like removing 2 port groups :)
> without knowing what I'm doing) .
> Sadly I can't remove all packages on the engine and hosts and reinstall
> them from scratch.
>
> Pip fails to install the openstacksdk (centOS7 is not great for such
> tasks) on the engine and my lack of knowledge in OVN makes it even more
> difficult.
>
> So the symptoms are that 2 machines can communicate with each other only
> if they are on the same host ,while on separate - no communications is
> happening.
>
>
This indicates that the tunnels between the hosts are not created.
Can you please check the /var/log/openvswitch/ovn-controller.log on both
hosts for errors and warnings, or share parts of the files here?
If this does not point us to a problem, ovn has to be reconfigured. If
possible, most easy way to do this would be to ensure that
ovirt-provider-ovn is the default network provider of the cluster of the
hosts, put one host after another in maintance mode and reinstall.
> How I created the network via UI:
>
> 1. Networks - new
> 2. Fill in the name
> 3. Create on external provider
> 4. Network Port security -> disabled (even undefined does not work)
> 5.Connect to physical network -> ovirtmgmt
>
>
> I would be happy to learn more about OVN and thus I would like to make it
> work.
>
> Here is some info from the engine:
>
> [root@engine ~]# ovn-nbctl show
> switch 1288ed26-471c-4bc2-8a7d-4531f306f44c
> (ovirt-pxelan-2a88b2e0-d04b-4196-ad50-074501e4ed08)
> port c1eba112-5eed-4c04-b25c-d3dcfb934546
> addresses: ["56:6f:5a:65:00:06"]
> port 8b52ab60-f474-4d51-b258-cb2e0a53c34a
> type: localnet
> addresses: ["unknown"]
> port b2753040-881b-487a-92a1-9721da749be4
> addresses: ["56:6f:5a:65:00:09"]
> [root@engine ~]# ovn-sbctl show
> Chassis "5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3"
> hostname: "ovirt3.localdomain"
> Encap geneve
> ip: "192.168.1.41"
> options: {csum="true"}
> Chassis "baa0199e-d1a4-484c-af13-a41bcad19dbc"
> hostname: "ovirt1.localdomain"
> Encap geneve
> ip: "192.168.1.90"
> options: {csum="true"}
> Chassis "25cc77b3-046f-45c5-af0c-ffb2f77d73f1"
> hostname: "ovirt2.localdomain"
> Encap geneve
> ip: "192.168.1.64"
> options: {csum="true"}
> Port_Binding "b2753040-881b-487a-92a1-9721da749be4"
> Port_Binding "c1eba112-5eed-4c04-b25c-d3dcfb934546"
>
>
> Is it possible to remove the vNICs , Virtual Network + and recreate the
> ovn db to start over ?
>
@Miguel Duarte de Mora Barroso Is there a hardcore
way bypassing ovirt-provider-ovn to do this?
> I guess the other option is to create a VM that can be used to install
> python openstacksdk and modify via the python script from your previous
> e-mail.
>
>
Yes, a fedora VM in oVirt works great and creating a template from the
images from ovirt-image-repository is comfortable.
>
> Best Regards,
> Strahil Nikolov
>
>
> В петък, 13 декември 2019 г., 10:11:51 ч. Гринуич+2, Dominik Holler <
> dhol...@redhat.com> написа:
>
>
>
>
> On Fri, Dec 13, 2019 at 5:51 AM Strahil wrote:
>
> Hi Dominik, All,
>
> I've checked '
> https://lists.ovirt.org/archives/list/users@ovirt.org/thread/W6U4XJHNMYMD3WIXDCPGOXLW6DFMCYIM/'
> and the user managed to clear up and start over.
>
> I have removed the ovn-external-provider from UI, but I forgot to copy
> the data from the fields.
>
> Do you know any refference guide (or any tips & tricks) for adding OVN ?
>
>
> The ovirt-provider-ovn entity can be added to oVirt Engine as a new
> provider with
> Type: External Network Provider
> Network Plugin: oVirt Network Provider for OVN
> Provider URL: https://YOUR_ENGINE_FQDNt:9696
> Username: admin@internal
> Password: admin@interal password
> Host Name: YOUR_ENGINE_FQDN
> API Port: 35357
> API Version: v2.0
>
> Is this the information you need?
>
>
> Thanks in advance.
>
> Best Regards,
> Strahil Nikolov
> On Dec 12, 2019 20:49, Strahil wrote:
>
> Hi Dominik,
>
> Thanks for the reply.
>
> Sadly the openstack module is missing on the engine and I have to figure
> it out.
>
> Can't I just undeploy the ovn and then redeploy it back ?
>
> Best Regards,
> Strahil Nikolov
> On Dec 12, 2019 09:32, Dominik Holler wrote:
>
> The cleanest way to clean up is to remove all entities on the OpenStack
> Network API on ovirt-provider-ovn, e.g. by something like
>
> https://gist.github.com/dominikholler/19bcdc5f14f42ab5f069086fd2ff5e37#file-list_security_groups-py-L25
> This should work, if not, please report a bug.
>
> To bypass the ovirt-provider-ovn, which is not recommended and might end
> in an inconsistent state, you could use ovn-nbctl .
>
>
>
> On Thu, Dec 12, 2019 at 3:33 AM Strahil Nikolov
> wrote:
>
> Hi Community,
>
> can someone hint me how to get
[ovirt-users] Re: Ovirt OVN help needed
Hi Dominik,
yes I was looking for those settings.
I have added again the external provider , but I guess the mess is even bigger
as I made some stupid decisions (like removing 2 port groups :) without knowing
what I'm doing) .Sadly I can't remove all packages on the engine and hosts and
reinstall them from scratch.
Pip fails to install the openstacksdk (centOS7 is not great for such tasks) on
the engine and my lack of knowledge in OVN makes it even more difficult.
So the symptoms are that 2 machines can communicate with each other only if
they are on the same host ,while on separate - no communications is happening.
How I created the network via UI:
1. Networks - new 2. Fill in the name3. Create on external provider4. Network
Port security -> disabled (even undefined does not work)5.Connect to physical
network -> ovirtmgmt
I would be happy to learn more about OVN and thus I would like to make it work.
Here is some info from the engine:
[root@engine ~]# ovn-nbctl showswitch 1288ed26-471c-4bc2-8a7d-4531f306f44c
(ovirt-pxelan-2a88b2e0-d04b-4196-ad50-074501e4ed08) port
c1eba112-5eed-4c04-b25c-d3dcfb934546 addresses: ["56:6f:5a:65:00:06"]
port 8b52ab60-f474-4d51-b258-cb2e0a53c34a type: localnet
addresses: ["unknown"] port b2753040-881b-487a-92a1-9721da749be4
addresses: ["56:6f:5a:65:00:09"][root@engine ~]# ovn-sbctl showChassis
"5668499c-7dd0-41ee-bc5d-2e6ee9cd61c3" hostname: "ovirt3.localdomain"
Encap geneve ip: "192.168.1.41" options: {csum="true"}Chassis
"baa0199e-d1a4-484c-af13-a41bcad19dbc" hostname: "ovirt1.localdomain"
Encap geneve ip: "192.168.1.90" options: {csum="true"}Chassis
"25cc77b3-046f-45c5-af0c-ffb2f77d73f1" hostname: "ovirt2.localdomain"
Encap geneve ip: "192.168.1.64" options: {csum="true"}
Port_Binding "b2753040-881b-487a-92a1-9721da749be4" Port_Binding
"c1eba112-5eed-4c04-b25c-d3dcfb934546"
Is it possible to remove the vNICs , Virtual Network + and recreate the ovn db
to start over ?I guess the other option is to create a VM that can be used to
install python openstacksdk and modify via the python script from your previous
e-mail.
Best Regards,Strahil Nikolov
В петък, 13 декември 2019 г., 10:11:51 ч. Гринуич+2, Dominik Holler
написа:
On Fri, Dec 13, 2019 at 5:51 AM Strahil wrote:
Hi Dominik, All,
I've checked
'https://lists.ovirt.org/archives/list/users@ovirt.org/thread/W6U4XJHNMYMD3WIXDCPGOXLW6DFMCYIM/'
and the user managed to clear up and start over.
I have removed the ovn-external-provider from UI, but I forgot to copy the
data from the fields.
Do you know any refference guide (or any tips & tricks) for adding OVN ?
The ovirt-provider-ovn entity can be added to oVirt Engine as a new provider
withType: External Network ProviderNetwork Plugin: oVirt Network Provider for
OVNProvider URL: https://YOUR_ENGINE_FQDNt:9696
Username: admin@internalPassword: admin@interal passwordHost Name:
YOUR_ENGINE_FQDNAPI Port: 35357API Version: v2.0
Is this the information you need?
Thanks in advance.
Best Regards,
Strahil Nikolov
On Dec 12, 2019 20:49, Strahil wrote:
Hi Dominik,
Thanks for the reply.
Sadly the openstack module is missing on the engine and I have to figure it out.
Can't I just undeploy the ovn and then redeploy it back ?
Best Regards,
Strahil Nikolov
On Dec 12, 2019 09:32, Dominik Holler wrote:
The cleanest way to clean up is to remove all entities on the OpenStack Network
API on ovirt-provider-ovn, e.g. by something like
https://gist.github.com/dominikholler/19bcdc5f14f42ab5f069086fd2ff5e37#file-list_security_groups-py-L25
This should work, if not, please report a bug.
To bypass the ovirt-provider-ovn, which is not recommended and might end in an
inconsistent state, you could use ovn-nbctl .
On Thu, Dec 12, 2019 at 3:33 AM Strahil Nikolov wrote:
Hi Community,
can someone hint me how to get rid of some ports? I just want to 'reset' my ovn
setup.
Here is what I have so far:
[root@ovirt1 openvswitch]# ovs-vsctl list interface
_uuid : be89c214-10e4-4a97-a9eb-1b82bc433a24
admin_state : up
bfd : {}
bfd_status : {}
cfm_fault : []
cfm_fault_status : []
cfm_flap_count : []
cfm_health : []
cfm_mpid : []
cfm_remote_mpids : []
cfm_remote_opstate : []
duplex : []
error : []
external_ids : {}
ifindex : 35
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current : []
link_resets : 0
link_speed : []
link_state : up
lldp : {}
mac : []
mac_in_use : "7a:7d:1d:a7:43:1d"
mtu : []
mtu_request : []
name : "ovn-25cc77-0"
ofport : 6
ofport_request : []
options : {csum="true", key=flow, remote_ip="192.168.1.64"}
other_config : {}
[ovirt-users] Re: Ovirt OVN help needed
On Fri, Dec 13, 2019 at 5:51 AM Strahil wrote:
> Hi Dominik, All,
>
> I've checked '
> https://lists.ovirt.org/archives/list/users@ovirt.org/thread/W6U4XJHNMYMD3WIXDCPGOXLW6DFMCYIM/'
> and the user managed to clear up and start over.
>
> I have removed the ovn-external-provider from UI, but I forgot to copy
> the data from the fields.
>
> Do you know any refference guide (or any tips & tricks) for adding OVN ?
>
The ovirt-provider-ovn entity can be added to oVirt Engine as a new
provider with
Type: External Network Provider
Network Plugin: oVirt Network Provider for OVN
Provider URL: https://YOUR_ENGINE_FQDNt:9696
Username: admin@internal
Password: admin@interal password
Host Name: YOUR_ENGINE_FQDN
API Port: 35357
API Version: v2.0
Is this the information you need?
> Thanks in advance.
>
> Best Regards,
> Strahil Nikolov
> On Dec 12, 2019 20:49, Strahil wrote:
>
> Hi Dominik,
>
> Thanks for the reply.
>
> Sadly the openstack module is missing on the engine and I have to figure
> it out.
>
> Can't I just undeploy the ovn and then redeploy it back ?
>
> Best Regards,
> Strahil Nikolov
> On Dec 12, 2019 09:32, Dominik Holler wrote:
>
> The cleanest way to clean up is to remove all entities on the OpenStack
> Network API on ovirt-provider-ovn, e.g. by something like
>
> https://gist.github.com/dominikholler/19bcdc5f14f42ab5f069086fd2ff5e37#file-list_security_groups-py-L25
> This should work, if not, please report a bug.
>
> To bypass the ovirt-provider-ovn, which is not recommended and might end
> in an inconsistent state, you could use ovn-nbctl .
>
>
>
> On Thu, Dec 12, 2019 at 3:33 AM Strahil Nikolov
> wrote:
>
> Hi Community,
>
> can someone hint me how to get rid of some ports? I just want to 'reset'
> my ovn setup.
>
> Here is what I have so far:
>
> [root@ovirt1 openvswitch]# ovs-vsctl list interface
> _uuid : be89c214-10e4-4a97-a9eb-1b82bc433a24
> admin_state : up
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : []
> error : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : []
> link_state : up
> lldp: {}
> mac : []
> mac_in_use : "7a:7d:1d:a7:43:1d"
> mtu : []
> mtu_request : []
> name: "ovn-25cc77-0"
> ofport : 6
> ofport_request : []
> options : {csum="true", key=flow, remote_ip="192.168.1.64"}
> other_config: {}
> statistics : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
> status : {tunnel_egress_iface=ovirtmgmt,
> tunnel_egress_iface_carrier=up}
> type: geneve
>
> _uuid : ec6a6688-e5d6-4346-ac47-ece1b8379440
> admin_state : down
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : []
> error : []
> external_ids: {}
> ifindex : 13
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : []
> link_state : down
> lldp: {}
> mac : []
> mac_in_use : "66:36:dd:63:dc:48"
> mtu : 1500
> mtu_request : []
> name: br-int
> ofport : 65534
> ofport_request : []
> options : {}
> other_config: {}
> statistics : {collisions=0, rx_bytes=0, rx_crc_err=0,
> rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
> tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
> status : {driver_name=openvswitch}
> type: internal
>
> _uuid : 1e511b4d-f7c2-499f-bd8c-07236e7bb7af
> admin_state : up
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : []
> error : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : []
> link_state : up
> lldp: {}
> mac : []
> mac_in_use : "1a:85:d1:d9:e2:a5"
> mtu : []
> mtu_request : []
> name: "ovn-566849-0"
> ofport : 5
>
[ovirt-users] Re: Ovirt OVN help needed
On Thu, Dec 12, 2019 at 7:50 PM Strahil wrote:
> Hi Dominik,
>
> Thanks for the reply.
>
> Sadly the openstack module is missing on the engine and I have to figure
> it out.
>
The module can be installed by 'pip install openstacksdk', please find an
example in
https://github.com/oVirt/ovirt-system-tests/blob/master/network-suite-master/control.sh#L20
> Can't I just undeploy the ovn and then redeploy it back ?
>
No idea, I never tried this.
In doubt, you can deleter one entity after another via ovn-nbctl.
> Best Regards,
> Strahil Nikolov
> On Dec 12, 2019 09:32, Dominik Holler wrote:
>
> The cleanest way to clean up is to remove all entities on the OpenStack
> Network API on ovirt-provider-ovn, e.g. by something like
>
> https://gist.github.com/dominikholler/19bcdc5f14f42ab5f069086fd2ff5e37#file-list_security_groups-py-L25
> This should work, if not, please report a bug.
>
> To bypass the ovirt-provider-ovn, which is not recommended and might end
> in an inconsistent state, you could use ovn-nbctl .
>
>
>
> On Thu, Dec 12, 2019 at 3:33 AM Strahil Nikolov
> wrote:
>
> Hi Community,
>
> can someone hint me how to get rid of some ports? I just want to 'reset'
> my ovn setup.
>
> Here is what I have so far:
>
> [root@ovirt1 openvswitch]# ovs-vsctl list interface
> _uuid : be89c214-10e4-4a97-a9eb-1b82bc433a24
> admin_state : up
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : []
> error : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : []
> link_state : up
> lldp: {}
> mac : []
> mac_in_use : "7a:7d:1d:a7:43:1d"
> mtu : []
> mtu_request : []
> name: "ovn-25cc77-0"
> ofport : 6
> ofport_request : []
> options : {csum="true", key=flow, remote_ip="192.168.1.64"}
> other_config: {}
> statistics : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
> status : {tunnel_egress_iface=ovirtmgmt,
> tunnel_egress_iface_carrier=up}
> type: geneve
>
> _uuid : ec6a6688-e5d6-4346-ac47-ece1b8379440
> admin_state : down
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : []
> error : []
> external_ids: {}
> ifindex : 13
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : []
> link_state : down
> lldp: {}
> mac : []
> mac_in_use : "66:36:dd:63:dc:48"
> mtu : 1500
> mtu_request : []
> name: br-int
> ofport : 65534
> ofport_request : []
> options : {}
> other_config: {}
> statistics : {collisions=0, rx_bytes=0, rx_crc_err=0,
> rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
> tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
> status : {driver_name=openvswitch}
> type: internal
>
> _uuid : 1e511b4d-f7c2-499f-bd8c-07236e7bb7af
> admin_state : up
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : []
> error : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : []
> link_state : up
> lldp: {}
> mac : []
> mac_in_use : "1a:85:d1:d9:e2:a5"
> mtu : []
> mtu_request : []
> name: "ovn-566849-0"
> ofport : 5
> ofport_request : []
> options : {csum="true", key=flow, remote_ip="192.168.1.41"}
> other_config: {}
> statistics : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
> status : {tunnel_egress_iface=ovirtmgmt,
> tunnel_egress_iface_carrier=up}
> type: geneve
>
>
> When I try to remove a port - it never ends (just hanging):
>
> [root@ovirt1 openvswitch]# ovs-vsctl --dry-run del-port br-int
> ovn-25cc77-0
> In journal I see only this:
> дек 12 04:13:57 ovirt1.localdomain ovs-vsctl[22030]:
>
[ovirt-users] Re: Ovirt OVN help needed
Hi Dominik, All,
I've checked
'https://lists.ovirt.org/archives/list/users@ovirt.org/thread/W6U4XJHNMYMD3WIXDCPGOXLW6DFMCYIM/'
and the user managed to clear up and start over.
I have removed the ovn-external-provider from UI, but I forgot to copy the
data from the fields.
Do you know any refference guide (or any tips & tricks) for adding OVN ?
Thanks in advance.
Best Regards,
Strahil NikolovOn Dec 12, 2019 20:49, Strahil wrote:
>
> Hi Dominik,
>
> Thanks for the reply.
>
> Sadly the openstack module is missing on the engine and I have to figure it
> out.
>
> Can't I just undeploy the ovn and then redeploy it back ?
>
> Best Regards,
> Strahil Nikolov
>
> On Dec 12, 2019 09:32, Dominik Holler wrote:
>>
>> The cleanest way to clean up is to remove all entities on the OpenStack
>> Network API on ovirt-provider-ovn, e.g. by something like
>> https://gist.github.com/dominikholler/19bcdc5f14f42ab5f069086fd2ff5e37#file-list_security_groups-py-L25
>> This should work, if not, please report a bug.
>>
>> To bypass the ovirt-provider-ovn, which is not recommended and might end in
>> an inconsistent state, you could use ovn-nbctl .
>>
>>
>>
>> On Thu, Dec 12, 2019 at 3:33 AM Strahil Nikolov
>> wrote:
>>>
>>> Hi Community,
>>>
>>> can someone hint me how to get rid of some ports? I just want to 'reset' my
>>> ovn setup.
>>>
>>> Here is what I have so far:
>>>
>>> [root@ovirt1 openvswitch]# ovs-vsctl list interface
>>> _uuid : be89c214-10e4-4a97-a9eb-1b82bc433a24
>>> admin_state : up
>>> bfd : {}
>>> bfd_status : {}
>>> cfm_fault : []
>>> cfm_fault_status : []
>>> cfm_flap_count : []
>>> cfm_health : []
>>> cfm_mpid : []
>>> cfm_remote_mpids : []
>>> cfm_remote_opstate : []
>>> duplex : []
>>> error : []
>>> external_ids : {}
>>> ifindex : 35
>>> ingress_policing_burst: 0
>>> ingress_policing_rate: 0
>>> lacp_current : []
>>> link_resets : 0
>>> link_speed : []
>>> link_state : up
>>> lldp : {}
>>> mac : []
>>> mac_in_use : "7a:7d:1d:a7:43:1d"
>>> mtu : []
>>> mtu_request : []
>>> name : "ovn-25cc77-0"
>>> ofport : 6
>>> ofport_request : []
>>> options : {csum="true", key=flow, remote_ip="192.168.1.64"}
>>> other_config : {}
>>> statistics : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
>>> status : {tunnel_egress_iface=ovirtmgmt,
>>> tunnel_egress_iface_carrier=up}
>>> type : geneve
>>>
>>> _uuid : ec6a6688-e5d6-4346-ac47-ece1b8379440
>>> admin_state : down
>>> bfd : {}
>>> bfd_status : {}
>>> cfm_fault : []
>>> cfm_fault_status : []
>>> cfm_flap_count : []
>>> cfm_health : []
>>> cfm_mpid : []
>>> cfm_remote_mpids : []
>>> cfm_remote_opstate : []
>>> duplex : []
>>> error : []
>>> external_ids : {}
>>> ifindex : 13
>>> ingress_policing_burst: 0
>>> ingress_policing_rate: 0
>>> lacp_current : []
>>> link_resets : 0
>>> link_speed : []
>>> link_state : down
>>> lldp : {}
>>> mac : []
>>> mac_in_use : "66:36:dd:63:dc:48"
>>> mtu : 1500
>>> mtu_request : []
>>> name : br-int
>>> ofport : 65534
>>> ofport_request : []
>>> options : {}
>>> other_config : {}
>>> statistics : {collisions=0, rx_bytes=0, rx_crc_err=0,
>>> rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
>>> tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
>>> status : {driver_name=openvswitch}
>>> type : internal
>>>
>>> _uuid : 1e511b4d-f7c2-499f-bd8c-07236e7bb7af
>>> admin_state : up
>>> bfd : {}
>>> bfd_status : {}
>>> cfm_fault : []
>>> cfm_fault_status : []
>>> cfm_flap_count : []
>>> cfm_health : []
>>> cfm_mpid : []
>>> cfm_remote_mpids : []
>>> cfm_remote_opstate : []
>>> duplex : []
>>> error : []
>>> external_ids : {}
>>> ifindex : 35
>>> ingress_policing_burst: 0
>>> ingress_policing_rate: 0
>>> lacp_current : []
>>> link_resets : 0
>>> link_speed : []
>>> link_state : up
>>> lldp : {}
>>> mac : []
>>> mac_in_use : "1a:85:d1:d9:e2:a5"
>>> mtu : []
>>> mtu_request : []
>>> name : "ovn-566849-0"
>>> ofport : 5
>>> ofport_request : []
>>> options : {csum="true", key=flow,
[ovirt-users] Re: Ovirt OVN help needed
Hi Dominik,
Thanks for the reply.
Sadly the openstack module is missing on the engine and I have to figure it out.
Can't I just undeploy the ovn and then redeploy it back ?
Best Regards,
Strahil NikolovOn Dec 12, 2019 09:32, Dominik Holler wrote:
>
> The cleanest way to clean up is to remove all entities on the OpenStack
> Network API on ovirt-provider-ovn, e.g. by something like
> https://gist.github.com/dominikholler/19bcdc5f14f42ab5f069086fd2ff5e37#file-list_security_groups-py-L25
> This should work, if not, please report a bug.
>
> To bypass the ovirt-provider-ovn, which is not recommended and might end in
> an inconsistent state, you could use ovn-nbctl .
>
>
>
> On Thu, Dec 12, 2019 at 3:33 AM Strahil Nikolov wrote:
>>
>> Hi Community,
>>
>> can someone hint me how to get rid of some ports? I just want to 'reset' my
>> ovn setup.
>>
>> Here is what I have so far:
>>
>> [root@ovirt1 openvswitch]# ovs-vsctl list interface
>> _uuid : be89c214-10e4-4a97-a9eb-1b82bc433a24
>> admin_state : up
>> bfd : {}
>> bfd_status : {}
>> cfm_fault : []
>> cfm_fault_status : []
>> cfm_flap_count : []
>> cfm_health : []
>> cfm_mpid : []
>> cfm_remote_mpids : []
>> cfm_remote_opstate : []
>> duplex : []
>> error : []
>> external_ids : {}
>> ifindex : 35
>> ingress_policing_burst: 0
>> ingress_policing_rate: 0
>> lacp_current : []
>> link_resets : 0
>> link_speed : []
>> link_state : up
>> lldp : {}
>> mac : []
>> mac_in_use : "7a:7d:1d:a7:43:1d"
>> mtu : []
>> mtu_request : []
>> name : "ovn-25cc77-0"
>> ofport : 6
>> ofport_request : []
>> options : {csum="true", key=flow, remote_ip="192.168.1.64"}
>> other_config : {}
>> statistics : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
>> status : {tunnel_egress_iface=ovirtmgmt,
>> tunnel_egress_iface_carrier=up}
>> type : geneve
>>
>> _uuid : ec6a6688-e5d6-4346-ac47-ece1b8379440
>> admin_state : down
>> bfd : {}
>> bfd_status : {}
>> cfm_fault : []
>> cfm_fault_status : []
>> cfm_flap_count : []
>> cfm_health : []
>> cfm_mpid : []
>> cfm_remote_mpids : []
>> cfm_remote_opstate : []
>> duplex : []
>> error : []
>> external_ids : {}
>> ifindex : 13
>> ingress_policing_burst: 0
>> ingress_policing_rate: 0
>> lacp_current : []
>> link_resets : 0
>> link_speed : []
>> link_state : down
>> lldp : {}
>> mac : []
>> mac_in_use : "66:36:dd:63:dc:48"
>> mtu : 1500
>> mtu_request : []
>> name : br-int
>> ofport : 65534
>> ofport_request : []
>> options : {}
>> other_config : {}
>> statistics : {collisions=0, rx_bytes=0, rx_crc_err=0, rx_dropped=0,
>> rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0, tx_bytes=0,
>> tx_dropped=0, tx_errors=0, tx_packets=0}
>> status : {driver_name=openvswitch}
>> type : internal
>>
>> _uuid : 1e511b4d-f7c2-499f-bd8c-07236e7bb7af
>> admin_state : up
>> bfd : {}
>> bfd_status : {}
>> cfm_fault : []
>> cfm_fault_status : []
>> cfm_flap_count : []
>> cfm_health : []
>> cfm_mpid : []
>> cfm_remote_mpids : []
>> cfm_remote_opstate : []
>> duplex : []
>> error : []
>> external_ids : {}
>> ifindex : 35
>> ingress_policing_burst: 0
>> ingress_policing_rate: 0
>> lacp_current : []
>> link_resets : 0
>> link_speed : []
>> link_state : up
>> lldp : {}
>> mac : []
>> mac_in_use : "1a:85:d1:d9:e2:a5"
>> mtu : []
>> mtu_request : []
>> name : "ovn-566849-0"
>> ofport : 5
>> ofport_request : []
>> options : {csum="true", key=flow, remote_ip="192.168.1.41"}
>> other_config : {}
>> statistics : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
>> status : {tunnel_egress_iface=ovirtmgmt,
>> tunnel_egress_iface_carrier=up}
>> type : geneve
>>
>>
>> When I try to remove a port - it never ends (just hanging):
>>
>> [root@ovirt1 openvswitch]# ovs-vsctl --dry-run del-port br-int ovn-25cc77-0
>>
>> In journal I see only this:
>> дек 12 04:13:57 ovirt1.localdomain ovs-vsctl[22030]:
>> ovs|1|vsctl|INFO|Called as ovs-vsctl --dry-run del-port br-int
>>
[ovirt-users] Re: Ovirt OVN help needed
The cleanest way to clean up is to remove all entities on the OpenStack
Network API on ovirt-provider-ovn, e.g. by something like
https://gist.github.com/dominikholler/19bcdc5f14f42ab5f069086fd2ff5e37#file-list_security_groups-py-L25
This should work, if not, please report a bug.
To bypass the ovirt-provider-ovn, which is not recommended and might end in
an inconsistent state, you could use ovn-nbctl .
On Thu, Dec 12, 2019 at 3:33 AM Strahil Nikolov
wrote:
> Hi Community,
>
> can someone hint me how to get rid of some ports? I just want to 'reset'
> my ovn setup.
>
> Here is what I have so far:
>
> [root@ovirt1 openvswitch]# ovs-vsctl list interface
> _uuid : be89c214-10e4-4a97-a9eb-1b82bc433a24
> admin_state : up
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : []
> error : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : []
> link_state : up
> lldp: {}
> mac : []
> mac_in_use : "7a:7d:1d:a7:43:1d"
> mtu : []
> mtu_request : []
> name: "ovn-25cc77-0"
> ofport : 6
> ofport_request : []
> options : {csum="true", key=flow, remote_ip="192.168.1.64"}
> other_config: {}
> statistics : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
> status : {tunnel_egress_iface=ovirtmgmt,
> tunnel_egress_iface_carrier=up}
> type: geneve
>
> _uuid : ec6a6688-e5d6-4346-ac47-ece1b8379440
> admin_state : down
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : []
> error : []
> external_ids: {}
> ifindex : 13
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : []
> link_state : down
> lldp: {}
> mac : []
> mac_in_use : "66:36:dd:63:dc:48"
> mtu : 1500
> mtu_request : []
> name: br-int
> ofport : 65534
> ofport_request : []
> options : {}
> other_config: {}
> statistics : {collisions=0, rx_bytes=0, rx_crc_err=0,
> rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
> tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0}
> status : {driver_name=openvswitch}
> type: internal
>
> _uuid : 1e511b4d-f7c2-499f-bd8c-07236e7bb7af
> admin_state : up
> bfd : {}
> bfd_status : {}
> cfm_fault : []
> cfm_fault_status: []
> cfm_flap_count : []
> cfm_health : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate : []
> duplex : []
> error : []
> external_ids: {}
> ifindex : 35
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed : []
> link_state : up
> lldp: {}
> mac : []
> mac_in_use : "1a:85:d1:d9:e2:a5"
> mtu : []
> mtu_request : []
> name: "ovn-566849-0"
> ofport : 5
> ofport_request : []
> options : {csum="true", key=flow, remote_ip="192.168.1.41"}
> other_config: {}
> statistics : {rx_bytes=0, rx_packets=0, tx_bytes=0, tx_packets=0}
> status : {tunnel_egress_iface=ovirtmgmt,
> tunnel_egress_iface_carrier=up}
> type: geneve
>
>
> When I try to remove a port - it never ends (just hanging):
>
> [root@ovirt1 openvswitch]# ovs-vsctl --dry-run del-port br-int
> ovn-25cc77-0
> In journal I see only this:
> дек 12 04:13:57 ovirt1.localdomain ovs-vsctl[22030]:
> ovs|1|vsctl|INFO|Called as ovs-vsctl --dry-run del-port br-int
> ovn-25cc77-0
>
> The stranger part to me is the log output:
>
> [root@ovirt1 openvswitch]# grep ovn-25cc77-0 /var/log/openvswitch/*.log
> /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:26:28.642Z|00032|bridge|INFO|bridge
> br-int: added interface ovn-25cc77-0 on port 14
> /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:45:15.646Z|00113|bridge|INFO|bridge
> br-int: deleted interface ovn-25cc77-0 on port 14
> /var/log/openvswitch/ovs-vswitchd.log:2019-12-12T01:45:15.861Z|00116|bridge|INFO|bridge
> br-int: added interface ovn-25cc77-0 on port 2
>
