[ovirt-users] Re: Ovirt OVN help needed

2020-01-17 Thread Miguel Duarte de Mora Barroso
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"
>

[ovirt-users] Re: Ovirt OVN help needed

2020-01-10 Thread Miguel Duarte de Mora Barroso
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 set

[ovirt-users] Re: Ovirt OVN help needed

2019-12-18 Thread 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 t

[ovirt-users] Re: Ovirt OVN help needed

2019-12-17 Thread 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
> >> 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 

[ovirt-users] Re: Ovirt OVN help needed

2019-12-17 Thread Miguel Duarte de Mora Barroso
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: External networks issue after upgrading to 4.3.6

2019-10-09 Thread Miguel Duarte de Mora Barroso
On Wed, Oct 9, 2019 at 1:50 PM ada per  wrote:
>
> Done!! thank you. it worked now but the  ovn-sbctl list chassis finds nothing

Good.

Some other things:
  - what's the output of 'ip a' on ovirt-engine ?
  - ssh into one of the hosts in that cluster and do 'ovs-vsctl list Open'

With this we can check that the OVN configuration is correct.

>
> results fom playbook
>
> PLAY RECAP 
> 
> localhost  : ok=1changed=0unreachable=0failed=0   
>  skipped=2rescued=0ignored=0
> threatrealm2.sec.ouc.ac.cy : ok=6changed=1unreachable=0failed=0   
>  skipped=3rescued=0ignored=0
> threatrealm3.sec.ouc.ac.cy : ok=6changed=1unreachable=0failed=0   
>  skipped=3rescued=0ignored=0
>
>
>
> results form ovn-sbctl list chassis:
>
> net_mlx5: cannot load glue library: libibverbs.so.1: cannot open shared 
> object file: No such file or directory
> net_mlx5: cannot initialize PMD due to missing run-time dependency on 
> rdma-core libraries (libibverbs, libmlx5)
> PMD: net_mlx4: cannot load glue library: libibverbs.so.1: cannot open shared 
> object file: No such file or directory
> PMD: net_mlx4: cannot initialize PMD due to missing run-time dependency on 
> rdma-core libraries (libibverbs, libmlx4)
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/IK5O7JZSGQJQKI77J2MQPKTX5BJRXC3X/


[ovirt-users] Re: External networks issue after upgrading to 4.3.6

2019-10-09 Thread Miguel Duarte de Mora Barroso
On Wed, Oct 9, 2019 at 1:28 PM ada per  wrote:
>
> I am also attaching a screenshot of  the host network setup. Apparently the 
> hosts can see the external networks and they get synchronized properly. Is 
> there a chance that the issue might be from open-stack security? i disabled 
> the port sec though
>
> On Wed, Oct 9, 2019 at 2:12 PM ada per  wrote:
>>
>> unfortunately I get the following error when running the playbook.
>>
>> TASK [ovirt-provider-ovn-driver : Configure OVN for oVirt] 
>> 
>> fatal: [threatrealm3.sec.ouc.ac.cy]: FAILED! => {
>> "changed": true,
>> "cmd": [
>> "vdsm-tool",
>> "ovn-config",
>> "192.168.1.21",
>> "ovirt-provider-ovn"
>> ],
>> "delta": "0:00:02.993452",
>> "end": "2019-10-09 14:09:57.555302",
>> "rc": 1,
>> "start": "2019-10-09 14:09:54.561850"
>> }

Here you should run with ovirtmgmt as network name - from your
network's screenshot, I think that's the correct thing to do.

This basically specifies on which network will OVN set up its overlay.

Also, it's important to make sure that the IP you're using as
"ovn_central" - 192.168.1.21 -  is the ovirt-engine IP address on the
network you're passing as argument - ovirtmgmt.

>>
>> STDERR:
>>
>> Traceback (most recent call last):
>>   File "/usr/bin/vdsm-tool", line 220, in main
>> return tool_command[cmd]["command"](*args)
>>   File "/usr/lib/python2.7/site-packages/vdsm/tool/ovn_config.py", line 64, 
>> in ovn_config
>> ip_address = get_ip_addr(get_network(network_caps(), net_name))
>>   File "/usr/lib/python2.7/site-packages/vdsm/tool/ovn_config.py", line 118, 
>> in get_network
>> raise NetworkNotFoundError(net_name)
>> NetworkNotFoundError: ovirt-provider-ovn
>>
>>
>> MSG:
>>
>> non-zero return code
>>
>> fatal: [threatrealm2.sec.ouc.ac.cy]: FAILED! => {
>> "changed": true,
>> "cmd": [
>> "vdsm-tool",
>> "ovn-config",
>> "192.168.1.21",
>> "ovirt-provider-ovn"
>> ],
>> "delta": "0:00:03.033376",
>> "end": "2019-10-09 14:09:57.650353",
>> "rc": 1,
>> "start": "2019-10-09 14:09:54.616977"
>> }
>>
>> STDERR:
>>
>> Traceback (most recent call last):
>>   File "/usr/bin/vdsm-tool", line 220, in main
>> return tool_command[cmd]["command"](*args)
>>   File "/usr/lib/python2.7/site-packages/vdsm/tool/ovn_config.py", line 64, 
>> in ovn_config
>> ip_address = get_ip_addr(get_network(network_caps(), net_name))
>>   File "/usr/lib/python2.7/site-packages/vdsm/tool/ovn_config.py", line 118, 
>> in get_network
>> raise NetworkNotFoundError(net_name)
>> NetworkNotFoundError: ovirt-provider-ovn
>>
>>
>> MSG:
>>
>> non-zero return code
>>
>>
>> PLAY RECAP 
>> 
>> localhost  : ok=1changed=0unreachable=0failed=0  
>>   skipped=2rescued=0ignored=0
>> threatrealm2.sec.ouc.ac.cy : ok=5changed=0unreachable=0failed=1  
>>   skipped=0rescued=0ignored=0
>> threatrealm3.sec.ouc.ac.cy : ok=5changed=0unreachable=0failed=1  
>>   skipped=0rescued=0ignored=0
>>
>>
>> On Wed, Oct 9, 2019 at 11:36 AM Miguel Duarte de Mora Barroso 
>>  wrote:
>>>
>>> On Wed, Oct 9, 2019 at 10:13 AM ada per  wrote:
>>> >
>>> > Can you please share the /var/log/openvswitch/ovn-controller.log from the 
>>> > host?
>>> > If you configure a subnet on the network, gets the VM an IP address?
>>> >
>>> >
>>> >the  /var/log/openvswitch/ovn-controller.log  its actually 
>>> > empty.  So Iam Attaching yesterdays log (it wasn’t connecting but after 
>>> > removing and reinstalling the hosts it connects)
>>> >
>>&g

[ovirt-users] Re: External networks issue after upgrading to 4.3.6

2019-10-09 Thread Miguel Duarte de Mora Barroso
On Wed, Oct 9, 2019 at 10:13 AM ada per  wrote:
>
> Can you please share the /var/log/openvswitch/ovn-controller.log from the 
> host?
> If you configure a subnet on the network, gets the VM an IP address?
>
>
>the  /var/log/openvswitch/ovn-controller.log  its actually 
> empty.  So Iam Attaching yesterdays log (it wasn’t connecting but after 
> removing and reinstalling the hosts it connects)
>
> Even with specifying a subnet still no IPs.
>
>
>  btw the openvswitch is active
>
>  openvswitch.service - Open vSwitch
>
>   Loaded: loaded (/usr/lib/systemd/system/openvswitch.service; 
> enabled; vendor preset: disabled)
>
>Active: active (exited) since Tue 2019-10-08 16:02:12 EEST; 
> 18h ago
>
>
>
>   You upgraded from which version ?
>
> Upgraded from 4 .3.4 to 4.3.6.7-1.el7 it currently runs openvswitch 
> 2.10.1

I find it strange that you weren't prompted to update ovs to
openvswitch-2.11.0-4.el7 , which is the currently tagged version for
ovirt-4.3 and master.

If you do yum update openvswitch, doesn't it spot the update possibility ?

>
>
> >> I have another environment running on a previous version of ovirt and it 
> >> works perfectly there. I think its a bug.
>
> Which version of ovirt is being run on that environment ? What's the
> openvswitch / openvswitch-ovn-central version running on that env ?
>
> Ovirt Version 4.3.4.3-1.el7
>
>
>
>Openvswitch 2.10.1  ( so both environments run the same version of 
> openvswitch)
>
>
>
>
>
>   Thinking a couple steps ahead, knowing the list of registered chassis
> could be useful. Please also tell us the output of the command (run it
> on your engine node):
>   $ ovn-sbctl list chassis
>
>
>
>   # ovn-sbctl list chassis
>
> net_mlx5: cannot load glue library: libibverbs.so.1: cannot open shared 
> object file: No such file or directory
>
> net_mlx5: cannot initialize PMD due to missing run-time dependency on 
> rdma-core libraries (libibverbs, libmlx5)
>
> PMD: net_mlx4: cannot load glue library: libibverbs.so.1: cannot open shared 
> obj ect file: No such file or directory
>
> PMD: net_mlx4: cannot initialize PMD due to missing run-time dependency on 
> rdma-core libraries (libibverbs, libmlx4)

Sorry for the ugly logged errors; they're just noise.

Despite that, the absence of registered chassis is quite surely why
your environment is misbehaving - it looks like the ovirt update
messed up the previous config.

Could you follow the instructions at [0] to re-configure OVN ? After
the playbook finishes, please re-check your chassis table (ovn-sbctl
list chassis). You should find exactly one entry per ovirt-node.

[0] - 
https://www.ovirt.org/documentation/admin-guide/chap-External_Providers.html#configuring-hosts-for-an-ovn-tunnel-network

>
>
>
>
>
>
>
> On Tue, Oct 8, 2019 at 6:10 PM Miguel Duarte de Mora Barroso 
>  wrote:
>>
>> On Tue, Oct 8, 2019 at 5:02 PM Miguel Duarte de Mora Barroso
>>  wrote:
>> >
>> > On Tue, Oct 8, 2019 at 4:53 PM Dominik Holler  wrote:
>> > >
>> > >
>> > >
>> > > On Tue, Oct 8, 2019 at 4:25 PM ada per  wrote:
>> > >>
>> > >> After upgrading to the latest stable version the external networks lost 
>> > >> all functionality. Under providers-->ovn-network-provider the test runs 
>> > >> successfully.
>> >
>> > You upgraded from which version ?
>> >
>> > >>
>> > >> But when im creating an external provider network, attaching it to a 
>> > >> router as a LAN setting up dhcp lease it is not reachable from other 
>> > >> VMs in the same network. Hosts and hosted engine can't seem to ping it 
>> > >> either.
>> > >> I tried disabling firewalls on both hosted engines, VMs and host and 
>> > >> still nothing.
>> > >> When configuring Logical networks or VLANs they work perfectly tje one 
>> > >> problem is the external networks.
>> > >>
>> > >> I have another environment running on a previous version of ovirt and 
>> > >> it works perfectly there. I think its a bug.
>> >
>> > Which version of ovirt is being run on that environment ? What's the
>> > openvswitch / openvswitch-ovn-central version running on that env ?
>>
>> Thinking a couple steps ahead, knowing the list of registered chassis
>> could be useful. Please also tell us the output of the command (run it
>> on your engine node)

[ovirt-users] Re: External networks issue after upgrading to 4.3.6

2019-10-08 Thread Miguel Duarte de Mora Barroso
On Tue, Oct 8, 2019 at 5:02 PM Miguel Duarte de Mora Barroso
 wrote:
>
> On Tue, Oct 8, 2019 at 4:53 PM Dominik Holler  wrote:
> >
> >
> >
> > On Tue, Oct 8, 2019 at 4:25 PM ada per  wrote:
> >>
> >> After upgrading to the latest stable version the external networks lost 
> >> all functionality. Under providers-->ovn-network-provider the test runs 
> >> successfully.
>
> You upgraded from which version ?
>
> >>
> >> But when im creating an external provider network, attaching it to a 
> >> router as a LAN setting up dhcp lease it is not reachable from other VMs 
> >> in the same network. Hosts and hosted engine can't seem to ping it either.
> >> I tried disabling firewalls on both hosted engines, VMs and host and still 
> >> nothing.
> >> When configuring Logical networks or VLANs they work perfectly tje one 
> >> problem is the external networks.
> >>
> >> I have another environment running on a previous version of ovirt and it 
> >> works perfectly there. I think its a bug.
>
> Which version of ovirt is being run on that environment ? What's the
> openvswitch / openvswitch-ovn-central version running on that env ?

Thinking a couple steps ahead, knowing the list of registered chassis
could be useful. Please also tell us the output of the command (run it
on your engine node):
  $ ovn-sbctl list chassis

>
> >>
> >
> > Can you please share the /var/log/openvswitch/ovn-controller.log from the 
> > host?
> > If you configure a subnet on the network, gets the VM an IP address?
> >
> >
> >>
> >>
> >> Thanks for your help
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/GZFJGDDDMNX6MSCJETYEFFX7BYS5R2FY/


[ovirt-users] Re: External networks issue after upgrading to 4.3.6

2019-10-08 Thread Miguel Duarte de Mora Barroso
On Tue, Oct 8, 2019 at 4:53 PM Dominik Holler  wrote:
>
>
>
> On Tue, Oct 8, 2019 at 4:25 PM ada per  wrote:
>>
>> After upgrading to the latest stable version the external networks lost all 
>> functionality. Under providers-->ovn-network-provider the test runs 
>> successfully.

You upgraded from which version ?

>>
>> But when im creating an external provider network, attaching it to a router 
>> as a LAN setting up dhcp lease it is not reachable from other VMs in the 
>> same network. Hosts and hosted engine can't seem to ping it either.
>> I tried disabling firewalls on both hosted engines, VMs and host and still 
>> nothing.
>> When configuring Logical networks or VLANs they work perfectly tje one 
>> problem is the external networks.
>>
>> I have another environment running on a previous version of ovirt and it 
>> works perfectly there. I think its a bug.

Which version of ovirt is being run on that environment ? What's the
openvswitch / openvswitch-ovn-central version running on that env ?

>>
>
> Can you please share the /var/log/openvswitch/ovn-controller.log from the 
> host?
> If you configure a subnet on the network, gets the VM an IP address?
>
>
>>
>>
>> Thanks for your help
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/FTJOQVKECWCYU4XTU2HNG3DHJQLYSCRF/


[ovirt-users] Re: Problem with logical network

2019-10-07 Thread Miguel Duarte de Mora Barroso
On Sat, Oct 5, 2019 at 7:15 AM Strahil  wrote:
>
> Can you check your hosts and especially their networks.
> If any network is not OK (out of sync), you can fix it from the UI.
>
> Best Regards,
> Strahil Nikolov
>
> On Oct 4, 2019 23:47, Alex Irmel Oviedo Solis  wrote:
>
> Hello, I'm trying to run a vm with two ethernet interfaces, one of them 
> attached to ovirmnt and the other attached to a logical network named 
> internal_servers and got this error:

Which ovirt version ?

>
> "VM is down with error. Exit message: can not get MTU interface in 'br-int': 
> No such device2

This error sounds related to ovn provider networks (it uses an
internal OVS bridge, called br-int). Is this 'internal_servers'
network a network 'created on external provider' ?

If so, I think somehow OVN was not properly configured; please tell us
the configuration state in one of your hosts - the output of:
  - ovs-vsctl show
  - ovs-vsctl list Open

>
> Then I created the bridge manually but I get the following error:
>
> "VM is down with error. Exit message: Hook Error: ('',)."
>
> Please help me.
>
> Best Regards
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/TMR7HIDUMJUYHZ77BD4D4Q26CJ2JESZU/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/4WGFFQKRQI73RS5U3H76HYOZRUFJYWWO/


[ovirt-users] Re: ovn networking

2019-08-22 Thread Miguel Duarte de Mora Barroso
On Thu, Aug 22, 2019 at 4:53 PM Gianluca Cecchi
 wrote:
>
>
>
> On Tue, Aug 20, 2019 at 12:01 PM Miguel Duarte de Mora Barroso 
>  wrote:
>>
>> On Mon, Aug 19, 2019 at 12:47 PM Staniforth, Paul
>>  wrote:
>> >
>> > Thanks Miguel,
>> >  I'm using 
>> > openvswitch-ovn-common-2.11.0-4.el7.x86_64
>>
>> I hoped this would be gone in version 2.11, but, seems like the
>> openvswitch build hasn't been updated for quite some time
>> (2019-03-20).
>>
>> Unfortunately I cannot provide an ETA on a newer OVS build.
>>
>
> I've just updated my ovirt engine server from 4.3.4 to 4.3.5 
> (ovirt-engine-4.3.5.5-1.el7.noarch) and then also "yum update" and reboot.
> Actually I get those messages as soon as I login to the system, not only 
> running commands:
>
> from my laptop
>  $ ssh ovmgr1
> Last login: Thu Aug 22 16:45:09 2019 from 10.4.23.18
> net_mlx5: cannot load glue library: libibverbs.so.1: cannot open shared 
> object file: No such file or directory
> net_mlx5: cannot initialize PMD due to missing run-time dependency on 
> rdma-core libraries (libibverbs, libmlx5)
> PMD: net_mlx4: cannot load glue library: libibverbs.so.1: cannot open shared 
> object file: No such file or directory
> PMD: net_mlx4: cannot initialize PMD due to missing run-time dependency on 
> rdma-core libraries (libibverbs, libmlx4)
> net_mlx5: cannot load glue library: libibverbs.so.1: cannot open shared 
> object file: No such file or directory
> net_mlx5: cannot initialize PMD due to missing run-time dependency on 
> rdma-core libraries (libibverbs, libmlx5)
> PMD: net_mlx4: cannot load glue library: libibverbs.so.1: cannot open shared 
> object file: No such file or directory
> PMD: net_mlx4: cannot initialize PMD due to missing run-time dependency on 
> rdma-core libraries (libibverbs, libmlx4)
> [g.cecchi@ovmgr1 ~]$
>
> Any way to fix?

You can get rid of those by installing the dependency libibverbs.
Other than that, none that I'm aware.

> Thanks,
> Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/NFMCO7IU4RT3R7QK2ZRVDBULBNI3ZPMC/


[ovirt-users] Re: attach untagged vlan internally on vm

2019-08-22 Thread Miguel Duarte de Mora Barroso
On Wed, Aug 21, 2019 at 9:18 AM  wrote:
>
> good day
> currently i am testing oVirt on a single box and setup some tagged vms and 
> non tagged vm.
> the non tagged vm is a firewall but it has limitations on the number of nic 
> so i cannot attach tagged vnic and wish to handdle vlan tagging on it
>
> is it possible to pass untaged franes internally?

I think it would fallback to the linux bridge default configuration,
which internally tags untagged frames with vlanID 1, and untags them
when exiting the port. Unless I'm wrong (for instance, we change the
bridge defaults), this means you can pass untagged frames through the
bridge.

Adding Edward, to keep me honest.




> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/HYFSLS5QM5DKBYWFF44NCB4E3CD5GKH4/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/ME77W5PLKOQC5U3OXNZE3W7W27ZOPVIP/


[ovirt-users] Re: Need to enable STP on ovirt bridges

2019-08-22 Thread Miguel Duarte de Mora Barroso
On Sat, Aug 17, 2019 at 11:27 AM  wrote:
>
> Hello. I have been trying to figure out an issue for a very long time.
> That issue relates to the ethernet and 10gb fc links that I have on my
> cluster being disabled any time a migration occurs.
>
> I believe this is because I need to have STP turned on in order to
> participate with the switch. However, there does not seem to be any
> way to tell oVirt to stop turning it off! Very frustrating.
>
> After entering a cronjob that enables stp on all bridges every 1
> minute, the migration issue disappears
>
> Is there any way at all to do without this cronjob and set STP to be
> ON without having to resort to such a silly solution?

Vdsm exposes a per bridge STP knob that you can use for this. By
default it is set to false, which is probably why you had to use this
shenanigan.

You can, for instance:

# show present state
[vagrant@vdsm ~]$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 52:54:00:41:fb:37 brd ff:ff:ff:ff:ff:ff
3: eth1:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 52:54:00:83:5b:6f brd ff:ff:ff:ff:ff:ff
inet 192.168.50.50/24 brd 192.168.50.255 scope global noprefixroute eth1
   valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe83:5b6f/64 scope link
   valid_lft forever preferred_lft forever
19: ;vdsmdummy;:  mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether 8e:5c:2e:87:fa:0b brd ff:ff:ff:ff:ff:ff

# show example bridge configuration - you're looking for the STP knob here.
[root@vdsm ~]$ cat bridged_net_with_stp
{
  "bondings": {},
  "networks": {
"test-network": {
  "nic": "eth0",
  "switch": "legacy",
  "bridged": true,
  "stp": true
}
  },
  "options": {
"connectivityCheck": false
  }
}

# issue setup networks command:
[root@vdsm ~]$ vdsm-client -f bridged_net_with_stp Host setupNetworks
{
"code": 0,
"message": "Done"
}

# show bridges
[root@vdsm ~]$ brctl show
bridge name bridge id STP enabled interfaces
;vdsmdummy; 8000. no
test-network 8000.52540041fb37 yes eth0

# show final state
[root@vdsm ~]$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast
master test-network state UP group default qlen 1000
link/ether 52:54:00:41:fb:37 brd ff:ff:ff:ff:ff:ff
3: eth1:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 52:54:00:83:5b:6f brd ff:ff:ff:ff:ff:ff
inet 192.168.50.50/24 brd 192.168.50.255 scope global noprefixroute eth1
   valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe83:5b6f/64 scope link
   valid_lft forever preferred_lft forever
19: ;vdsmdummy;:  mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether 8e:5c:2e:87:fa:0b brd ff:ff:ff:ff:ff:ff
432: test-network:  mtu 1500 qdisc
noqueue state UP group default qlen 1000
link/ether 52:54:00:41:fb:37 brd ff:ff:ff:ff:ff:ff

I don't think this STP parameter is exposed via engine UI; @Dominik
Holler , could you confirm ? What are our plans for it ?

>
> Here are some details about my systems, if you need it.
>
>
> selinux is disabled.
>
>
>
>
>
>
>
>
>
> [root@swm-02 ~]# rpm -qa | grep ovirt
> ovirt-imageio-common-1.5.1-0.el7.x86_64
> ovirt-release43-4.3.5.2-1.el7.noarch
> ovirt-imageio-daemon-1.5.1-0.el7.noarch
> ovirt-vmconsole-host-1.0.7-2.el7.noarch
> ovirt-hosted-engine-setup-2.3.11-1.el7.noarch
> ovirt-ansible-hosted-engine-setup-1.0.26-1.el7.noarch
> python2-ovirt-host-deploy-1.8.0-1.el7.noarch
> ovirt-ansible-engine-setup-1.1.9-1.el7.noarch
> python2-ovirt-setup-lib-1.2.0-1.el7.noarch
> cockpit-machines-ovirt-195.1-1.el7.noarch
> ovirt-hosted-engine-ha-2.3.3-1.el7.noarch
> ovirt-vmconsole-1.0.7-2.el7.noarch
> cockpit-ovirt-dashboard-0.13.5-1.el7.noarch
> ovirt-provider-ovn-driver-1.2.22-1.el7.noarch
> ovirt-host-deploy-common-1.8.0-1.el7.noarch
> ovirt-host-4.3.4-1.el7.x86_64
> python-ovirt-engine-sdk4-4.3.2-2.el7.x86_64
> ovirt-host-dependencies-4.3.4-1.el7.x86_64
> ovirt-ansible-repositories-1.1.5-1.el7.noarch
> [root@swm-02 ~]# cat /etc/redhat-release
> CentOS Linux release 7.6.1810 (Core)
> [root@swm-02 ~]# uname -r
> 3.10.0-957.27.2.el7.x86_64
> You have new mail in /var/spool/mail/root
> [root@swm-02 ~]# ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> 2: em1:  mtu 1500 qdisc mq master
> test state UP group default qlen 1000
> link/ether d4:ae:52:8d:50:48 brd 

[ovirt-users] Re: ovn networking

2019-08-20 Thread Miguel Duarte de Mora Barroso
On Mon, Aug 19, 2019 at 12:47 PM Staniforth, Paul
 wrote:
>
> Thanks Miguel,
>  I'm using openvswitch-ovn-common-2.11.0-4.el7.x86_64

I hoped this would be gone in version 2.11, but, seems like the
openvswitch build hasn't been updated for quite some time
(2019-03-20).

Unfortunately I cannot provide an ETA on a newer OVS build.

>
> I'll just ignore as I don't want to create any dependency problems.
>
> Regards,
>Paul S.
>
> ____________
> From: Miguel Duarte de Mora Barroso 
> Sent: 16 August 2019 12:09
> To: Staniforth, Paul
> Cc: users@ovirt.org
> Subject: Re: [ovirt-users] ovn networking
>
> On Wed, Aug 14, 2019 at 9:09 AM Staniforth, Paul
>  wrote:
> >
> > Hello
> >
> >   I the latest release of the engine 4.3.5.5-1.el7
> >
> > ovn-nbctl  show
> >
> > ovn-sbctl  show
> >
> >
> > both seem to work but produce the errors
> >
> >
> > net_mlx5: cannot load glue library: libibverbs.so.1: cannot open shared 
> > object file: No such file or directory
> > net_mlx5: cannot initialize PMD due to missing run-time dependency on 
> > rdma-core libraries (libibverbs, libmlx5)
> > PMD: net_mlx4: cannot load glue library: libibverbs.so.1: cannot open 
> > shared object file: No such file or directory
> > PMD: net_mlx4: cannot initialize PMD due to missing run-time dependency on 
> > rdma-core libraries (libibverbs, libmlx4)
> >
> >
> > should libibverbs be a dependency?
>
> It shouldn't, since has no use in the engine node - other than
> silencing those errors.
>
> Which OVS / OVN version are you using ?
>
> >
> > Paul S.
> > To view the terms under which this email is distributed, please go to:-
> > http://leedsbeckett.ac.uk/disclaimer/email/
> >
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: 
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fsite%2Fprivacy-policy%2Fdata=02%7C01%7CP.Staniforth%40leedsbeckett.ac.uk%7Cc27b535313664fe3b0f508d7223a2bfc%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C637015505546807557sdata=DafifdFwfFumf10G6KxdAm2GxZNo%2BL%2FuQlNcT0c9Pxc%3Dreserved=0
> > oVirt Code of Conduct: 
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2Fdata=02%7C01%7CP.Staniforth%40leedsbeckett.ac.uk%7Cc27b535313664fe3b0f508d7223a2bfc%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C637015505546817549sdata=O3l6rooWKILYsyPAQWDPKuwQFyoOLFG7IbT7j5YiPZ4%3Dreserved=0
> > List Archives: 
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2FJ4T4YFAVYOMASVV3ACCNVFGF3YSAT3N4%2Fdata=02%7C01%7CP.Staniforth%40leedsbeckett.ac.uk%7Cc27b535313664fe3b0f508d7223a2bfc%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C637015505546817549sdata=WCOzfW2gI3H5a8E85WLDo2zsW0AEvTKlcqWdKa74AJ4%3Dreserved=0
> To view the terms under which this email is distributed, please go to:-
> http://leedsbeckett.ac.uk/disclaimer/email/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/OJBLUKJFBESRCCIMAMUFNSLAA7ZC4V65/


[ovirt-users] Re: ovn networking

2019-08-16 Thread Miguel Duarte de Mora Barroso
On Wed, Aug 14, 2019 at 9:09 AM Staniforth, Paul
 wrote:
>
> Hello
>
>   I the latest release of the engine 4.3.5.5-1.el7
>
> ovn-nbctl  show
>
> ovn-sbctl  show
>
>
> both seem to work but produce the errors
>
>
> net_mlx5: cannot load glue library: libibverbs.so.1: cannot open shared 
> object file: No such file or directory
> net_mlx5: cannot initialize PMD due to missing run-time dependency on 
> rdma-core libraries (libibverbs, libmlx5)
> PMD: net_mlx4: cannot load glue library: libibverbs.so.1: cannot open shared 
> object file: No such file or directory
> PMD: net_mlx4: cannot initialize PMD due to missing run-time dependency on 
> rdma-core libraries (libibverbs, libmlx4)
>
>
> should libibverbs be a dependency?

It shouldn't, since has no use in the engine node - other than
silencing those errors.

Which OVS / OVN version are you using ?

>
> Paul S.
> To view the terms under which this email is distributed, please go to:-
> http://leedsbeckett.ac.uk/disclaimer/email/
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/J4T4YFAVYOMASVV3ACCNVFGF3YSAT3N4/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/U27MNWZB33G37D6QB3VUTF6XALUJ7SY5/


[ovirt-users] Re: port_security in external networks-API

2019-08-07 Thread Miguel Duarte de Mora Barroso
On Tue, Aug 6, 2019 at 9:30 AM ada per  wrote:
>
> Thank you very much for all the information it help me understand it better.
> Unfortunately i cant get it to work in python :(

Could you elaborate more ?

You can also take a look at [3], on ovirt's system test project. It
does what you're after, but using the OST entities - which are a
simple wrapper over the REST API ones.

Never the less, that test is useful to understand what needs to be done.

>
> On Fri, Jul 26, 2019 at 2:09 PM Miguel Duarte de Mora Barroso 
>  wrote:
>>
>> On Thu, Jul 25, 2019 at 3:50 PM ada per  wrote:
>> >
>> > Hello everyone,
>> >
>> > I have the following python script that creates an external network, but 
>> > now after updating  ovirt a new option "network port security" exists that 
>> > is set as enabled by default.
>>
>> That attribute is specified in
>> https://github.com/oVirt/ovirt-provider-ovn#section-network - the
>> default on the configuration file is set by engine-setup to true.
>>
>> >
>> > How can i disable the network port security?
>>
>> You can update it for each network / logical port in the system.
>>
>> Be advised that updating the port security attribute of a network
>> value will *not* impact existing ports - it only impacts newly created
>> logical ports.
>>
>> To disable that property for existing VMs you need to update that
>> property in the logical port to which the VM is connected, via the
>> logical port's REST API. The logical port follows a subset of the
>> networking api, which is defined in [0].
>>
>> Some time ago I wrote an example playbook that can be leveraged for
>> this type of thing, check [1]. It's usage is described in [2], look
>> for 'update_port_security'. You can update it for all port in the
>> system, for all ports within a logical network, or for a single port.
>>
>> Let me know if this helps.
>>
>> [0] - 
>> https://github.com/oVirt/ovirt-provider-ovn/blob/master/docs/provider_api_description.adoc#ports
>> [1] - 
>> https://github.com/maiqueb/ovirt-security-groups-demo/blob/master/playbooks/update_port_security.yml
>> [2] - https://github.com/maiqueb/ovirt-security-groups-demo#provided-tools

[3] - 
https://github.com/oVirt/ovirt-system-tests/blob/master/network-suite-master/tests/ovs/test_ovn_physnet.py#L137

>>
>> >
>> > thanks!! :)
>> >
>> >networks_service = connection.system_service().networks_service()
>> > # Use the "add" method to create new VM logical network in data center
>> > network = networks_service.add(
>> > network=types.Network(
>> > name= ext_net_name,
>> > description='Network for testing API',
>> > data_center=types.DataCenter(
>> > name='Default'
>> > ),
>> > usages=[types.NetworkUsage.VM],
>> > external_provider=types.OpenStackNetworkProvider(
>> > id=provider.id
>> >
>> > )
>> > ),
>> > ___
>> > Users mailing list -- users@ovirt.org
>> > To unsubscribe send an email to users-le...@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/PZI4SHUNFWPPRNTIA2I445PG6HV7YPVZ/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/ZBWJCH54K7LAIRCS7F2KRBPWOAMWIXGB/


[ovirt-users] Re: port_security in external networks-API

2019-07-26 Thread Miguel Duarte de Mora Barroso
On Thu, Jul 25, 2019 at 3:50 PM ada per  wrote:
>
> Hello everyone,
>
> I have the following python script that creates an external network, but now 
> after updating  ovirt a new option "network port security" exists that is set 
> as enabled by default.

That attribute is specified in
https://github.com/oVirt/ovirt-provider-ovn#section-network - the
default on the configuration file is set by engine-setup to true.

>
> How can i disable the network port security?

You can update it for each network / logical port in the system.

Be advised that updating the port security attribute of a network
value will *not* impact existing ports - it only impacts newly created
logical ports.

To disable that property for existing VMs you need to update that
property in the logical port to which the VM is connected, via the
logical port's REST API. The logical port follows a subset of the
networking api, which is defined in [0].

Some time ago I wrote an example playbook that can be leveraged for
this type of thing, check [1]. It's usage is described in [2], look
for 'update_port_security'. You can update it for all port in the
system, for all ports within a logical network, or for a single port.

Let me know if this helps.

[0] - 
https://github.com/oVirt/ovirt-provider-ovn/blob/master/docs/provider_api_description.adoc#ports
[1] - 
https://github.com/maiqueb/ovirt-security-groups-demo/blob/master/playbooks/update_port_security.yml
[2] - https://github.com/maiqueb/ovirt-security-groups-demo#provided-tools

>
> thanks!! :)
>
>networks_service = connection.system_service().networks_service()
> # Use the "add" method to create new VM logical network in data center
> network = networks_service.add(
> network=types.Network(
> name= ext_net_name,
> description='Network for testing API',
> data_center=types.DataCenter(
> name='Default'
> ),
> usages=[types.NetworkUsage.VM],
> external_provider=types.OpenStackNetworkProvider(
> id=provider.id
>
> )
> ),
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/PZI4SHUNFWPPRNTIA2I445PG6HV7YPVZ/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/XYVBGU6KSWJPKXGV5LEVTI52VVCAV2VL/


[ovirt-users] Re: major network changes

2019-07-18 Thread Miguel Duarte de Mora Barroso
On Thu, Jul 18, 2019 at 2:50 PM Miguel Duarte de Mora Barroso
 wrote:
>
> On Thu, Jul 18, 2019 at 1:57 PM carl langlois  wrote:
> >
> > Hi Miguel,
> >
> > I have managed to change the config for the ovn-controler.
> > with those commands
> >  ovs-vsctl set Open_vSwitch . external-ids:ovn-remote=ssl:10.16.248.74:6642
> >  ovs-vsctl set Open_vSwitch . external-ids:ovn-encap-ip=10.16.248.65
> > and restating the services
>
> Yes, that's what the script is supposed to do, check [0].
>
> Not sure why running vdsm-tool didn't work for you.
>
> >
> > But even with this i still have the "fail for liveliness check" when 
> > starting the ovirt engine. But one thing  i notice with our new network is 
> > that the reverse DNS does not work(IP -> hostname). The forward is working 
> > fine. I am trying to see with our IT why it is not working.
>
> Do you guys use OVN? If not, you could disable the provider, install
> the hosted-engine VM, then, if needed, re-add / re-activate it .

I'm assuming it fails for the same reason you've stated initially  -
i.e. ovn-controller is involved; if it is not, disregard this msg :)
>
> [0] - 
> https://github.com/oVirt/ovirt-provider-ovn/blob/master/driver/scripts/setup_ovn_controller.sh#L24
>
> >
> > Regards.
> > Carl
> >
> > On Thu, Jul 18, 2019 at 4:03 AM Miguel Duarte de Mora Barroso 
> >  wrote:
> >>
> >> On Wed, Jul 17, 2019 at 7:07 PM carl langlois  
> >> wrote:
> >> >
> >> > Hi
> >> > Here is the output of the command
> >> >
> >> > [root@ovhost1 ~]# vdsm-tool --vvverbose ovn-config 10.16.248.74 ovirtmgmt
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,581::cmdutils::150::root::(exec_cmd) lshw -json -disable usb 
> >> > -disable pcmcia -disable isapnp -disable ide -disable scsi -disable dmi 
> >> > -disable memory -disable cpuinfo (cwd None)
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,738::cmdutils::158::root::(exec_cmd) SUCCESS:  = '';  
> >> > = 0
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,741::routes::109::root::(get_gateway) The gateway 10.16.248.1 
> >> > is duplicated for the device ovirtmgmt
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,742::routes::109::root::(get_gateway) The gateway 10.16.248.1 
> >> > is duplicated for the device ovirtmgmt
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,742::cmdutils::150::root::(exec_cmd) /sbin/tc qdisc show (cwd 
> >> > None)
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,744::cmdutils::158::root::(exec_cmd) SUCCESS:  = '';  
> >> > = 0
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,745::cmdutils::150::root::(exec_cmd) /sbin/tc class show dev 
> >> > enp2s0f1 classid 0:1388 (cwd None)
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,747::cmdutils::158::root::(exec_cmd) SUCCESS:  = '';  
> >> > = 0
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,766::cmdutils::150::root::(exec_cmd) 
> >> > /usr/share/openvswitch/scripts/ovs-ctl status (cwd None)
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,777::cmdutils::158::root::(exec_cmd) SUCCESS:  = '';  
> >> > = 0
> >> > MainThread::DEBUG::2019-07-17 13:02:52,778::vsctl::67::root::(commit) 
> >> > Executing commands: /usr/bin/ovs-vsctl --timeout=5 --oneline 
> >> > --format=json -- list Bridge -- list Port -- list Interface
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,778::cmdutils::150::root::(exec_cmd) /usr/bin/ovs-vsctl 
> >> > --timeout=5 --oneline --format=json -- list Bridge -- list Port -- list 
> >> > Interface (cwd None)
> >> > MainThread::DEBUG::2019-07-17 
> >> > 13:02:52,799::cmdutils::158::root::(exec_cmd) SUCCESS:  = '';  
> >> > = 0
> >> > netlink/events::DEBUG::2019-07-17 
> >> > 13:02:52,802::concurrent::192::root::(run) START thread 
> >> >  (func= >> > method Monitor._scan of  >> > 0x7f99fb618c90>>, args=(), kwargs={})
> >> > netlink/events::DEBUG::2019-07-17 
> >> > 13:02:54,805::concurrent::195::root::(run) FINISH thread 
> >> > 
> >> > Using default PKI files
> >> >
> >> > I do not see any indication of the config??
> >>
> >> And afterwards when you execute "ovs-vsctl list Open_vSwitch" does

[ovirt-users] Re: major network changes

2019-07-18 Thread Miguel Duarte de Mora Barroso
On Thu, Jul 18, 2019 at 1:57 PM carl langlois  wrote:
>
> Hi Miguel,
>
> I have managed to change the config for the ovn-controler.
> with those commands
>  ovs-vsctl set Open_vSwitch . external-ids:ovn-remote=ssl:10.16.248.74:6642
>  ovs-vsctl set Open_vSwitch . external-ids:ovn-encap-ip=10.16.248.65
> and restating the services

Yes, that's what the script is supposed to do, check [0].

Not sure why running vdsm-tool didn't work for you.

>
> But even with this i still have the "fail for liveliness check" when starting 
> the ovirt engine. But one thing  i notice with our new network is that the 
> reverse DNS does not work(IP -> hostname). The forward is working fine. I am 
> trying to see with our IT why it is not working.

Do you guys use OVN? If not, you could disable the provider, install
the hosted-engine VM, then, if needed, re-add / re-activate it .

[0] - 
https://github.com/oVirt/ovirt-provider-ovn/blob/master/driver/scripts/setup_ovn_controller.sh#L24

>
> Regards.
> Carl
>
> On Thu, Jul 18, 2019 at 4:03 AM Miguel Duarte de Mora Barroso 
>  wrote:
>>
>> On Wed, Jul 17, 2019 at 7:07 PM carl langlois  wrote:
>> >
>> > Hi
>> > Here is the output of the command
>> >
>> > [root@ovhost1 ~]# vdsm-tool --vvverbose ovn-config 10.16.248.74 ovirtmgmt
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,581::cmdutils::150::root::(exec_cmd) lshw -json -disable usb 
>> > -disable pcmcia -disable isapnp -disable ide -disable scsi -disable dmi 
>> > -disable memory -disable cpuinfo (cwd None)
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,738::cmdutils::158::root::(exec_cmd) SUCCESS:  = '';  = 0
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,741::routes::109::root::(get_gateway) The gateway 10.16.248.1 is 
>> > duplicated for the device ovirtmgmt
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,742::routes::109::root::(get_gateway) The gateway 10.16.248.1 is 
>> > duplicated for the device ovirtmgmt
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,742::cmdutils::150::root::(exec_cmd) /sbin/tc qdisc show (cwd 
>> > None)
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,744::cmdutils::158::root::(exec_cmd) SUCCESS:  = '';  = 0
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,745::cmdutils::150::root::(exec_cmd) /sbin/tc class show dev 
>> > enp2s0f1 classid 0:1388 (cwd None)
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,747::cmdutils::158::root::(exec_cmd) SUCCESS:  = '';  = 0
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,766::cmdutils::150::root::(exec_cmd) 
>> > /usr/share/openvswitch/scripts/ovs-ctl status (cwd None)
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,777::cmdutils::158::root::(exec_cmd) SUCCESS:  = '';  = 0
>> > MainThread::DEBUG::2019-07-17 13:02:52,778::vsctl::67::root::(commit) 
>> > Executing commands: /usr/bin/ovs-vsctl --timeout=5 --oneline --format=json 
>> > -- list Bridge -- list Port -- list Interface
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,778::cmdutils::150::root::(exec_cmd) /usr/bin/ovs-vsctl 
>> > --timeout=5 --oneline --format=json -- list Bridge -- list Port -- list 
>> > Interface (cwd None)
>> > MainThread::DEBUG::2019-07-17 
>> > 13:02:52,799::cmdutils::158::root::(exec_cmd) SUCCESS:  = '';  = 0
>> > netlink/events::DEBUG::2019-07-17 
>> > 13:02:52,802::concurrent::192::root::(run) START thread 
>> >  (func=> > method Monitor._scan of > > 0x7f99fb618c90>>, args=(), kwargs={})
>> > netlink/events::DEBUG::2019-07-17 
>> > 13:02:54,805::concurrent::195::root::(run) FINISH thread 
>> > 
>> > Using default PKI files
>> >
>> > I do not see any indication of the config??
>>
>> And afterwards when you execute "ovs-vsctl list Open_vSwitch" does it
>> reflect the updated value ?
>>
>> This command would have to be performed in the node where hosted
>> engine will be hosted - not sure if it's possible to determine before
>> hand which one it will be. If not, you should run it in all the nodes
>> in the cluster, to be sure.
>>
>> >
>> > Regards
>> > Carl
>> >
>> > On Wed, Jul 17, 2019 at 11:40 AM carl langlois  
>> > wrote:
>> >>
>> >> Hi
>> >>
>> >> I have open a bug https://bugzilla.redhat.com/show_bug.cgi?id=1730776
>> >>
>> >> I have try this command "vdsm-tool ovn-config 10.16.248.74 ovirtmgmt" on 
>> >&

[ovirt-users] Re: major network changes

2019-07-18 Thread Miguel Duarte de Mora Barroso
On Wed, Jul 17, 2019 at 7:07 PM carl langlois  wrote:
>
> Hi
> Here is the output of the command
>
> [root@ovhost1 ~]# vdsm-tool --vvverbose ovn-config 10.16.248.74 ovirtmgmt
> MainThread::DEBUG::2019-07-17 13:02:52,581::cmdutils::150::root::(exec_cmd) 
> lshw -json -disable usb -disable pcmcia -disable isapnp -disable ide -disable 
> scsi -disable dmi -disable memory -disable cpuinfo (cwd None)
> MainThread::DEBUG::2019-07-17 13:02:52,738::cmdutils::158::root::(exec_cmd) 
> SUCCESS:  = '';  = 0
> MainThread::DEBUG::2019-07-17 13:02:52,741::routes::109::root::(get_gateway) 
> The gateway 10.16.248.1 is duplicated for the device ovirtmgmt
> MainThread::DEBUG::2019-07-17 13:02:52,742::routes::109::root::(get_gateway) 
> The gateway 10.16.248.1 is duplicated for the device ovirtmgmt
> MainThread::DEBUG::2019-07-17 13:02:52,742::cmdutils::150::root::(exec_cmd) 
> /sbin/tc qdisc show (cwd None)
> MainThread::DEBUG::2019-07-17 13:02:52,744::cmdutils::158::root::(exec_cmd) 
> SUCCESS:  = '';  = 0
> MainThread::DEBUG::2019-07-17 13:02:52,745::cmdutils::150::root::(exec_cmd) 
> /sbin/tc class show dev enp2s0f1 classid 0:1388 (cwd None)
> MainThread::DEBUG::2019-07-17 13:02:52,747::cmdutils::158::root::(exec_cmd) 
> SUCCESS:  = '';  = 0
> MainThread::DEBUG::2019-07-17 13:02:52,766::cmdutils::150::root::(exec_cmd) 
> /usr/share/openvswitch/scripts/ovs-ctl status (cwd None)
> MainThread::DEBUG::2019-07-17 13:02:52,777::cmdutils::158::root::(exec_cmd) 
> SUCCESS:  = '';  = 0
> MainThread::DEBUG::2019-07-17 13:02:52,778::vsctl::67::root::(commit) 
> Executing commands: /usr/bin/ovs-vsctl --timeout=5 --oneline --format=json -- 
> list Bridge -- list Port -- list Interface
> MainThread::DEBUG::2019-07-17 13:02:52,778::cmdutils::150::root::(exec_cmd) 
> /usr/bin/ovs-vsctl --timeout=5 --oneline --format=json -- list Bridge -- list 
> Port -- list Interface (cwd None)
> MainThread::DEBUG::2019-07-17 13:02:52,799::cmdutils::158::root::(exec_cmd) 
> SUCCESS:  = '';  = 0
> netlink/events::DEBUG::2019-07-17 13:02:52,802::concurrent::192::root::(run) 
> START thread  
> (func= object at 0x7f99fb618c90>>, args=(), kwargs={})
> netlink/events::DEBUG::2019-07-17 13:02:54,805::concurrent::195::root::(run) 
> FINISH thread 
> Using default PKI files
>
> I do not see any indication of the config??

And afterwards when you execute "ovs-vsctl list Open_vSwitch" does it
reflect the updated value ?

This command would have to be performed in the node where hosted
engine will be hosted - not sure if it's possible to determine before
hand which one it will be. If not, you should run it in all the nodes
in the cluster, to be sure.

>
> Regards
> Carl
>
> On Wed, Jul 17, 2019 at 11:40 AM carl langlois  wrote:
>>
>> Hi
>>
>> I have open a bug https://bugzilla.redhat.com/show_bug.cgi?id=1730776
>>
>> I have try this command "vdsm-tool ovn-config 10.16.248.74 ovirtmgmt" on one 
>> of the host but nothing changed. After a restart of the ovn-controler i 
>> still get
>>
>> 2019-07-17T15:38:52.572Z|00033|reconnect|INFO|ssl:10.8.236.244:6642: waiting 
>> 8 seconds before reconnect
>> 2019-07-17T15:39:00.578Z|00034|reconnect|INFO|ssl:10.8.236.244:6642: 
>> connecting...
>> 2019-07-17T15:39:05.720Z|00035|fatal_signal|WARN|terminating with signal 15 
>> (Terminated)
>> 2019-07-17T15:39:05.863Z|1|vlog|INFO|opened log file 
>> /var/log/openvswitch/ovn-controller.log
>> 2019-07-17T15:39:05.864Z|2|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
>>  connecting...
>> 2019-07-17T15:39:05.864Z|3|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
>>  connected
>> 2019-07-17T15:39:05.865Z|4|reconnect|INFO|ssl:10.8.236.244:6642: 
>> connecting...
>> 2019-07-17T15:39:06.865Z|5|reconnect|INFO|ssl:10.8.236.244:6642: 
>> connection attempt timed out
>> 2019-07-17T15:39:06.865Z|6|reconnect|INFO|ssl:10.8.236.244:6642: waiting 
>> 1 seconds before reconnect
>> 2019-07-17T15:39:07.867Z|7|reconnect|INFO|ssl:10.8.236.244:6642: 
>> connecting...
>> 2019-07-17T15:39:08.867Z|8|reconnect|INFO|ssl:10.8.236.244:6642: 
>> connection attempt timed out
>> 2019-07-17T15:39:08.868Z|9|reconnect|INFO|ssl:10.8.236.244:6642: waiting 
>> 2 seconds before reconnect
>> 2019-07-17T15:39:10.870Z|00010|reconnect|INFO|ssl:10.8.236.244:6642: 
>> connecting...
>> 2019-07-17T15:39:12.872Z|00011|reconnect|INFO|ssl:10.8.236.244:6642: 
>> connection attempt timed out
>> 2019-07-17T15:39:12.872Z|00012|reconnect|INFO|ssl:10.8.236.244:6642: waiting 
>> 4 seconds before reconnect
>>
>>
>>
>> On Wed, Jul 17, 2019 at 10:56 AM Miguel D

[ovirt-users] Re: major network changes

2019-07-17 Thread Miguel Duarte de Mora Barroso
On Wed, Jul 17, 2019 at 3:01 PM carl langlois  wrote:
>
> Hi Miguel
>
> if i do ovs-vsctl  list Open_vSwitch i get
>
> uuid   : ce94c4b1-7eb2-42e3-8bfd-96e1dec40dea
> bridges : [9b0738ee-594d-4a87-8967-049a8b1a5774]
> cur_cfg : 1
> datapath_types  : [netdev, system]
> db_version  : "7.14.0"
> external_ids: {hostname="ovhost2", ovn-bridge-mappings="", 
> ovn-encap-ip="10.8.236.150", ovn-encap-type=geneve, 
> ovn-remote="ssl:10.8.236.244:6642", 
> system-id="7c39d07b-1d54-417b-bf56-7a0f1a07f832"}
> iface_types : [geneve, gre, internal, lisp, patch, stt, system, tap, 
> vxlan]
> manager_options : []
> next_cfg: 1
> other_config: {}
> ovs_version : "2.7.3"
> ssl : []
> statistics  : {}
> system_type : centos
> system_version  : "7"
>
> I can see two addresses that are on the old network..

Yes, those are it.

Use the tool I mentioned to update that to the correct addresses on
the network, and re-try.

vdsm-tool ovn-config  

> Regards
> Carl
>
>
> On Wed, Jul 17, 2019 at 8:21 AM carl langlois  wrote:
>>
>> Hi Miguel,
>>
>> I will surely open a bugs, any specific ovirt componenent to select when 
>> openeing the bug?

ovirt-engine

>>
>> When you say that the hosted-engine should have trigger a the update. Do you 
>> mean is was suppose to trigger the update and did not work or it is 
>> something missing?

I sincerely do not know. @Dominik Holler, could you shed some light into this ?

>> Could i have missed a step when switching the network?
>>
>> Also if i try to do ovs-vsctl list . The list command require a Table name. 
>> Not sure what table to use?
>>
>> Regards
>> Carl
>>
>>
>>
>> On Wed, Jul 17, 2019 at 4:21 AM Miguel Duarte de Mora Barroso 
>>  wrote:
>>>
>>> On Tue, Jul 16, 2019 at 8:48 PM carl langlois  
>>> wrote:
>>> >
>>> > Hi
>>> >
>>> > We are in a process of changing our network connection. Our current 
>>> > network is using 10.8.256.x and we will change to 10.16.248.x. We have a 
>>> > HA ovirt cluster (around 10 nodes) currently configure on the 10.8.256.x. 
>>> > So my question is is it possible to relocate the ovirt cluster to the 
>>> > 10.16.248.x.  We have tried to move everything to the new network without 
>>> > success. All the node seem to boot up properly, our gluster storage also 
>>> > work properly.
>>> > When we try to start the hosted-engine it goes up but fail the liveliness 
>>> > check. We have notice in the /var/log/openvswitch/ovn-controller.log that 
>>> > he is triying to connect to the hold ip address of the hosted-engine vm.
>>> > 019-07-16T18:41:29.483Z|01992|reconnect|INFO|ssl:10.8.236.244:6642: 
>>> > waiting 8 seconds before reconnect
>>> > 2019-07-16T18:41:37.489Z|01993|reconnect|INFO|ssl:10.8.236.244:6642: 
>>> > connecting...
>>> > 2019-07-16T18:41:45.497Z|01994|reconnect|INFO|ssl:10.8.236.244:6642: 
>>> > connection attempt timed out
>>> >
>>> > So my question is were is the 10.8.236.244 come from.
>>>
>>> Looks like the ovn controllers were not updated during the network change.
>>>
>>> The wrong IP is configured within openvswitch, you can see it in the
>>> (offending) nodes through "ovs-vsctl list . ". It'll be a key in the
>>> 'external_ids' column called 'ovn-remote' .
>>>
>>> This is not the solution, but a work-around; you could try to
>>> configure the ovn controllers via:
>>> vdsm-tool ovn-config  
>>>
>>> Despite the provided work-around, I really think the hosted engine
>>> should have triggered the ansible role that in turn triggers this
>>> reconfiguration.
>>>
>>> Would you open a bug with this information ?
>>>
>>>
>>> >
>>> > The routing table for one of our host look like this
>>> >
>>> > estination Gateway Genmask Flags Metric RefUse 
>>> > Iface
>>> > default gateway 0.0.0.0 UG0  00 
>>> > ovirtmgmt
>>> > 10.16.248.0 0.0.0.0 255.255.255.0   U 0  00 
>>> > ovirtmgmt
>>> > link-local  0.0.0.0 255.255.0.0 U 1002   00 
>>> > eno1
&

[ovirt-users] Re: major network changes

2019-07-17 Thread Miguel Duarte de Mora Barroso
On Tue, Jul 16, 2019 at 8:48 PM carl langlois  wrote:
>
> Hi
>
> We are in a process of changing our network connection. Our current network 
> is using 10.8.256.x and we will change to 10.16.248.x. We have a HA ovirt 
> cluster (around 10 nodes) currently configure on the 10.8.256.x. So my 
> question is is it possible to relocate the ovirt cluster to the 10.16.248.x.  
> We have tried to move everything to the new network without success. All the 
> node seem to boot up properly, our gluster storage also work properly.
> When we try to start the hosted-engine it goes up but fail the liveliness 
> check. We have notice in the /var/log/openvswitch/ovn-controller.log that he 
> is triying to connect to the hold ip address of the hosted-engine vm.
> 019-07-16T18:41:29.483Z|01992|reconnect|INFO|ssl:10.8.236.244:6642: waiting 8 
> seconds before reconnect
> 2019-07-16T18:41:37.489Z|01993|reconnect|INFO|ssl:10.8.236.244:6642: 
> connecting...
> 2019-07-16T18:41:45.497Z|01994|reconnect|INFO|ssl:10.8.236.244:6642: 
> connection attempt timed out
>
> So my question is were is the 10.8.236.244 come from.

Looks like the ovn controllers were not updated during the network change.

The wrong IP is configured within openvswitch, you can see it in the
(offending) nodes through "ovs-vsctl list . ". It'll be a key in the
'external_ids' column called 'ovn-remote' .

This is not the solution, but a work-around; you could try to
configure the ovn controllers via:
vdsm-tool ovn-config  

Despite the provided work-around, I really think the hosted engine
should have triggered the ansible role that in turn triggers this
reconfiguration.

Would you open a bug with this information ?


>
> The routing table for one of our host look like this
>
> estination Gateway Genmask Flags Metric RefUse Iface
> default gateway 0.0.0.0 UG0  00 
> ovirtmgmt
> 10.16.248.0 0.0.0.0 255.255.255.0   U 0  00 
> ovirtmgmt
> link-local  0.0.0.0 255.255.0.0 U 1002   00 eno1
> link-local  0.0.0.0 255.255.0.0 U 1003   00 eno2
> link-local  0.0.0.0 255.255.0.0 U 1025   00 
> ovirtmgmt
>
> Any help would be really appreciated.
>
> Regards
> Carl
>
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/DBQUWEPPDK2JDFU4HOGNURK7AB3FDINC/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/YGT2TEE7PBVNLZGKN7TSF77K7V7A3H2R/


[ovirt-users] Re: How to fix ovn apparent inconsistency?

2019-04-15 Thread Miguel Duarte de Mora Barroso
Hi Gianluca,

First of, sorry for the late reply, been very busy this past week.

Regarding the lack of security group support on oVirt, I agree it's unfortunate.

Please take a look at this repo [0]; you'll find playbooks to update
the port's / networks port security, security groups, and a couple of
examples on how to create new security groups and rules via ansible.

You can follow the README, it features all the information you need to
install the requirements, and use the playbooks. Comments are welcome.

You can find answers to your questions inline.

[0] - https://github.com/maiqueb/ovirt-security-groups-demo/

On Fri, Apr 5, 2019 at 10:25 AM Gianluca Cecchi
 wrote:
>
> On Fri, Apr 5, 2019 at 9:56 AM Miguel Duarte de Mora Barroso 
>  wrote:
>>
>>
>>
>> Mind sharing the created ACLs ? (which I'm quite positive will be the
>> default ones, but I just have to be sure). Can be done via "ovn-nbctl
>> list acl" . With that I can check the ACLs assigned to the default
>> group, and assure they are correct.
>>
>
> The question is: previous networks (in the sense of already existing before 
> the port security feature had been introduced in 4.3) seems inherited the 
> "Enabled" option and this prevents communication between VMs on the same OVN 
> network.
> Is this expected?

Previous networks are unchanged; nothing updates any of those during
the upgrade.

Now, newly created ports on existing networks *will* inherit the value
from the configuration - since the network itself doesn't have the
port security attribute set.

Can you share what's the current port-security-enabled value on your
configuration ?
(/etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf)

> Otherwise other people in 4.2 using OVN will have the same problem migrating 
> to 4.3
> If I create now n 4.3.2 a new OVN based network, if I select "Create an 
> external provider", I get as default "ovirt-provider-ovn" as External 
> Provider and "Enabled" as Network Port Security. Is this expected?

Yes.

> Is it expected that a new OVN network with default values (Enabled port 
> security) is made so that by default 2 VMs don't communicate if I don't set a 
> special security group rule (that in tis moment requires REST api)?

No, the exact purpose of the default group is for the VMs to
communicate out of the box.

The ACLs you provide match all the ACLs present on the port groups
you've previously shared, and ; from my perspective, your VMs should
be able to communicate.

Could you share the output of 'ovs-ofctl dump-flows br-int' on the
ovirt node where your VMs are located ? That could indicate why the
packets are being dropped. Please provide that in a pastebin (this
email is already hard to follow).

A further question: your cluster switch type is ovs, right? This would
only matter if your VMs run in different nodes, but hey, best to get
that sorted out early.

Lastly, are your VMs able to receive an IP address via dhcp ?






>
> As far as ACLs currently in place are concerned, here they are for my current 
> environment.
>
> [root@ovmgr1 ~]# ovn-nbctl list acl
> _uuid   : 239f0fa4-a66e-4cce-8df2-05630f11e052
> action  : drop
> direction   : to-lport
> external_ids: {description="drop all ingress ip traffic", 
> ovirt_port_group_id="79d3d3a0-7a57-4903-8646-f678ea53aeca"}
> log : false
> match   : "outport == @DropAll && ip"
> meter   : []
> name: ""
> priority: 1000
> severity: alert
>
> _uuid   : 141aa336-0549-47d0-b09f-c2cb0dd78dd2
> action  : allow-related
> direction   : from-lport
> external_ids: {description="automatically added allow all egress ip 
> traffic", ovirt_ethertype="IPv4", 
> ovirt_port_group_id="1fd8cacf-35cf-4aa3-b245-fec9c2e6e616"}
> log : false
> match   : "inport == @Default && ip4"
> meter   : []
> name: ""
> priority: 1001
> severity: alert
>
> _uuid   : ac7d5a16-a596-43dc-88ec-e9d47512e7ce
> action  : drop
> direction   : from-lport
> external_ids: {description="drop all egress ip traffic", 
> ovirt_port_group_id="79d3d3a0-7a57-4903-8646-f678ea53aeca"}
> log : false
> match   : "inport == @DropAll && ip"
> meter   : []
> name: ""
> priority: 1000
> severity: alert
>
> _uuid   : ef7f32f2-8b78-433f-a831-0e801c9d8

[ovirt-users] Re: How to fix ovn apparent inconsistency?

2019-04-05 Thread Miguel Duarte de Mora Barroso
On Thu, Apr 4, 2019 at 2:04 PM Gianluca Cecchi
 wrote:
>
> On Thu, Apr 4, 2019 at 12:07 PM Miguel Duarte de Mora Barroso 
>  wrote:
>>
>>
>> > Questions:
>> > - what is the role of the "Network port security" option for an OVN 
>> > network?
>>
>> It means that newly created ports under that network will inherit the
>> port security value from the network - e.g. if the network's port
>> security attribute is active, so will the newly created port's port
>> security.
>>
>> Port security on a port means 2 things:
>>   #1 - security group rules *will* apply to the VM having that port attached
>>   #2 - only the specified mac address will be allowed to send/receive
>> through that port. MAC spoofing protection is applied.
>>
>> > - what is the meaning of "Undefined" option for it other than "Enabled" 
>> > and "Disabled"?
>>
>> It means that the network will inherit the value from the provider's
>> configuration - you can check what it translates to in
>> /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
>
>
> Thanks for clarifications. Digging around RHV 4.2 vs 4.3beta docs I see now 
> that "Network Port Security" will be also one of the new features for it
> In 4.3 beta the third option is explictly defined as "Inherited" (reflecting 
> your explanation) and not "Undefined" as in current oVirt 4.3.2)
>
>>
>>
>> > - it seems I cannot edit the value for "Network port security" option of 
>> > an existing OVN network, is it correct?
>>
>> You cannot do it *through the UI*. You can use ansible / REST api to
>> update the network - or ports - port_security_enabled value.
>
>
>
>>
>>
>> I am working on creating a couple of playbooks for this; hopefully I
>> can provide those early next week. It would be helpful to agilize this
>> process.
>>
>
> Indeed. Because in Openstack web mgmt interface all the settings related to 
> security groups are simplified and intuitive, but here we have not...
> Also because it seems from rhv 4.3beta manual that creation of security 
> groups themselves will not be possible through web gui...
>
>>
>> There is a notion of 'default' group, that ensures connectivity to all
>> VMs whose ports belong to that group - and all ports with active port
>> security, by default do.
>>
>> I'm not sure how you reached that situation, but let's first make sure
>> of a couple of things; please provider the output of:
>>   - ovn-nbctl list logical_switch_port # this will feature info of the
>> port security value, and of which groups the port belongs to - the
>> latter in the 'external_ids' column.
>>   - ovn-nbctl list port_group # this is where the security groups are
>> stored; it has associations to the ACLs belonging to the group, and of
>> the ports that are using it
>>   - ovn-nbctl list address_set # this is where the IPs per group are
>> stored. security groups are an L3 concept.
>>
>> A pastebin with the aforementioned info is welcome.
>
>
> See here:
> https://drive.google.com/file/d/1hgXMGttMgb0oaDEy5k6aWFdb01dYsjwq/view?usp=sharing

From the data you supply, everything looks as is should: both the
ports are members of the default port group, and both their IPs are
featured in the ip4 address set.

Mind sharing the created ACLs ? (which I'm quite positive will be the
default ones, but I just have to be sure). Can be done via "ovn-nbctl
list acl" . With that I can check the ACLs assigned to the default
group, and assure they are correct.




>
> Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/MLBMI2GVJPFJKCT52AQLIOGUOP3HLMGN/


[ovirt-users] Re: How to fix ovn apparent inconsistency?

2019-04-04 Thread Miguel Duarte de Mora Barroso
On Thu, Apr 4, 2019 at 11:27 AM Gianluca Cecchi
 wrote:
>
> On Sat, Mar 23, 2019 at 7:44 PM Dominik Holler  wrote:
>
> Sorry for late reply Dominik busy on other (interesting at least ;-) 
> things
>>
>>
>> > I have to dig a bit more, because from first tests if I start another VM on
>> > the same ovn192 network also on the same host they are not able to
>> > communicate
>> > Possibly an iptables misconfiguration on host?
>> >
>>
>> Just to understand the error, would you please check if
>> /var/log/openvswitch/ovn-controller.log
>> or any other logfile in the same directory contains any hints?
>>
>
> It seems not
>
>>
>> Would communication using a new created ovn network without port
>> security enabled work?
>
>
> I confirm that if I create a new ovn with security port "Disabled" the VMs 
> can communicate both when running on the same host and on hosts even in 
> different datacenters ;-)
> I unplug vnic / change ovn network of vms to match the new one / plug vnics 
> again and they communicate.
> I unplug vnic / change ovn network of vms to the old one with port securty 
> enabled / plug vnics again and they don't communicate.
>
> Questions:
> - what is the role of the "Network port security" option for an OVN network?

It means that newly created ports under that network will inherit the
port security value from the network - e.g. if the network's port
security attribute is active, so will the newly created port's port
security.

Port security on a port means 2 things:
  #1 - security group rules *will* apply to the VM having that port attached
  #2 - only the specified mac address will be allowed to send/receive
through that port. MAC spoofing protection is applied.

> - what is the meaning of "Undefined" option for it other than "Enabled" and 
> "Disabled"?

It means that the network will inherit the value from the provider's
configuration - you can check what it translates to in
/etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf

> - it seems I cannot edit the value for "Network port security" option of an 
> existing OVN network, is it correct?

You cannot do it *through the UI*. You can use ansible / REST api to
update the network - or ports - port_security_enabled value.

I am working on creating a couple of playbooks for this; hopefully I
can provide those early next week. It would be helpful to agilize this
process.

>
> Thanks again,
> Gianluca
>

There is a notion of 'default' group, that ensures connectivity to all
VMs whose ports belong to that group - and all ports with active port
security, by default do.

I'm not sure how you reached that situation, but let's first make sure
of a couple of things; please provider the output of:
  - ovn-nbctl list logical_switch_port # this will feature info of the
port security value, and of which groups the port belongs to - the
latter in the 'external_ids' column.
  - ovn-nbctl list port_group # this is where the security groups are
stored; it has associations to the ACLs belonging to the group, and of
the ports that are using it
  - ovn-nbctl list address_set # this is where the IPs per group are
stored. security groups are an L3 concept.

A pastebin with the aforementioned info is welcome.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/PAPRJWY7D2A3Z7TM5OCUNIDK7SE3XOT4/


[ovirt-users] Re: How to fix ovn apparent inconsistency?

2019-03-21 Thread Miguel Duarte de Mora Barroso
On Thu, Mar 21, 2019 at 9:31 AM Gianluca Cecchi
 wrote:
>
>
>
> On Wed, Mar 20, 2019 at 2:09 PM Gianluca Cecchi  
> wrote:
>>
>> On Wed, Mar 20, 2019 at 1:26 PM Marcin Mirecki  wrote:
>>>
>>> Looking at the original state we had:
>>> switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192)
>>> switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192)
>>> switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172)
>>> switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172)
>>>
>>> In the output of GET, 6110649a-db2b-4de7-8fbc-601095cfe510 is not longer 
>>> there, so it has been deleted.
>>> Did you maybe try to submit the request twice?
>>
>>
>> With that switch, as it had no ports attached, I tried the command line 
>> option with:
>>  ovn-nbctl destroy logical_switch 6110649a-db2b-4de7-8fbc-601095cfe510
>>
>>
>>
>>>
>>>
>>> About  8fd63a10-a2ba-4c56-a8e0-0bc8d70be8b5. There was never a network with 
>>> that id, so this is correct.
>>
>>
>> Yes, but that was the id provided by web admin gui for the network
>> - ovn192
>> Id: 8fd63a10-a2ba-4c56-a8e0-0bc8d70be8b5
>> External ID: 32367d8a-460f-4447-b35a-abe9ea5187e0
>>
>> or did I misunderstood?
>>
>>
>>>
>>>
>>> Also note that to delete a network you will first have to delete its ports.
>>
>>
>> OK.
>> Is there a command to clean all so that I can restart with a new OVN setup 
>> in this infra?
>> I think I messed up too many things on it
>>
>> Thanks,
>> Gianluca
>>
>
>
> I have deleted provider from web admin gui and then on manager from command 
> line:
>
> ovn-nbctl lsp-del 
> for the ports defined and then
> ovn-nbctl destroy logical_switch 
> for the defined switches.
>
> Then reboot of manager.
>
> Now I have on it:
> [root@ovmgr1 ~]# ovs-vsctl show
> eae54ff9-b86c-4050-8241-46f44336ba94
> ovs_version: "2.10.1"
> [root@ovmgr1 ~]#
>
> [root@ovmgr1 ~]# ovn-nbctl show
> [root@ovmgr1 ~]#
>
> and no provider and/or networks on OVN in web admin gui.
>
> What could be the sequence to re-add an OVN provider now?
> From engine-setup or from web admin gui?

Through engine UI, through "Administration" -> "Providers" -> Add

> Any quick tip for? Any other commands (eg at db level) to verify all previous 
> config is cleaned?

+Ales Musil could you indicate how to check the network list on the
engine's DB ? A query to filter all the external networks is what
we're after.

> Thanks
> Gianluca
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/P3OGISMQBLF6YCZKPDU46B7PKWKTDOQN/


[ovirt-users] Re: How to fix ovn apparent inconsistency?

2019-03-19 Thread Miguel Duarte de Mora Barroso
On Tue, Mar 19, 2019 at 3:09 PM Gianluca Cecchi
 wrote:
>
>
>
> On Tue, Mar 19, 2019 at 2:51 PM Miguel Duarte de Mora Barroso 
>  wrote:
>>
>> On Tue, Mar 19, 2019 at 2:15 PM Gianluca Cecchi
>>  wrote:
>> >
>> > On Tue, Mar 19, 2019 at 10:25 AM Miguel Duarte de Mora Barroso 
>> >  wrote:
>> >>
>> >> >>
>> >> >>
>> >> >> @Gianluca Cecchi , I notice that one of your duplicate networks -
>> >> >> 'ovn192'  - has no ports attached. That makes it the perfect candidate
>> >> >> to be deleted, and see if it becomes 'listable' on engine. That would
>> >> >> help rule out the 'duplicate name' theory.
>> >> >
>> >> >
>> >> >  I can try. Can you give me the command to be run?
>> >> > It is a test oVirt so It would be not a big problem in case of failures 
>> >> > in this respect.
>> >>
>> >> You can delete it via the UI; just be sure to delete the one without
>> >> ports - it's external ID is 6110649a-db2b-4de7-8fbc-601095cfe510.
>> >>
>> >> It will ask you if you also want to delete it from the external
>> >> provider, say yes.
>> >
>> >
>> >
>> > Inside the GUI I see only one ovn192 network and one ovn172 network and 
>> > their external ids don't match the ones without ports...
>> >
>> > - ovn192
>> > Id: 8fd63a10-a2ba-4c56-a8e0-0bc8d70be8b5
>> > External ID: 32367d8a-460f-4447-b35a-abe9ea5187e0
>> >
>> > - ovn172
>> > Id: 7546d5d3-a0e3-40d5-9d22-cf355da47d3a
>> > External ID: 64c4c17f-cd67-4e29-939e-2b952495159f
>> >
>> > So I think I have to delete from command line
>>
>> Check pastebin [0],  with it you can safely delete those 2 networks.
>> Last course of action would be to delete via ovn-nbctl - e.g.
>> ovn-nbctl destroy logical_switch  - but hopefully it won't
>> come to that.
>>
>> [0] - https://paste.fedoraproject.org/paste/mxVUEJZWxG-QHX0mJO1VhA
>>
>> >
>> > Gianluca Cecchi
>> >
>
>
>
> I get this error from the first part where I should get  the token id
> {
>   "error": {
> "message": "No JSON object could be decoded",
> "code": 400,
> "title": "Bad Request"
>   }
> }
>
> In your command there is:
>
>   -H 'Postman-Token: 87fa50fd-0d06-497d-b2ac-b66b78ad90b8' \

Remove that, sorry for not noticing it before. Also get rid of the
'Cache-Control: no-cache' header.

The request thus becomes:
curl -k -X POST \
  https://localhost:35357/v2.0/tokens \
  -H 'Content-Type: application/json' \
  -d '{
"auth": {
"passwordCredentials": {
"username": ,
"password": 
}
}
}
'

>
> what is that sequence? where did you get it?
> Also, inside the credential section
>
> "username": ,
> "password": YYY
>
> do I have to put my username and password inside single/double quotes or 
> nothing?
> eg admin@internal or "admin@internal" or what?
>

Between quotes - e.g. "admin@internal" and "whatever-password-you-have".

> Thanks,
> Gianluca
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/IBMCNPUMP25FMLLHREJPOAOOFSYWARQB/


[ovirt-users] Re: How to fix ovn apparent inconsistency?

2019-03-19 Thread Miguel Duarte de Mora Barroso
On Tue, Mar 19, 2019 at 2:15 PM Gianluca Cecchi
 wrote:
>
> On Tue, Mar 19, 2019 at 10:25 AM Miguel Duarte de Mora Barroso 
>  wrote:
>>
>> >>
>> >>
>> >> @Gianluca Cecchi , I notice that one of your duplicate networks -
>> >> 'ovn192'  - has no ports attached. That makes it the perfect candidate
>> >> to be deleted, and see if it becomes 'listable' on engine. That would
>> >> help rule out the 'duplicate name' theory.
>> >
>> >
>> >  I can try. Can you give me the command to be run?
>> > It is a test oVirt so It would be not a big problem in case of failures in 
>> > this respect.
>>
>> You can delete it via the UI; just be sure to delete the one without
>> ports - it's external ID is 6110649a-db2b-4de7-8fbc-601095cfe510.
>>
>> It will ask you if you also want to delete it from the external
>> provider, say yes.
>
>
>
> Inside the GUI I see only one ovn192 network and one ovn172 network and their 
> external ids don't match the ones without ports...
>
> - ovn192
> Id: 8fd63a10-a2ba-4c56-a8e0-0bc8d70be8b5
> External ID: 32367d8a-460f-4447-b35a-abe9ea5187e0
>
> - ovn172
> Id: 7546d5d3-a0e3-40d5-9d22-cf355da47d3a
> External ID: 64c4c17f-cd67-4e29-939e-2b952495159f
>
> So I think I have to delete from command line

Check pastebin [0],  with it you can safely delete those 2 networks.
Last course of action would be to delete via ovn-nbctl - e.g.
ovn-nbctl destroy logical_switch  - but hopefully it won't
come to that.

[0] - https://paste.fedoraproject.org/paste/mxVUEJZWxG-QHX0mJO1VhA

>
> Gianluca Cecchi
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/IKKBNNW5KLNBBHH2AFWYRYW3NVIJP3QJ/


[ovirt-users] Re: How to fix ovn apparent inconsistency?

2019-03-19 Thread Miguel Duarte de Mora Barroso
On Mon, Mar 18, 2019 at 5:08 PM Gianluca Cecchi
 wrote:
>
> On Mon, Mar 18, 2019 at 4:40 PM Miguel Duarte de Mora Barroso 
>  wrote:
>>
>> On Mon, Mar 18, 2019 at 2:20 PM Gianluca Cecchi
>>  wrote:
>> >
>> > Hello,
>> > passing from old manual to current OVN in 4.3.1 it seems I have some 
>> > problems with OVN now.
>> > I cannot assign network on OVN to VM (powered on or off doesn't change).
>> > When I add//edit a vnic, they are not on the possible choices
>> > Environment composed by three hosts and one engine (external on vSphere).
>> > The mgmt network during time has been configured on network named 
>> > ovirtmgmntZ2Z3
>> > On engine it seems there are 2 switches for every defined ovn network 
>> > (ovn192 and ovn172)
>> > Below some output of commands in case any inconsistency has remained and I 
>> > can purge it.
>> > Thanks in advance.
>> >
>>
>> I'm very confused here; you mention that on engine there are 2
>> switches for every ovn network, but, on your ovn-nbctl list
>> logical_switch output I can clearly see the 2 logical switches where
>> the OVN logical networks are stored. Who created those ?
>
>
> I think it could be related to the situation described here (it is the same 
> environment, in the meantime updated also from 4.2.8 to 4.3.1) and previous 
> configuration not backed up at that time:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/32S5L4JKHGPHE2XIQMLRIVLOXRG4CHW3/
>
> and some steps not done correctly by me.
> After following indications, I tried to import ovn but probably I did it 
> wrong.
>
>>
>>
>> Could you show us the properties of those 2 networks ? (e.g. ovn-nbctl
>> list logical_switch 32367d8a-460f-4447-b35a-abe9ea5187e0 & ovn-nbctl
>> list logical_switch 64c4c17f-cd67-4e29-939e-2b952495159f)
>>
>
> [root@ovmgr1 ~]# ovn-nbctl list logical_switch 
> 32367d8a-460f-4447-b35a-abe9ea5187e0
> _uuid   : 32367d8a-460f-4447-b35a-abe9ea5187e0
> acls: []
> dns_records : []
> external_ids: {}
> load_balancer   : []
> name: "ovn192"
> other_config: {subnet="192.168.10.0/24"}
> ports   : [affc5570-3e5a-439c-9fdf-d75d6810e3a3, 
> f639d541-2118-4c24-b478-b7a586eb170c]
> qos_rules   : []
> [root@ovmgr1 ~]#
>
> [root@ovmgr1 ~]# ovn-nbctl list logical_switch 
> 64c4c17f-cd67-4e29-939e-2b952495159f
> _uuid   : 64c4c17f-cd67-4e29-939e-2b952495159f
> acls: []
> dns_records : []
> external_ids: {}
> load_balancer   : []
> name: "ovn172"
> other_config: {subnet="172.16.10.0/24"}
> ports   : [32c348d9-12e9-4bcf-a43f-69338c887cfc, 
> 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69]
> qos_rules   : []
> [root@ovmgr1 ~]#
>
>
>>
>>
>> @Gianluca Cecchi , I notice that one of your duplicate networks -
>> 'ovn192'  - has no ports attached. That makes it the perfect candidate
>> to be deleted, and see if it becomes 'listable' on engine. That would
>> help rule out the 'duplicate name' theory.
>
>
>  I can try. Can you give me the command to be run?
> It is a test oVirt so It would be not a big problem in case of failures in 
> this respect.

You can delete it via the UI; just be sure to delete the one without
ports - it's external ID is 6110649a-db2b-4de7-8fbc-601095cfe510.

It will ask you if you also want to delete it from the external
provider, say yes.



>
>>
>> At the moment, I can't think of a better alternative. Let's see if
>> Marcin comes up with a better test / idea / alternative.
>>
>> Also, please let us know the version of the ovirt-provider-ovn,
>> openvswitch-ovn-central, and openvswitch-ovn-host.
>
>
> On engine:
> [root@ovmgr1 ~]# rpm -q ovirt-provider-ovn openvswitch-ovn-central 
> openvswitch-ovn-host
> ovirt-provider-ovn-1.2.20-1.el7.noarch
> openvswitch-ovn-central-2.10.1-3.el7.x86_64
> package openvswitch-ovn-host is not installed
> [root@ovmgr1 ~]#
>
> On the 3 hosts I only have this package installed:
> openvswitch-ovn-host-2.10.1-3.el7.x86_64
>
>  Thanks
> Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/HPASIKY52XE7LPRYDQBKGTCHADP35YRS/


[ovirt-users] Re: How to fix ovn apparent inconsistency?

2019-03-18 Thread Miguel Duarte de Mora Barroso
On Mon, Mar 18, 2019 at 2:20 PM Gianluca Cecchi
 wrote:
>
> Hello,
> passing from old manual to current OVN in 4.3.1 it seems I have some problems 
> with OVN now.
> I cannot assign network on OVN to VM (powered on or off doesn't change).
> When I add//edit a vnic, they are not on the possible choices
> Environment composed by three hosts and one engine (external on vSphere).
> The mgmt network during time has been configured on network named 
> ovirtmgmntZ2Z3
> On engine it seems there are 2 switches for every defined ovn network (ovn192 
> and ovn172)
> Below some output of commands in case any inconsistency has remained and I 
> can purge it.
> Thanks in advance.
>

I'm very confused here; you mention that on engine there are 2
switches for every ovn network, but, on your ovn-nbctl list
logical_switch output I can clearly see the 2 logical switches where
the OVN logical networks are stored. Who created those ?

Could you show us the properties of those 2 networks ? (e.g. ovn-nbctl
list logical_switch 32367d8a-460f-4447-b35a-abe9ea5187e0 & ovn-nbctl
list logical_switch 64c4c17f-cd67-4e29-939e-2b952495159f)

+Marcin Mirecki  does this ring a bell? AFAIU, the ovn network names
had to be unique - until bug [0] was fixed, where the network names
would have a whole different format - e.g.
ovirt--  .

@Gianluca Cecchi , I notice that one of your duplicate networks -
'ovn192'  - has no ports attached. That makes it the perfect candidate
to be deleted, and see if it becomes 'listable' on engine. That would
help rule out the 'duplicate name' theory.

At the moment, I can't think of a better alternative. Let's see if
Marcin comes up with a better test / idea / alternative.

Also, please let us know the version of the ovirt-provider-ovn,
openvswitch-ovn-central, and openvswitch-ovn-host.

[0] - https://bugzilla.redhat.com/show_bug.cgi?id=1503577

> Gianluca
>
> - On manager ovmgr1:
>
> [root@ovmgr1 ~]# ovs-vsctl show
> eae54ff9-b86c-4050-8241-46f44336ba94
> ovs_version: "2.10.1"
> [root@ovmgr1 ~]#
>
> [root@ovmgr1 ~]# ovn-nbctl show
> switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192)
> port affc5570-3e5a-439c-9fdf-d75d6810e3a3
> addresses: ["00:1a:4a:17:01:73"]
> port f639d541-2118-4c24-b478-b7a586eb170c
> addresses: ["00:1a:4a:17:01:75"]
> switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192)
> switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172)
> port 32c348d9-12e9-4bcf-a43f-69338c887cfc
> addresses: ["00:1a:4a:17:01:72 dynamic"]
> port 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69
> addresses: ["00:1a:4a:17:01:74 dynamic"]
> switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172)
> port 0a2a47bc-ea0d-4f1d-8f49-ec903e519983
> addresses: ["00:1a:4a:17:01:65 dynamic"]
> port 8fc7bed4-7663-4903-922b-05e490c6a5a1
> addresses: ["00:1a:4a:17:01:64 dynamic"]
> port f2b64f89-b719-484c-ac02-2a1ac8eaacdb
> addresses: ["00:1a:4a:17:01:59 dynamic"]
> port f7389c88-1ea1-47c2-92fd-6beffb2e2190
> addresses: ["00:1a:4a:17:01:58 dynamic"]
> [root@ovmgr1 ~]#
>
> - On host ov200 (10.4.192.32 on ovirtmgmntZ2Z3):
> [root@ov200 ~]# ovs-vsctl show
> ae0a1256-7250-46a2-a1b6-8f0ae6105c20
> Bridge br-int
> fail_mode: secure
> Port br-int
> Interface br-int
> type: internal
> Port "ovn-ddecf0-0"
> Interface "ovn-ddecf0-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.33"}
> Port "ovn-b8872a-0"
> Interface "ovn-b8872a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.34"}
> ovs_version: "2.10.1"
> [root@ov200 ~]#
>
> - On host ov300 (10.4.192.33 on ovirtmgmntZ2Z3):
>
> [root@ov300 ~]# ovs-vsctl show
> f1a41e9c-16fb-4aa2-a386-2f366ade4d3c
> Bridge br-int
> fail_mode: secure
> Port br-int
> Interface br-int
> type: internal
> Port "ovn-b8872a-0"
> Interface "ovn-b8872a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.34"}
> Port "ovn-1dce5b-0"
> Interface "ovn-1dce5b-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.32"}
> ovs_version: "2.10.1"
> [root@ov300 ~]#
>
> - On host ov301 (10.4.192.34 on ovirtmgmntZ2Z3):
> [root@ov301 ~]# ovs-vsctl show
> 3a38c5bb-0abf-493d-a2e6-345af8aedfe3
> Bridge br-int
> fail_mode: secure
> Port "ovn-1dce5b-0"
> Interface "ovn-1dce5b-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.32"}
> Port "ovn-ddecf0-0"
> Interface "ovn-ddecf0-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.33"}
> Port br-int
> Interface br-int
> type: 

[ovirt-users] Re: ovn-provider-network

2019-03-18 Thread Miguel Duarte de Mora Barroso
On Fri, Mar 15, 2019 at 6:11 PM Staniforth, Paul
 wrote:
>
> I've now got the second host working, the directory /etc/openvswitch/ was 
> owned by root instead of openvswitch:openvswitch

Nice to know you've got it working.

Thanks for getting back to us.

>
>
> Thanks,
>Paul S.
> To view the terms under which this email is distributed, please go to:-
> http://leedsbeckett.ac.uk/disclaimer/email/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/Q4CP55BRQZNOVHOMHJ32EWXECTLWUOUN/


[ovirt-users] Re: ovn-provider-network

2019-03-15 Thread Miguel Duarte de Mora Barroso
On Fri, Mar 15, 2019 at 5:15 PM Miguel Duarte de Mora Barroso
 wrote:
>
> On Fri, Mar 15, 2019 at 3:49 PM Staniforth, Paul
>  wrote:
> >
> > Thanks,
> >   I can see now from "ovn-sbctl show" on the engine machine  
> > that 2 of our hosts haven't  deployed ovn
> >
> > ● ovn-controller.service - OVN controller daemon
> >Loaded: loaded (/usr/lib/systemd/system/ovn-controller.service; 
> > disabled; vendor preset: disabled)
> >Active: inactive (dead)
> > This was one of the things that was confusing me
> >
> > I'll see if I can deploy ovn without reinstalling, also is it possible to 
> > change the deployment to use a different network rather than ovirtmgmt?
>
> You could use vdsm-tool to reconfigure OVN on the hosts.
>
> Please try this:
>
> vdsm-tool ovn-config  ovirtmgmt
>
> If you want to setup your overlay on top of a different network,
> replace ovirtmgmt with that network name.
>
> To ensure connectivity accross the cluster, make sure all your hosts
> are configured to run overlays on top *of the same network*.
>
> Make sure that other network is good to go before; I'd hate for you to
> end up worse than you are now, or lose faith on ovn :)

I think I wasn't adamant enough here; please try to get OVN controller
configure using ovirtmgmt network before.

If that works as expected, you can later on evaluate if setting the
overlay on top of a different network is beneficial.

>
>
>
>
>
>
>
> >
> > Regards,
> > Paul S.
> > 
> > From: Miguel Duarte de Mora Barroso 
> > Sent: 15 March 2019 11:28
> > To: Staniforth, Paul
> > Cc: users@ovirt.org
> > Subject: Re: [ovirt-users] ovn-provider-network
> >
> > On Thu, Mar 14, 2019 at 3:04 PM Staniforth, Paul
> >  wrote:
> > >
> > > Thanks Miguel,
> > >  if we configure it connect to a physical network 
> > > and select the Data Centre Network  I assume it will create the overlay 
> > > network on top of that logical network.
> >
> > Let me clarify; the network on top of which it sets up the overlay is
> > defined when the host is added, and is *only* used for inter-host
> > communication. When within the same host, it simply uses the OVS
> > bridge.
> >
> > What (I think) you mean uses the localnet feature of OVN, where the
> > packets leaving the OVS bridge are forwarded to the external logical
> > network you configure.
> >
> > These 2 concepts are unrelated.
> >
> >
> > > Also is there any documentation about the ovn-provider-network 
> > > architecture.
> > >
> > > Regards,
> > > Paul S.
> > > 
> > > From: Miguel Duarte de Mora Barroso 
> > > Sent: 14 March 2019 13:15
> > > To: Staniforth, Paul
> > > Cc: users@ovirt.org
> > > Subject: Re: [ovirt-users] ovn-provider-network
> > >
> > > On Wed, Mar 13, 2019 at 10:08 PM Staniforth, Paul
> > >  wrote:
> > > >
> > > > Hello,
> > > >
> > > >   we are using oVirt-4.2.8 and I have created a logical 
> > > > network using the ovn-network-provider, I haven't configured it to 
> > > > connect to a physical network.
> > > >
> > > >
> > > > I have 2 VMs running on 2 hosts which can connect to each other this 
> > > > logical network. The only connection between the hosts is over the 
> > > > ovirtmgmt network so presumably the traffic is using this?
> > >
> > > Yes, OVN sets up an overlay network on top of ovirtmgmt network.
> > >
> > > >
> > > >
> > > > Thanks,
> > > >
> > > >Paul S.
> > > >
> > > > To view the terms under which this email is distributed, please go to:-
> > > > http://leedsbeckett.ac.uk/disclaimer/email/
> > > >
> > > > ___
> > > > Users mailing list -- users@ovirt.org
> > > > To unsubscribe send an email to users-le...@ovirt.org
> > > > Privacy Statement: 
> > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fsite%2Fprivacy-policy%2Fdata=02%7C01%7CP.Staniforth%40leedsbeckett.ac.uk%7Cc1a89b8a39764e42ed5a08d6a9395111%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C636882460976049145sdata=7Fn7bcDC1yOgjfKewdHjExwScVuw03joXYKx16G%2BMOM%3Dreserved=0
> > 

[ovirt-users] Re: ovn-provider-network

2019-03-15 Thread Miguel Duarte de Mora Barroso
On Fri, Mar 15, 2019 at 3:49 PM Staniforth, Paul
 wrote:
>
> Thanks,
>   I can see now from "ovn-sbctl show" on the engine machine  that 
> 2 of our hosts haven't  deployed ovn
>
> ● ovn-controller.service - OVN controller daemon
>Loaded: loaded (/usr/lib/systemd/system/ovn-controller.service; disabled; 
> vendor preset: disabled)
>Active: inactive (dead)
> This was one of the things that was confusing me
>
> I'll see if I can deploy ovn without reinstalling, also is it possible to 
> change the deployment to use a different network rather than ovirtmgmt?

You could use vdsm-tool to reconfigure OVN on the hosts.

Please try this:

vdsm-tool ovn-config  ovirtmgmt

If you want to setup your overlay on top of a different network,
replace ovirtmgmt with that network name.

To ensure connectivity accross the cluster, make sure all your hosts
are configured to run overlays on top *of the same network*.

Make sure that other network is good to go before; I'd hate for you to
end up worse than you are now, or lose faith on ovn :)







>
> Regards,
> Paul S.
> ____________
> From: Miguel Duarte de Mora Barroso 
> Sent: 15 March 2019 11:28
> To: Staniforth, Paul
> Cc: users@ovirt.org
> Subject: Re: [ovirt-users] ovn-provider-network
>
> On Thu, Mar 14, 2019 at 3:04 PM Staniforth, Paul
>  wrote:
> >
> > Thanks Miguel,
> >  if we configure it connect to a physical network 
> > and select the Data Centre Network  I assume it will create the overlay 
> > network on top of that logical network.
>
> Let me clarify; the network on top of which it sets up the overlay is
> defined when the host is added, and is *only* used for inter-host
> communication. When within the same host, it simply uses the OVS
> bridge.
>
> What (I think) you mean uses the localnet feature of OVN, where the
> packets leaving the OVS bridge are forwarded to the external logical
> network you configure.
>
> These 2 concepts are unrelated.
>
>
> > Also is there any documentation about the ovn-provider-network architecture.
> >
> > Regards,
> > Paul S.
> > 
> > From: Miguel Duarte de Mora Barroso 
> > Sent: 14 March 2019 13:15
> > To: Staniforth, Paul
> > Cc: users@ovirt.org
> > Subject: Re: [ovirt-users] ovn-provider-network
> >
> > On Wed, Mar 13, 2019 at 10:08 PM Staniforth, Paul
> >  wrote:
> > >
> > > Hello,
> > >
> > >   we are using oVirt-4.2.8 and I have created a logical 
> > > network using the ovn-network-provider, I haven't configured it to 
> > > connect to a physical network.
> > >
> > >
> > > I have 2 VMs running on 2 hosts which can connect to each other this 
> > > logical network. The only connection between the hosts is over the 
> > > ovirtmgmt network so presumably the traffic is using this?
> >
> > Yes, OVN sets up an overlay network on top of ovirtmgmt network.
> >
> > >
> > >
> > > Thanks,
> > >
> > >Paul S.
> > >
> > > To view the terms under which this email is distributed, please go to:-
> > > http://leedsbeckett.ac.uk/disclaimer/email/
> > >
> > > ___
> > > Users mailing list -- users@ovirt.org
> > > To unsubscribe send an email to users-le...@ovirt.org
> > > Privacy Statement: 
> > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fsite%2Fprivacy-policy%2Fdata=02%7C01%7CP.Staniforth%40leedsbeckett.ac.uk%7Cc1a89b8a39764e42ed5a08d6a9395111%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C636882460976049145sdata=7Fn7bcDC1yOgjfKewdHjExwScVuw03joXYKx16G%2BMOM%3Dreserved=0
> > > oVirt Code of Conduct: 
> > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2Fdata=02%7C01%7CP.Staniforth%40leedsbeckett.ac.uk%7Cc1a89b8a39764e42ed5a08d6a9395111%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C636882460976049145sdata=rUqtChv%2FOG7HHS8gySIpHsh3s9VrqO2GzrdTO08DL4Q%3Dreserved=0
> > > List Archives: 
> > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2FB22LIMO6RI4SBYAOVDRWPQX3UUUYTUGL%2Fdata=02%7C01%7CP.Staniforth%40leedsbeckett.ac.uk%7Cc1a89b8a39764e42ed5a08d6a9395111%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C636882460976049145sdata=FtjV4dRfhlnZaJ2syoBcOCT8Nx9yS1UNjkBuX9aru0s%3Dreserved=0
> > To view the terms under which 

[ovirt-users] Re: ovn-provider-network

2019-03-15 Thread Miguel Duarte de Mora Barroso
On Thu, Mar 14, 2019 at 3:04 PM Staniforth, Paul
 wrote:
>
> Thanks Miguel,
>  if we configure it connect to a physical network and 
> select the Data Centre Network  I assume it will create the overlay network 
> on top of that logical network.

Let me clarify; the network on top of which it sets up the overlay is
defined when the host is added, and is *only* used for inter-host
communication. When within the same host, it simply uses the OVS
bridge.

What (I think) you mean uses the localnet feature of OVN, where the
packets leaving the OVS bridge are forwarded to the external logical
network you configure.

These 2 concepts are unrelated.


> Also is there any documentation about the ovn-provider-network architecture.
>
> Regards,
> Paul S.
> ____________
> From: Miguel Duarte de Mora Barroso 
> Sent: 14 March 2019 13:15
> To: Staniforth, Paul
> Cc: users@ovirt.org
> Subject: Re: [ovirt-users] ovn-provider-network
>
> On Wed, Mar 13, 2019 at 10:08 PM Staniforth, Paul
>  wrote:
> >
> > Hello,
> >
> >   we are using oVirt-4.2.8 and I have created a logical network 
> > using the ovn-network-provider, I haven't configured it to connect to a 
> > physical network.
> >
> >
> > I have 2 VMs running on 2 hosts which can connect to each other this 
> > logical network. The only connection between the hosts is over the 
> > ovirtmgmt network so presumably the traffic is using this?
>
> Yes, OVN sets up an overlay network on top of ovirtmgmt network.
>
> >
> >
> > Thanks,
> >
> >Paul S.
> >
> > To view the terms under which this email is distributed, please go to:-
> > http://leedsbeckett.ac.uk/disclaimer/email/
> >
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: 
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fsite%2Fprivacy-policy%2Fdata=02%7C01%7CP.Staniforth%40leedsbeckett.ac.uk%7C5336751f2bac4792de0c08d6a87f22f5%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C636881661346520630sdata=AY7YVtWAxfRugtfVf4qpkhSRsAisdGVgBrDLKDmZKyM%3Dreserved=0
> > oVirt Code of Conduct: 
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2Fdata=02%7C01%7CP.Staniforth%40leedsbeckett.ac.uk%7C5336751f2bac4792de0c08d6a87f22f5%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C636881661346520630sdata=LON7wN1k4d2OOEwEqb7xxkc2w4NwlWjRK5AjYLmLSu0%3Dreserved=0
> > List Archives: 
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2FB22LIMO6RI4SBYAOVDRWPQX3UUUYTUGL%2Fdata=02%7C01%7CP.Staniforth%40leedsbeckett.ac.uk%7C5336751f2bac4792de0c08d6a87f22f5%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C636881661346520630sdata=2yPcOGZFuJM05c9%2Bhw73OS14NRJ6wRAG9RfbdJTaRGw%3Dreserved=0
> To view the terms under which this email is distributed, please go to:-
> http://leedsbeckett.ac.uk/disclaimer/email/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/NPVZGHQHJQE2YIBD6ID5KM7RPJ36M55R/


[ovirt-users] Re: ovn-provider-network

2019-03-14 Thread Miguel Duarte de Mora Barroso
On Wed, Mar 13, 2019 at 10:08 PM Staniforth, Paul
 wrote:
>
> Hello,
>
>   we are using oVirt-4.2.8 and I have created a logical network 
> using the ovn-network-provider, I haven't configured it to connect to a 
> physical network.
>
>
> I have 2 VMs running on 2 hosts which can connect to each other this logical 
> network. The only connection between the hosts is over the ovirtmgmt network 
> so presumably the traffic is using this?

Yes, OVN sets up an overlay network on top of ovirtmgmt network.

>
>
> Thanks,
>
>Paul S.
>
> To view the terms under which this email is distributed, please go to:-
> http://leedsbeckett.ac.uk/disclaimer/email/
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/B22LIMO6RI4SBYAOVDRWPQX3UUUYTUGL/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/5RB4W7HSCUIDJCYCO7MJV6NARNZHWI3E/


[ovirt-users] Re: Suggestions on adding 1000 or more networks to an engine/hosts

2019-02-19 Thread Miguel Duarte de Mora Barroso
On Mon, Feb 18, 2019 at 9:41 PM Brian Wilson  wrote:
>
> It looked to continue to add them if looking at something like output from 
> "ip link".
>
> I was not however able to save the networks so the host always had "Unsaved 
> Network Changes".
>
> I eventually needed to use the host and rebooted it and since they weren't 
> saved they were all gone on reboot.
>
>
>
> So the takeaway i see here is that with Bridged Networks there is a softlimit 
> of ~350 in a Datacenter/Cluster due to the timeout of the VDSM.  "vdsTimeout"
>
> Is this something we could tune if we wanted have more than 350?
>
> Im trying to think of what would happen if we increased that to anything else 
> though.

I think Petr is the best person to theorize over this :)

+Petr Horacek , what are your thoughts on this matter?

>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/SUANWYTO727LRQFC5X22G2AVSNQ52HG6/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/AXD3O5XPLDIPXULXDFGKO6ZGOTNCHWUR/


[ovirt-users] Re: Upgrade from 4.2.7 to 4.3.0 troubles

2019-02-15 Thread Miguel Duarte de Mora Barroso
On Fri, Feb 15, 2019 at 4:59 PM Mariani Alberto
 wrote:
>
> It seems as always my bad luck's sight is 20/20...

I actually think you can retry now:

[root@e66c37a9472b /]# yum install
http://resources.ovirt.org/pub/yum-repo/ovirt-release43.rpm
Loaded plugins: fastestmirror, ovl
ovirt-release43.rpm| 9.8 kB  00:00:00
Examining /var/tmp/yum-root-VsnEAY/ovirt-release43.rpm:
ovirt-release43-4.3.0-1.el7.noarch
Marking /var/tmp/yum-root-VsnEAY/ovirt-release43.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package ovirt-release43.noarch 0:4.3.0-1.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

==
 Package  ArchVersion Repository
  Size
==
Installing:
 ovirt-release43  noarch  4.3.0-1.el7 /ovirt-release43
  14 k

Transaction Summary
==
Install  1 Package
...
Installed:
  ovirt-release43.noarch 0:4.3.0-1.el7

Complete!
[root@e66c37a9472b /]# yum list openvswitch
...
Available Packages
openvswitch.x86_64 1:2.10.1-3.el7
ovirt-4.3-centos-ovirt43

That is the correct build.

Only bad thing about it, is it has dpdk support disabled; we're
waiting on a new build w/ dpdk support.

Please confirm that you managed to upgrade.


>
>
> Thank you.
>
>
> Best Regards,
> Alberto M.
>
>
> Il 15/02/19 16:54, Miguel Duarte de Mora Barroso ha scritto:
> > On Fri, Feb 15, 2019 at 4:44 PM  wrote:
> >> Hello All,
> >>
> >>
> >> I'm trying to upgrade a Self Hosted Engine installation from 4.2.7 to 
> >> 4.3.0.
> >>
> >> I was able to update the Engine itself, but when I try the general update 
> >> for both the Engine VM and the Self Hosted Nodes the update fails because 
> >> the openvswitch-ovn-* packages want a long series of libraries as 
> >> dependencies, all with the name librte_*
> >>
> >> Unfortunately, I don't think these exist in CentOs 7, so I'm having no 
> >> luck in finding them.
> >>
> >> Am I doing something wrong?
> > You're not doing anything wrong; the openvswitch-ovn-* packages are
> > currently broken due to a dpdk update.
> >
> > A new build has been pushed to release and should hit the centOS repos
> > today - not exactly sure when. If you can, re-try tomorrow.
> >
> > Hope this helps.
> >
> >> Best Regards,
> >> Alberto M.
> >> ___
> >> Users mailing list -- users@ovirt.org
> >> To unsubscribe send an email to users-le...@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/Y7AAB5H2VKYRX3PNFTMOSHAAILEDUTOJ/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/7M7THK5X2RH7JZAU3X7RPEG3NWSJJ2LC/


[ovirt-users] Re: Upgrade from 4.2.7 to 4.3.0 troubles

2019-02-15 Thread Miguel Duarte de Mora Barroso
On Fri, Feb 15, 2019 at 4:44 PM  wrote:
>
> Hello All,
>
>
> I'm trying to upgrade a Self Hosted Engine installation from 4.2.7 to 4.3.0.
>
> I was able to update the Engine itself, but when I try the general update for 
> both the Engine VM and the Self Hosted Nodes the update fails because the 
> openvswitch-ovn-* packages want a long series of libraries as dependencies, 
> all with the name librte_*
>
> Unfortunately, I don't think these exist in CentOs 7, so I'm having no luck 
> in finding them.
>
> Am I doing something wrong?

You're not doing anything wrong; the openvswitch-ovn-* packages are
currently broken due to a dpdk update.

A new build has been pushed to release and should hit the centOS repos
today - not exactly sure when. If you can, re-try tomorrow.

Hope this helps.

>
> Best Regards,
> Alberto M.
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/Y7AAB5H2VKYRX3PNFTMOSHAAILEDUTOJ/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/OUKVKQ6NJAK7T45R3NHOQCMD7QABO5LQ/


[ovirt-users] Re: Vnic-Port mirroring

2019-02-15 Thread Miguel Duarte de Mora Barroso
On Thu, Feb 14, 2019 at 10:32 PM ada per  wrote:

> Thanks everyone for the replies
> Bug ID:1677426 <https://bugzilla.redhat.com/show_bug.cgi?id=1677426>
> -On Thu, Feb 14, 2019 at 6:11 PM Miguel Duarte de Mora Barroso <
> mdbarr...@redhat.com> wrote:
>
>>
>> As a workaround, I think you could try the REST interface - check [1] and
>> [2] - to update your vnic profile's port mirroring attribute.
>> [1] -
>> http://ovirt.github.io/ovirt-engine-api-model/master/#services/vnic_profile/methods/update
>> [2] -
>> http://ovirt.github.io/ovirt-engine-api-model/master/#types/vnic_profile/attributes/port_mirroring
>>
>> I am using ovirtsdk -python is there any example on how to resolve that
> there?
>

I wrote one; please check [0] out. I hope that filtering the vnic profile
by name is enough.

Let me know if that works; if so, please also comment on the bug ticket
that using the REST API you were able to update the port mirroring flag.

[0] -  https://gist.github.com/maiqueb/d644bebb8af19357977387d2d5999c18


> Thank you
>
> On Thu, Feb 14, 2019 at 6:11 PM Miguel Duarte de Mora Barroso <
> mdbarr...@redhat.com> wrote:
>
>>
>>
>> On Thu, Feb 14, 2019 at 4:11 PM ada per  wrote:
>>
>>> No it is not. I think  it is shown in the first screenshot that is
>>> logical
>>>
>>
>> I think you've hit a bug on the frontend code.
>>
>> Would you be kind enough to report it on [0], setting 'BLL.network' as
>> the component ? Please reply with the bug ID so we can track it.
>>
>> As a workaround, I think you could try the REST interface - check [1] and
>> [2] - to update your vnic profile's port mirroring attribute.
>>
>> [0] - https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-engine
>> [1] -
>> http://ovirt.github.io/ovirt-engine-api-model/master/#services/vnic_profile/methods/update
>> [2] -
>> http://ovirt.github.io/ovirt-engine-api-model/master/#types/vnic_profile/attributes/port_mirroring
>>
>>
>>> On Thu, 14 Feb 2019, 16:36 Staniforth, Paul, <
>>> p.stanifo...@leedsbeckett.ac.uk> wrote:
>>>
>>>> I don't know I assume it's not an external network?
>>>> --
>>>> *From:* ada per 
>>>> *Sent:* 14 February 2019 14:24
>>>> *To:* Staniforth, Paul
>>>> *Cc:* Greg Sheremeta; users@ovirt.org
>>>> *Subject:* Re: [ovirt-users] Re: Vnic-Port mirroring
>>>>
>>>> No it is not used by any vms.
>>>> We created a new vnic which is currently not assigned in any vm and
>>>> still no options available.
>>>>
>>>> On Thu, 14 Feb 2019, 16:16 Staniforth, Paul, <
>>>> p.stanifo...@leedsbeckett.ac.uk> wrote:
>>>>
>>>>> is the vNiC profile being used by any VMs , they need to be down to
>>>>> enable port-mirroring
>>>>> --
>>>>> *From:* ada per 
>>>>> *Sent:* 14 February 2019 14:08
>>>>> *To:* Staniforth, Paul
>>>>> *Cc:* Greg Sheremeta; users@ovirt.org
>>>>> *Subject:* Re: [ovirt-users] Re: Vnic-Port mirroring
>>>>>
>>>>> Thanks for your reply,
>>>>>
>>>>> I have 2 clusters one is with linux bridge and the other one is OVS.
>>>>>
>>>>> None seems to work.. I just retried the linux bridge cluster now and
>>>>> still no luck.
>>>>>
>>>>> On Thu, 14 Feb 2019, 15:58 Staniforth, Paul, <
>>>>> p.stanifo...@leedsbeckett.ac.uk> wrote:
>>>>>
>>>>>> Is the cluster using linux bridge? OVS doesn't support Port Mirroring.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>  Paul S.
>>>>>> --
>>>>>> *From:* ada per 
>>>>>> *Sent:* 14 February 2019 12:37
>>>>>> *To:* Greg Sheremeta
>>>>>> *Cc:* users
>>>>>> *Subject:* [ovirt-users] Re: Vnic-Port mirroring
>>>>>>
>>>>>> The one below is  my logical network configuration
>>>>>> [image: image.png]
>>>>>> The following one is the grayed out VNIC Profiles options
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>> On Thu, Feb 14, 2019 at 1:18 PM Greg Sheremeta 
>>>>>> wrote:
>>>>

[ovirt-users] Re: Vnic-Port mirroring

2019-02-14 Thread Miguel Duarte de Mora Barroso
On Thu, Feb 14, 2019 at 4:11 PM ada per  wrote:

> No it is not. I think  it is shown in the first screenshot that is logical
>

I think you've hit a bug on the frontend code.

Would you be kind enough to report it on [0], setting 'BLL.network' as the
component ? Please reply with the bug ID so we can track it.

As a workaround, I think you could try the REST interface - check [1] and
[2] - to update your vnic profile's port mirroring attribute.

[0] - https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-engine
[1] -
http://ovirt.github.io/ovirt-engine-api-model/master/#services/vnic_profile/methods/update
[2] -
http://ovirt.github.io/ovirt-engine-api-model/master/#types/vnic_profile/attributes/port_mirroring


> On Thu, 14 Feb 2019, 16:36 Staniforth, Paul, <
> p.stanifo...@leedsbeckett.ac.uk> wrote:
>
>> I don't know I assume it's not an external network?
>> --
>> *From:* ada per 
>> *Sent:* 14 February 2019 14:24
>> *To:* Staniforth, Paul
>> *Cc:* Greg Sheremeta; users@ovirt.org
>> *Subject:* Re: [ovirt-users] Re: Vnic-Port mirroring
>>
>> No it is not used by any vms.
>> We created a new vnic which is currently not assigned in any vm and still
>> no options available.
>>
>> On Thu, 14 Feb 2019, 16:16 Staniforth, Paul, <
>> p.stanifo...@leedsbeckett.ac.uk> wrote:
>>
>>> is the vNiC profile being used by any VMs , they need to be down to
>>> enable port-mirroring
>>> --
>>> *From:* ada per 
>>> *Sent:* 14 February 2019 14:08
>>> *To:* Staniforth, Paul
>>> *Cc:* Greg Sheremeta; users@ovirt.org
>>> *Subject:* Re: [ovirt-users] Re: Vnic-Port mirroring
>>>
>>> Thanks for your reply,
>>>
>>> I have 2 clusters one is with linux bridge and the other one is OVS.
>>>
>>> None seems to work.. I just retried the linux bridge cluster now and
>>> still no luck.
>>>
>>> On Thu, 14 Feb 2019, 15:58 Staniforth, Paul, <
>>> p.stanifo...@leedsbeckett.ac.uk> wrote:
>>>
 Is the cluster using linux bridge? OVS doesn't support Port Mirroring.


 Regards,

  Paul S.
 --
 *From:* ada per 
 *Sent:* 14 February 2019 12:37
 *To:* Greg Sheremeta
 *Cc:* users
 *Subject:* [ovirt-users] Re: Vnic-Port mirroring

 The one below is  my logical network configuration
 [image: image.png]
 The following one is the grayed out VNIC Profiles options

 [image: image.png]

 On Thu, Feb 14, 2019 at 1:18 PM Greg Sheremeta 
 wrote:

> Can you share a screenshot?
>
> On Thu, Feb 14, 2019 at 4:14 AM ada per  wrote:
>
>> Hello everyone,
>>
>> I am trying to allow port mirroring through the Vnic profile but no
>> matter what i do it stays grayed out. How can i enable this option?
>>
>> When i am creating a new VNIC profile the options ,port mirroring and
>> passthrough are disabled.
>>
>> the version i am using is 4.2.8.
>> Thanks!:)
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@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/YFD5NVE4LF5IL7SX2Z2FB3YGFNQSEFP4/
>>
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
>
 To view the terms under which this email is distributed, please go to:-
 http://leedsbeckett.ac.uk/disclaimer/email/

 To view the terms under which this email is distributed, please go to:-
>>> http://leedsbeckett.ac.uk/disclaimer/email/
>>>
>>> To view the terms under which this email is distributed, please go to:-
>> http://leedsbeckett.ac.uk/disclaimer/email/
>>
>> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/FDTK7XZZGAGZPIAU7JIR6VAAJUA5YLDU/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/IKXIV7U26XIVXFYBMZAYIM3FOTUFWISN/


[ovirt-users] Re: Network Performance Issues

2019-02-08 Thread Miguel Duarte de Mora Barroso
Hi Bryan,

On Thu, Feb 7, 2019 at 10:00 PM Bryan Sockel  wrote:
>
> Hi,
>
>
>
> I currently have a 4 node ovirt cluster running.  Each node is configured 
> with an active passive network setup, with each link being 10 GB.  After 
> looking over my performance metrics collected via observium.  I am noticing 
> the network traffic rarely exceeds 100 MB.  I am noticing this across all 
> four of my servers and my 2 storage arrays that are also connected via the 
> same 10 GB links.
>
>
>
> What is the best way to trouble shoot this problem?

Could you run iperf between 2 nodes on the cluster ?

Also, please report the MTU of the network in question.

>
>
>
> Thanks
>
>
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/P4KJR6F4QPQRN3XFULCHV7ZDU77LJLEE/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/A3IYCXZAMQRQQXA5TAMI2BXLE6TZT4E2/


[ovirt-users] Re: Forcing vdsm to configure another NIC as the bridge (oVirt 4.2.8)

2019-02-08 Thread Miguel Duarte de Mora Barroso
Hi Zachary,

On Fri, Feb 8, 2019 at 2:56 AM  wrote:
>
> I installed a new 10GbE NIC after installing the oVirt engine, and upon 
> reboot vdsm began auto-configuring one of the ports on the new NIC rather 
> than the original 1GbE interface.  The new NIC is not currently connected to 
> anything, so I am wondering how to force vdsm to use the 1GbE NIC until I 
> install and connect the server to a 10GbE switch.  This is causing the data 
> center and host in the Administration Portal to show as "non-operational," 
> though I can still log in.
>
> I have been poring over any files I can find on the server relating to 
> "ovirtmgmt" or "vdsm," and I am wondering if I simply change the "nic" 
> parameter to the name of the 1GbE interface in the following file that 
> reloading vdsmd or rebooting will cause it to behave the way I want:
>
> /var/lib/vdsm/persistence/netconf/nets/ovirtmgmt
>
> Any insight on this?  Are there other locations that need to be edited to 
> force vdsm to use, say, "eth0" rather than "eth3"?  Are there files that I 
> need to delete so vdsm will automatically re-create them?

Actually, engine itself can take care of this.

You can configure the new nic through the UI, by clicking through
'Compute' > "Hosts" > (select the host in question) > "Network
Interfaces" > "Setup Host Networks".

There you can attach the desired network to the desired nic.

>
> Any help is appreciated - thanks!

Let me know if this solved your issue.

> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/OFYRUQYT7VB34ZPWFBCUISJKIXZ6IMH4/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/TGWQBET5T2XUQMZBE2NM3N6OTPFYCEOL/


[ovirt-users] Re: Adding a new Host to Cluster via oVirt Manager fails with "No Route to Host"

2018-10-09 Thread Miguel Duarte de Mora Barroso
After a while I managed to access that.

I asked for it, since you said the 'installation process failed'.

Please also get us the vdsm.log and supervdsm.log of the failed host.

On Mon, Oct 8, 2018 at 12:46 PM, Markus Frei  wrote:
> Hi Miguel
>
> Thanks for your reply.
> I hope this is how you wanted it.
> It`s the ovirt-host-deploy log, but it doesn`t contain any errors.
>
> https://paste.simplylinux.ch/view/a16a3a99
>
> Kind regards,
> Chris
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/PV7VMUFL5GPFED5KB2GB5PZNXVFGYQ4Y/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/B522YABRCANOXNXJUYZULTSHEC3Z4UXX/


[ovirt-users] Re: Adding a new Host to Cluster via oVirt Manager fails with "No Route to Host"

2018-10-08 Thread Miguel Duarte de Mora Barroso
Could you share a pastebin with the contents of the relevant host
install log (located at /var/log/ovirt-engine/host-deploy/ ) ?


On Fri, Oct 5, 2018 at 4:38 PM, Markus Frei  wrote:
> Additionally I "grepped" all WARNs and ERRORs from an installation process. 
> Hope this is helpfully.
> Fun Fact: This time the message "No route to host" is not present.
>
> 2018-10-05 16:10:17,335+02 WARN  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (VdsDeploy) [f0f524b] EVENT_ID: VDS_INSTALL_IN_PROGRESS_WARNING(510), Host 
> myhostname installation in progress . Confirm use of GPG Key userid=CentOS 
> Storage SIG (http://wiki.centos.org/SpecialInterestGroup/Storage) 
>  hexkeyid=E451E5B5.
> 2018-10-05 16:17:52,487+02 ERROR 
> [org.ovirt.engine.core.bll.SetNonOperationalVdsCommand] 
> (EE-ManagedThreadFactory-engine-Thread-20884) [5b501a44] Host 'myhostname' is 
> set to Non-Operational, it is missing the following networks: 
> 'inet,inet-customers,inet-hosting,net1,net3,net38,net-hosting'
> 2018-10-05 16:17:52,501+02 WARN  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engine-Thread-20884) [5b501a44] EVENT_ID: 
> VDS_SET_NONOPERATIONAL_NETWORK(519), Host myhostname does not comply with the 
> cluster Cluster networks, the following networks are missing on host: 
> 'inet,inet-customers,inet-hosting,net1,net3,net38,net-hosting'
> 2018-10-05 16:17:52,507+02 ERROR 
> [org.ovirt.engine.core.bll.job.ExecutionHandler] 
> (EE-ManagedThreadFactory-engine-Thread-20884) [5b501a44] Exception: 
> org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC 
> Connection; nested exception is java.sql.SQLException: 
> javax.resource.ResourceException: IJ000457: Unchecked throwable in 
> managedConnectionReconnected() 
> cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@64330f0a[state=NORMAL
>  managed 
> connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@2e958c5 
> connection handles=0 lastReturned=1538749072502 lastValidated=1538748751557 
> lastCheckedOut=1538749072499 trackByTx=false 
> pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@17388824 
> mcp=SemaphoreConcurrentLinkedQueueManagedConnectionPool@4eb14706[pool=ENGINEDataSource]
>  xaResource=LocalXAResourceImpl@1657bdb2[connectionListener=64330f0a 
> connectionManager=1fe5192 warned=false currentXid=null productName=PostgreSQL 
> productVersio
>  n=9.5.9 jndiName=java:/ENGINEDataSource] txSync=null]
> 2018-10-05 16:17:52,520+02 ERROR 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.CollectVdsNetworkDataAfterInstallationVDSCommand]
>  (EE-ManagedThreadFactory-engine-Thread-20884) [5b501a44] Failed in 
> 'CollectVdsNetworkDataAfterInstallationVDS' method, for vds: 'myhostname'; 
> host: 'myhostname': Could not get JDBC Connection; nested exception is 
> java.sql.SQLException: javax.resource.ResourceException: IJ000457: Unchecked 
> throwable in managedConnectionReconnected() 
> cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@64330f0a[state=NORMAL
>  managed 
> connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@2e958c5 
> connection handles=0 lastReturned=1538749072516 lastValidated=1538748751557 
> lastCheckedOut=1538749072513 trackByTx=false 
> pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@17388824 
> mcp=SemaphoreConcurrentLinkedQueueManagedConnectionPool@4eb14706[pool=ENGINEDataSource]
>  xaResource=LocalXAResourceImpl@1657bdb2[connectionListener=64330f0a 
> connectionMa
>  nager=1fe5192 warned=false currentXid=null productName=PostgreSQL 
> productVersion=9.5.9 jndiName=java:/ENGINEDataSource] txSync=null]
> 2018-10-05 16:17:52,520+02 ERROR 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.CollectVdsNetworkDataAfterInstallationVDSCommand]
>  (EE-ManagedThreadFactory-engine-Thread-20884) [5b501a44] Command 
> 'CollectVdsNetworkDataAfterInstallationVDSCommand(HostName = myhostname, 
> CollectHostNetworkDataVdsCommandParameters:{hostId='c549d687-8aef-44fe-bbff-b4e63a5afc46',
>  vds='Host[myhostname,c549d687-8aef-44fe-bbff-b4e63a5afc46]'})' execution 
> failed: Could not get JDBC Connection; nested exception is 
> java.sql.SQLException: javax.resource.ResourceException: IJ000457: Unchecked 
> throwable in managedConnectionReconnected() 
> cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@64330f0a[state=NORMAL
>  managed 
> connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@2e958c5 
> connection handles=0 lastReturned=1538749072516 lastValidated=1538748751557 
> lastCheckedOut=1538749072513 trackByTx=false 
> pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@17388824 
> mcp=SemaphoreConcurr
>  entLinkedQueueManagedConnectionPool@4eb14706[pool=ENGINEDataSource] 
> xaResource=LocalXAResourceImpl@1657bdb2[connectionListener=64330f0a 
> connectionManager=1fe5192 warned=false currentXid=null productName=PostgreSQL 
> 

[ovirt-users] Re: Error when running hosted-engine deploy on system with bond of bonds

2018-10-05 Thread Miguel Duarte de Mora Barroso
On Thu, Oct 4, 2018 at 11:49 PM, Ben Webber  wrote:
> Hi,
>
> I'm trying to set up ovirt using the hosted-engine --deploy command on 
> CentOS7, but am encountering an error. I am running a slightly unusual 
> network configuration. I have two fairly basic non stacked gigabit switches 
> with port channels connecting the two switches together. I have a lacp bond 
> from the host consisting of 4 ports to each switch (bond1 and bond2). I have 
> then created an active-backup bond (bond0) using the two lacp bonds as slaves 
> in the hope to create ha at the switch layer using my basic switches. There 
> is then a VLAN (101) on bond0.
>
> This network configuration runs fine on the host, however, when run, after a 
> short while, the hosted-engine --deploy command outputs the following error:
>
> ...
>
> [ INFO  ] TASK [Force host-deploy in offline mode]
> [ INFO  ] ok: [localhost]
> [ INFO  ] TASK [Add host]
> [ INFO  ] changed: [localhost]
> [ INFO  ] TASK [Wait for the host to be up]
> [ INFO  ] ok: [localhost]
> [ INFO  ] TASK [Check host status]
> [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The host 
> has been set in non_operational status, please check engine logs, fix 
> accordingly and re-deploy.\n"}
>
> ...
>
>
> Looking in /var/log/ovirt-engine/engine.log on the machine created, I can see 
> the following errors logged:
>
> ...
>
> 2018-10-04 21:51:30,116+01 INFO  
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] 
> (EE-ManagedThreadFactory-engine-Thread-1) [59fb360a] START, 
> HostSetupNetworksVDSCommand(HostName = ov1.test.local, 
> HostSetupNetworksVdsCommandParameters:{hostId='7440c9b9-e530-4341-a317-d3a9041dc777',
>  vds='Host[ov1.test.local,7440c9b9-e530-4341-a317-d3a9041dc777]', 
> rollbackOnFailure='true', connectivityTimeout='120', 
> networks='[HostNetwork:{defaultRoute='true', bonding='true', 
> networkName='ovirtmgmt', vdsmName='ovirtmgmt', nicName='bond0', vlan='101', 
> vmNetwork='true', stp='false', properties='null', 
> ipv4BootProtocol='STATIC_IP', ipv4Address='192.168.1.11', 
> ipv4Netmask='255.255.255.0', ipv4Gateway='192.168.1.1', 
> ipv6BootProtocol='AUTOCONF', ipv6Address='null', ipv6Prefix='null', 
> ipv6Gateway='null', nameServers='null'}]', removedNetworks='[]', bonds='[]', 
> removedBonds='[]', clusterSwitchType='LEGACY'}), log id: 4f0c7eaa
> 2018-10-04 21:51:30,121+01 INFO  
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] 
> (EE-ManagedThreadFactory-engine-Thread-1) [59fb360a] FINISH, 
> HostSetupNetworksVDSCommand, log id: 4f0c7eaa
> 2018-10-04 21:51:30,645+01 ERROR 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] 
> (EE-ManagedThreadFactory-engine-Thread-1) [59fb360a] Failed in 
> 'HostSetupNetworksVDS' method
> 2018-10-04 21:51:30,687+01 ERROR 
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engine-Thread-1) [59fb360a] EVENT_ID: 
> VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ov1.test.local command 
> HostSetupNetworksVDS failed: Unknown nics in: ['bond1', 'bond2']
> 2018-10-04 21:51:30,688+01 ERROR 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] 
> (EE-ManagedThreadFactory-engine-Thread-1) [59fb360a] Error: 
> VDSGenericException: VDSErrorException: Failed to HostSetupNetworksVDS, error 
> = Unknown nics in: ['bond1', 'bond2'], code = 23
>
> ...
>
>
> It looks like when HostSetupNetworksVDS is run, it is checking that the slave 
> interfaces to the bonds are physical network devices and being as the slaves 
> of bond0 are bond1 and bond2, rather than physical devices, it then throws 
> the error Unknown nics in: ['bond1', 'bond2'].
>
> Is there anything I can do or any configuration that I can put anywhere to 
> make it work with this "stacked bond" configuration or does ovirt just not 
> work when bonds are set up like this?

Forwarding to Simone, who is an ovirt-hosted-engine-setup expert.

Please get us a pastebin with the output of 'ansible-playbook -vvv -i
localhost, 
/usr/share/ovirt-hosted-engine-setup/ansible/get_network_interfaces.yml'
on your engine node.

One thing I want to make sure: your bond1 and bond2 configurations are
 IEEE 802.3ad bonds, please confirm.

>
> Thanks in advance,
>
> Ben
>
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/XPHQTPUINKZBSZVUDP2G66UPA5OJL3J7/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 

[ovirt-users] Re: OVN and impact of missing connectivity with OVN Provider/Central

2018-09-05 Thread Miguel Duarte de Mora Barroso
Hi Gianluca,

I really don't think it should.

I've re-created that scenario - I didn't go as far as to stop the
engine, but stopped *all* of the ovn stuff running on it - and despite
that, the flows on the host were unaffected, and traffic kept flowing.

Could you provide the output of 'ovs-ofctl dump-flows br-int' *before*
and *after* engine is shutdown ?

Also outputs to 'ovs-vsctl show' and 'ovs-ofctl show br-int' . Also
before and after engine-shutdown.

All of the above on the host where the VMs are running.

Another question; is the OVN network you created an overlay, or is it
attached to a physical network?

Regards,
Miguel


On Tue, Sep 4, 2018 at 3:15 PM, Gianluca Cecchi
 wrote:
> Hello,
> I have VM1 and VM2 with their vnics on OVN.
> They are running on the same host.
> Suppose this host (and so its OVN Controller) looses connectivity with the
> OVN Provider (that in my case runs on oVirt engine, that is an external
> server).
> Is it correct/expected that VM1 looses connectivity with VM2 until fixed?
>
> So, in other words, is the OVN Provider a sort of single point of failure
> (eg if I restart enigine in my case)?
>
> Thanks,
> Gianluca
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/ESBKINTLKTWNQ2PXCCFSPQBHNK5ECSNO/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/32M6CQSIJTSNYSY3HW5SFMDSLKQYTKLH/


[ovirt-users] Re: Clarifications regarding ovirt-provider-ovn network

2018-08-17 Thread Miguel Duarte de Mora Barroso
On Thu, Aug 16, 2018 at 9:11 PM,   wrote:
> Well, you are right about that. My cluster's switch type is linux bridge. 
> Regrding the first question though, is VLAN tagging unsupported on external 
> provider networks?

Yes, VLAN tagging is *not* supported on external provider networks.

The idea there is that you can create multiple isolated logical
networks in the external provider, providing the same functionality as
VLAN does.

You can though connect an external network to a VLAN tagged physical network.

> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/WGA4KMZAAWYDHWAVMKUIOZ5T2UNMQPA5/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/KRCMB53V44EGFBKPY6U4YJENZ5LOGHWJ/


[ovirt-users] Re: Clarifications regarding ovirt-provider-ovn network

2018-08-16 Thread Miguel Duarte de Mora Barroso
On Tue, Aug 14, 2018 at 11:50 PM, Anurag Porripireddi
 wrote:
> Hi,
>
> I had some questions a overt-provider-ovn based external network which is 
> built on top of an physical network. I notice that VLAN tagging gets greyed 
> out when I try to create an external provider network. Is it not supported by 
> overt right now?I am on version 4.2.5.3. Also, if I create NICs with the 
> external provider network built atop a physical network on VMs that are on 
> different hosts, but the same cluster, I see they are unable to ping each 
> other, though it seems to work fine if they are on the same host. Is that 
> elected behaviour? Could you you please help me understand why?

Currently, inter-host communication over an external network is only
supported *if* the cluster's switch type is OVS - could you confirm my
suspicion that the switch type of the cluster where you're creating
your VMs is indeed linux bridge?

You could achieve inter host communication in a linux bridge cluster
by specifying a pure overlay network - e.g. don't connect the external
network to a physical network.

Never-the-less, the 'correct' way would be to created both the
physical and the external network in another cluster, with switch type
OVS; which - AFAIK - is currently *not* recommended for production use
cases.

>
> Thanks,
> Anurag
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/OAJ62BNREVNYOXA4H2SBT7RH2ECRUHUQ/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/SE3TVMBAMQSKATUBIWD5DVJRJ273SBTB/


[ovirt-users] Re: OVN ACLs

2018-07-11 Thread Miguel Duarte de Mora Barroso
On Thu, Jul 5, 2018 at 9:19 PM, Niyazi Elvan  wrote:
> Hi All,
>
> I have started testing oVirt 4.2 and focused on OVN recently. I was
> wondering whether there is a plan to manage L2->L7 ACLs through oVirt web
> ui.
> If not, how could it be possible to manage ACLs except command line tools ?
> Using opendaylight ??
>
> All the best !
> Niyazi
>
> --
> Niyazi Elvan
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/ZIF233I4EJXWEQA56GGSGAMKEQI7C56X/
>

Hello,

Ovirt does not currently support OVN ACLs, but leveraging them is in
our road map.

We're planning on exposing networking API security groups [1], which
will be implemented as OVN ACLs.

Unfortunately, the time frame is not completely defined yet.

I can also say that the UI side was never evaluated, so it is
currently out of scope - not sure on the long term goals though.

Best regards,
Miguel

[1] - 
https://developer.openstack.org/api-ref/network/v2/#security-groups-security-groups
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/EJBWW2CXJVA2ZW43XH42YSRB2DJQO4NV/