[ovirt-users] Re: New failure Gluster deploy: Set granual-entry-heal on --> Bricks down

2021-01-27 Thread Sverker Abrahamsson via Users

We ran in to this issue as well when trying to install Ovirt Hyperconverged.

The root issue is that kmod-kvdo in Centos 8 (and probably upstream) is 
built for a specific kernel and if you don't run that kernel it is not 
found. This is a major issue even if you match the kernel version then 
if the kernel is updated then your volume will fail because a rpm 
package for kmod-kvdo for that specific kernel would have to be built. 
It doesn't even declare a rpm dependency on the kernel version it works 
with.


I cloned the git repo from https://github.com/dm-vdo/kvdo and built a 
rpm from there, it uses dkms so it will build a module for the running 
kernel and if the kernel is updated then a new module for that version 
will be built. Works like a charm every time, but I haven't yet tried to 
run the hyperconverged wizard again.


/Sverker

Den 2021-01-11 kl. 21:32, skrev Charles Lam:

Dear Strahil and Ritesh,

Thank you both.  I am back where I started with:

"One or more bricks could be down. Please execute the command again after bringing all bricks online and finishing 
any pending heals\nVolume heal failed.", "stdout_lines": ["One or more bricks could be down. Please 
execute the command again after bringing all bricks online and finishing any pending heals", "Volume heal 
failed."]

Regarding my most recent issue:

"vdo: ERROR - Kernel module kvdo not installed\nvdo: ERROR - modprobe: FATAL: 
Module
kvdo not found in directory /lib/modules/4.18.0-240.1.1.el8_3.x86_64\n"

Per Strahil's note, I checked for kvdo:

[r...@host1.tld.com conf.d]# rpm -qa | grep vdo
libblockdev-vdo-2.24-1.el8.x86_64
vdo-6.2.3.114-14.el8.x86_64
kmod-kvdo-6.2.2.117-65.el8.x86_64
[r...@host1.tld.com conf.d]#

[r...@host2.tld.com conf.d]# rpm -qa | grep vdo
libblockdev-vdo-2.24-1.el8.x86_64
vdo-6.2.3.114-14.el8.x86_64
kmod-kvdo-6.2.2.117-65.el8.x86_64
[r...@host2.tld.com conf.d]#

[r...@host3.tld.com ~]# rpm -qa | grep vdo
libblockdev-vdo-2.24-1.el8.x86_64
vdo-6.2.3.114-14.el8.x86_64
kmod-kvdo-6.2.2.117-65.el8.x86_64
[r...@host3.tld.com ~]#

I found 
https://unix.stackexchange.com/questions/624011/problem-on-centos-8-with-creating-vdo-kernel-module-kvdo-not-installed
 which pointed to https://bugs.centos.org/view.php?id=17928.  As suggested on 
the CentOS bug tracker I attempted to manually install

vdo-support-6.2.4.14-14.el8.x86_64
vdo-6.2.4.14-14.el8.x86_64
kmod-kvdo-6.2.3.91-73.el8.x86_64

but there was a dependency that kernel-core be greater than what I was 
installed, so I manually upgraded kernel-core to 
kernel-core-4.18.0-259.el8.x86_64.rpm then upgraded vdo and kmod-kvdo to

vdo-6.2.4.14-14.el8.x86_64.rpm
kmod-kvdo-6.2.4.26-76.el8.x86_64.rpm

and installed vdo-support-6.2.4.14-14.el8.x86_64.rpm.  Upon clean-up and 
redeploy I am now back at Gluster deploy failing at

TASK [gluster.features/roles/gluster_hci : Set granual-entry-heal on] **
task path: 
/etc/ansible/roles/gluster.features/roles/gluster_hci/tasks/hci_volumes.yml:67
failed: [fmov1n1.sn.dtcorp.com] (item={'volname': 'engine', 'brick': '/gluster_bricks/engine/engine', 'arbiter': 0}) => {"ansible_loop_var": "item", "changed": true, "cmd": ["gluster", "volume", "heal", "engine", "granular-entry-heal", "enable"], "delta": "0:00:10.098573", 
"end": "2021-01-11 19:27:05.333720", "item": {"arbiter": 0, "brick": "/gluster_bricks/engine/engine", "volname": "engine"}, "msg": "non-zero return code", "rc": 107, "start": "2021-01-11 19:26:55.235147", "stderr": "", "stderr_lines": [], 
"stdout": "One or more bricks could be down. Please execute the command again after bringing all bricks online and finishing any pending heals\nVolume heal failed.", "stdout_lines": ["One or more bricks could be down. Please execute the command again after bringing all bricks online and finishing any pending heals", "Volume heal failed."]}
failed: [fmov1n1.sn.dtcorp.com] (item={'volname': 'data', 'brick': '/gluster_bricks/data/data', 'arbiter': 0}) => {"ansible_loop_var": "item", "changed": true, "cmd": ["gluster", "volume", "heal", "data", "granular-entry-heal", "enable"], "delta": "0:00:10.099670", "end": 
"2021-01-11 19:27:20.564554", "item": {"arbiter": 0, "brick": "/gluster_bricks/data/data", "volname": "data"}, "msg": "non-zero return code", "rc": 107, "start": "2021-01-11 19:27:10.464884", "stderr": "", "stderr_lines": [], "stdout": "One or 
more bricks could be down. Please execute the command again after bringing all bricks online and finishing any pending heals\nVolume heal failed.", "stdout_lines": ["One or more bricks could be down. Please execute the command again after bringing all bricks online and finishing any pending heals", "Volume heal failed."]}
failed: [fmov1n1.sn.dtcorp.com] (item={'volname': 'vmstore', 'brick': '/gluster_bricks/vmstore/vmstore', 'arbiter': 0}) => {"ansible_loop_var": "item", "changed": true, "cmd": ["gluster", "volume", "heal", "vmstore", "granular-entry-heal", "enable"], "delta": "0:00:10.104624", 
"end": "2021-01-11 19:27:35.774230", 

[ovirt-users] Re: Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-03 Thread Sverker Abrahamsson via Users
v6:
    enabled: false
  mac-address: A2:35:7A:6C:B7:EF
  mtu: 1500

/Sverker


Was the enp4s0 always managed by NetworkManager or only after the 
attempt to make the ovirtmgmt? If not that would explain the failure.
Also the workaround would be to configure the interface via 
NetworkManager and then run the host deploy again.


Thanks,
Ales

Den 2020-09-03 kl. 11:54, skrev Ales Musil:



On Thu, Sep 3, 2020 at 11:51 AM Sverker Abrahamsson via Users
mailto:users@ovirt.org>> wrote:

Hi Dominik
That is my issue, I don't get to where I can get the
ovirtmgmt bridge established because vdsm insists on creating
it. It used to be possible to create that bridge statically
and vdsm would just skip it but seems to be broken now.

If it would be possible to use OVN for the management network
that would solve my issue and would be the preferable
solution, but as you write that isn't possible which was what
I suspected.

Do you have any other suggestion on how to solve this issue?
That I get the external interface untagged and the internal
network tagged is not possible to change.

/Sverker


Hello Sverker,

can you please share output from "nmcli con show" and "nmstatectl
show"?

Thank you.
Regards,
Ales

Den 2020-09-03 kl. 10:52, skrev Dominik Holler:



On Wed, Sep 2, 2020 at 10:38 PM Sverker Abrahamsson via
Users mailto:users@ovirt.org>> wrote:

Well, unforturnatly I don't have a choise since it is
out of my control.
I only have one physical network port where the external
traffic is
untagged and the internal vlan is tagged. If I could run
with OVN


OVN is for VM traffic only, not usable for the
management network.

instead I wouldn't need that tagged vlan, but I haven't
been able to get
that to work neither.


Please let us know if OVN does not work for VM traffic for you.

It's perfectly possible to have both tagged and untagged
traffic on the
same switch port, issue is that vdsm tries to take
control over the
network without being able to be flexible enough.. I'm
attempting now to
have ovirtmgmt bridge created before, that used to be
possible but
according to previous mails on the list it went broken
somewhere at 4.x.

/Sverker

Den 2020-09-02 kl. 21:39, skrev Strahil Nikolov:
> Switchports can either be tagged or untagged.
> I'm not sure that your setup is supported at all.
>
> Best Regards,
> Strahil Nikolov
>
>
>
        >
        >
>
> В сряда, 2 септември 2020 г., 20:41:57 Гринуич+3,
Sverker Abrahamsson via Users mailto:users@ovirt.org>> написа:
>
>
>
>
>
> Pretty formatting the "desired state" it seems that
vdsm tries to remove
> the ip of my underlying interface, that is enp4s0:
> 


> {
>      'interfaces': [{
>              'name': 'enp4s0',
>              'state': 'up',
>              'mtu': 1500
>          }, {
>              'vlan': {
>                  'id': 4000,
>                  'base-iface': 'enp4s0'
>              },
>              'name': 'enp4s0.4000',
>              'type': 'vlan',
>              'state': 'up',
>              'mtu': 1500,
>              'ipv4': {
>                  'enabled': False
>              },
>              'ipv6': {
>                  'enabled': False
>              }
>          }, {
>              'name': 'ovirtmgmt',
>              'type': 'linux-bridge',
>              'state': 'up',
>              'mtu': 1500,
>              'bridge': {
>                  'port': [{
>                          'name': 'enp4s0.4000'
>                      }
>                  ],
>                  'options': {
>                      'stp': {
>                          'enabled': False
>                      }
>

[ovirt-users] Re: Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-03 Thread Sverker Abrahamsson via Users
 this:


[root@h1-mgmt ~]# nmcli con show
NAME UUID TYPE  DEVICE
enp4s0   af7ccb53-011b-4c36-998a-1878b4ae7100 ethernet  enp4s0
enp4s0.4000  ecc8064d-18c1-99b7-3fe4-9c5a593ece6f vlan  enp4s0.4000
[root@h1-mgmt ~]# nmstatectl show
---
dns-resolver:
  config:
    search: []
    server:
    - 213.133.98.98
  running:
    search: []
    server:
    - 213.133.98.98
route-rules:
  config: []
routes:
  config:
  - destination: 0.0.0.0/0
    metric: -1
    next-hop-address: 144.76.84.65
    next-hop-interface: enp4s0
    table-id: 0
  - destination: ::/0
    metric: -1
    next-hop-address: fe80::1
    next-hop-interface: enp4s0
    table-id: 0
  running:
  - destination: 0.0.0.0/0
    metric: 100
    next-hop-address: 144.76.84.65
    next-hop-interface: enp4s0
    table-id: 254
  - destination: 144.76.84.65/32
    metric: 100
    next-hop-address: ''
    next-hop-interface: enp4s0
    table-id: 254
  - destination: 172.27.1.0/24
    metric: 400
    next-hop-address: ''
    next-hop-interface: enp4s0.4000
    table-id: 254
  - destination: 2a01:4f8:192:1148::/64
    metric: 100
    next-hop-address: ''
    next-hop-interface: enp4s0
    table-id: 254
  - destination: ::/0
    metric: 100
    next-hop-address: fe80::1
    next-hop-interface: enp4s0
    table-id: 254
  - destination: fe80::/64
    metric: 100
    next-hop-address: ''
    next-hop-interface: enp4s0
    table-id: 254
  - destination: ff00::/8
    metric: 256
    next-hop-address: ''
    next-hop-interface: enp4s0
    table-id: 255
interfaces:
- name: ;vdsmdummy;
  type: linux-bridge
  state: down
  ipv4:
    enabled: false
  ipv6:
    enabled: false
  mac-address: B2:9E:E0:61:71:88
  mtu: 1500
- name: br-int
  type: unknown
  state: down
  ipv4:
    enabled: false
  ipv6:
    enabled: false
  mac-address: 6E:37:94:63:E0:4B
  mtu: 1500
- name: enp4s0
  type: ethernet
  state: up
  ethernet:
    auto-negotiation: true
    duplex: full
    speed: 1000
  ipv4:
    address:
    - ip: 144.76.84.73
  prefix-length: 32
    dhcp: false
    enabled: true
  ipv6:
    address:
    - ip: 2a01:4f8:192:1148::2
  prefix-length: 64
    - ip: fe80::62a4:4cff:fee9:4ac
  prefix-length: 64
    auto-dns: true
    auto-gateway: true
    auto-routes: true
    autoconf: true
    dhcp: true
    enabled: true
  mac-address: 60:A4:4C:E9:04:AC
  mtu: 1500
- name: enp4s0.4000
  type: vlan
  state: up
  ipv4:
    address:
    - ip: 172.27.1.1
  prefix-length: 24
    dhcp: false
    enabled: true
  ipv6:
    autoconf: false
    dhcp: false
    enabled: false
  mac-address: 60:A4:4C:E9:04:AC
  mtu: 1500
  vlan:
    base-iface: enp4s0
    id: 4000
- name: lo
  type: unknown
  state: down
  ipv4:
    enabled: false
  ipv6:
    enabled: false
  mtu: 65536
- name: ovs-system
  type: unknown
  state: down
  ipv4:
    enabled: false
  ipv6:
    enabled: false
  mac-address: A2:35:7A:6C:B7:EF
  mtu: 1500

/Sverker

Den 2020-09-03 kl. 11:54, skrev Ales Musil:



On Thu, Sep 3, 2020 at 11:51 AM Sverker Abrahamsson via Users 
mailto:users@ovirt.org>> wrote:


Hi Dominik
That is my issue, I don't get to where I can get the ovirtmgmt
bridge established because vdsm insists on creating it. It used to
be possible to create that bridge statically and vdsm would just
skip it but seems to be broken now.

If it would be possible to use OVN for the management network that
would solve my issue and would be the preferable solution, but as
you write that isn't possible which was what I suspected.

Do you have any other suggestion on how to solve this issue? That
I get the external interface untagged and the internal network
tagged is not possible to change.

/Sverker


Hello Sverker,

can you please share output from "nmcli con show" and "nmstatectl show"?

Thank you.
Regards,
Ales

Den 2020-09-03 kl. 10:52, skrev Dominik Holler:



On Wed, Sep 2, 2020 at 10:38 PM Sverker Abrahamsson via Users
mailto:users@ovirt.org>> wrote:

Well, unforturnatly I don't have a choise since it is out of
my control.
I only have one physical network port where the external
traffic is
untagged and the internal vlan is tagged. If I could run with
OVN


OVN is for VM traffic only, not usable for the management network.

instead I wouldn't need that tagged vlan, but I haven't been
able to get
that to work neither.


Please let us know if OVN does not work for VM traffic for you.

It's perfectly possible to have both tagged and untagged
traffic on the
same switch port, issue is that vdsm tries to take control
over the
network without being able to be flexible enough.. I'm
attempting now to
have ovirtmgmt bridge created before, that used to be
possible but
according to previous mails on the list it went broken
somewhere at 4.x.

/Sverker

   

[ovirt-users] Re: Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-03 Thread Sverker Abrahamsson via Users

Hi Dominik
That is my issue, I don't get to where I can get the ovirtmgmt bridge 
established because vdsm insists on creating it. It used to be possible 
to create that bridge statically and vdsm would just skip it but seems 
to be broken now.


If it would be possible to use OVN for the management network that would 
solve my issue and would be the preferable solution, but as you write 
that isn't possible which was what I suspected.


Do you have any other suggestion on how to solve this issue? That I get 
the external interface untagged and the internal network tagged is not 
possible to change.


/Sverker

Den 2020-09-03 kl. 10:52, skrev Dominik Holler:



On Wed, Sep 2, 2020 at 10:38 PM Sverker Abrahamsson via Users 
mailto:users@ovirt.org>> wrote:


Well, unforturnatly I don't have a choise since it is out of my
control.
I only have one physical network port where the external traffic is
untagged and the internal vlan is tagged. If I could run with OVN


OVN is for VM traffic only, not usable for the management network.

instead I wouldn't need that tagged vlan, but I haven't been able
to get
that to work neither.


Please let us know if OVN does not work for VM traffic for you.

It's perfectly possible to have both tagged and untagged traffic
on the
same switch port, issue is that vdsm tries to take control over the
network without being able to be flexible enough.. I'm attempting
now to
have ovirtmgmt bridge created before, that used to be possible but
according to previous mails on the list it went broken somewhere
at 4.x.

/Sverker

Den 2020-09-02 kl. 21:39, skrev Strahil Nikolov:
> Switchports can either be tagged or untagged.
> I'm not sure that your setup is supported at all.
>
> Best Regards,
> Strahil Nikolov
>
>
>
>
>
>
> В сряда, 2 септември 2020 г., 20:41:57 Гринуич+3, Sverker
Abrahamsson via Users mailto:users@ovirt.org>>
написа:
>
>
>
>
>
> Pretty formatting the "desired state" it seems that vdsm tries
to remove
> the ip of my underlying interface, that is enp4s0:
> 


> {
>      'interfaces': [{
>              'name': 'enp4s0',
>              'state': 'up',
>              'mtu': 1500
>          }, {
>              'vlan': {
>                  'id': 4000,
>                  'base-iface': 'enp4s0'
>              },
>              'name': 'enp4s0.4000',
>              'type': 'vlan',
>              'state': 'up',
>              'mtu': 1500,
>              'ipv4': {
>                  'enabled': False
>              },
>              'ipv6': {
>                  'enabled': False
>              }
>          }, {
>              'name': 'ovirtmgmt',
>              'type': 'linux-bridge',
>              'state': 'up',
>              'mtu': 1500,
>              'bridge': {
>                  'port': [{
>                          'name': 'enp4s0.4000'
>                      }
>                  ],
>                  'options': {
>                      'stp': {
>                          'enabled': False
>                      }
>                  }
>              },
>              'ipv4': {
>                  'enabled': True,
>                  'address': [{
>                          'ip': '172.27.1.1',
>                          'prefix-length': 24
>                      }
>                  ],
>                  'dhcp': False
>              },
>              'ipv6': {
>                  'enabled': False
>              }
>          }
>      ],
>      'dns-resolver': {
>          'config'
>          : {
>              'server': ['213.133.98.98']
>          }
>      }
> }
>


Thanks, this is helpful information.
Can you please share the getCapabilities result sent from vdsm to 
Engine directly before the setupNetworks request,

and the parameters of the setupNetworks request from Engine to vdsm?
Both are in the vdsm.log during adding the host.

>
> This is my interfaces before vdsm attemtpts to change the config:
>
> enp4s0: flags=4163  mtu 1500
>      inet 144.76.84.73  netmask 255.255.255.255 broadcast
0.0.0.0
>      inet6 fe80::62a4:4cff:fee9:4ac  prefixlen 64 scopeid
0x20
>      inet6 2a01:4f8:192:1148::2  prefixlen 64 scopeid
0x0
>      ether 60:a4:4c:e9:04:ac  txqueuelen 1000 (Ethernet)
>      RX packets 293442  bytes 385541799 (367.6 MiB)
>    

[ovirt-users] Re: Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-03 Thread Sverker Abrahamsson via Users

Hi Strahil,
there is nothing wrong with the switch other than that I don't have any 
control over it so the network setup is as it is. The issue is that vdsm 
breaks the network setup because it's not flexible enough.


/Sverker

Den 2020-09-03 kl. 00:47, skrev Strahil Nikolov:

What is you switch brand & model ?
Maybe someone more experienced in networking can help.


Best Regards,
Strahil Nikolov






В сряда, 2 септември 2020 г., 23:39:57 Гринуич+3, Sverker Abrahamsson via Users 
 написа:





Well, unforturnatly I don't have a choise since it is out of my control.
I only have one physical network port where the external traffic is
untagged and the internal vlan is tagged. If I could run with OVN
instead I wouldn't need that tagged vlan, but I haven't been able to get
that to work neither.

It's perfectly possible to have both tagged and untagged traffic on the
same switch port, issue is that vdsm tries to take control over the
network without being able to be flexible enough.. I'm attempting now to
have ovirtmgmt bridge created before, that used to be possible but
according to previous mails on the list it went broken somewhere at 4.x.

/Sverker

Den 2020-09-02 kl. 21:39, skrev Strahil Nikolov:

Switchports can either be tagged or untagged.
I'm not sure that your setup is supported at all.

Best Regards,
Strahil Nikolov






В сряда, 2 септември 2020 г., 20:41:57 Гринуич+3, Sverker Abrahamsson via Users 
 написа:





Pretty formatting the "desired state" it seems that vdsm tries to remove
the ip of my underlying interface, that is enp4s0:

{
       'interfaces': [{
               'name': 'enp4s0',
               'state': 'up',
               'mtu': 1500
           }, {
               'vlan': {
                   'id': 4000,
                   'base-iface': 'enp4s0'
               },
               'name': 'enp4s0.4000',
               'type': 'vlan',
               'state': 'up',
               'mtu': 1500,
               'ipv4': {
                   'enabled': False
               },
               'ipv6': {
                   'enabled': False
               }
           }, {
               'name': 'ovirtmgmt',
               'type': 'linux-bridge',
               'state': 'up',
               'mtu': 1500,
               'bridge': {
                   'port': [{
                           'name': 'enp4s0.4000'
                       }
                   ],
                   'options': {
                       'stp': {
                           'enabled': False
                       }
                   }
               },
               'ipv4': {
                   'enabled': True,
                   'address': [{
                           'ip': '172.27.1.1',
                           'prefix-length': 24
                       }
                   ],
                   'dhcp': False
               },
               'ipv6': {
                   'enabled': False
               }
           }
       ],
       'dns-resolver': {
           'config'
           : {
               'server': ['213.133.98.98']
           }
       }
}


This is my interfaces before vdsm attemtpts to change the config:

enp4s0: flags=4163  mtu 1500
       inet 144.76.84.73  netmask 255.255.255.255  broadcast 0.0.0.0
       inet6 fe80::62a4:4cff:fee9:4ac  prefixlen 64  scopeid 0x20
       inet6 2a01:4f8:192:1148::2  prefixlen 64  scopeid 0x0
       ether 60:a4:4c:e9:04:ac  txqueuelen 1000  (Ethernet)
       RX packets 293442  bytes 385541799 (367.6 MiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 91095  bytes 31160348 (29.7 MiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
       device interrupt 17  memory 0xf7d0-f7d2

enp4s0.4000: flags=4163  mtu 1500
       inet 172.27.1.1  netmask 255.255.255.0  broadcast 172.27.1.255
       inet6 fe80::62a4:4cff:fee9:4ac  prefixlen 64  scopeid 0x20
       ether 60:a4:4c:e9:04:ac  txqueuelen 1000  (Ethernet)
       RX packets 0  bytes 0 (0.0 B)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 13  bytes 938 (938.0 B)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I.e. enp4s0 is the external interface that must not be changed, bridge
must be created on the vlan interface. I would prefer to create the
bridge manually and not through vdsm if that is possible.

/Sverker

Den 2020-09-02 kl. 19:14, skrev Sverker Abrahamsson via Users:

Hi,
I'm attempting to install hosted engine but getting this failure:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg":
"The host has been set in non_operational status, deployment errors:
code 505: Host h1-mgmt.limetransit.com installation failed. Failed to
configure management network on the host.,    code 1120: Failed to
configure management network on host h1-mgmt.limetransit.com due to
setup networks failure., code 9000: Failed to verify 

[ovirt-users] Re: Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-02 Thread Sverker Abrahamsson via Users
Well, unforturnatly I don't have a choise since it is out of my control. 
I only have one physical network port where the external traffic is 
untagged and the internal vlan is tagged. If I could run with OVN 
instead I wouldn't need that tagged vlan, but I haven't been able to get 
that to work neither.


It's perfectly possible to have both tagged and untagged traffic on the 
same switch port, issue is that vdsm tries to take control over the 
network without being able to be flexible enough.. I'm attempting now to 
have ovirtmgmt bridge created before, that used to be possible but 
according to previous mails on the list it went broken somewhere at 4.x.


/Sverker

Den 2020-09-02 kl. 21:39, skrev Strahil Nikolov:

Switchports can either be tagged or untagged.
I'm not sure that your setup is supported at all.

Best Regards,
Strahil Nikolov






В сряда, 2 септември 2020 г., 20:41:57 Гринуич+3, Sverker Abrahamsson via Users 
 написа:





Pretty formatting the "desired state" it seems that vdsm tries to remove
the ip of my underlying interface, that is enp4s0:

{
     'interfaces': [{
             'name': 'enp4s0',
             'state': 'up',
             'mtu': 1500
         }, {
             'vlan': {
                 'id': 4000,
                 'base-iface': 'enp4s0'
             },
             'name': 'enp4s0.4000',
             'type': 'vlan',
             'state': 'up',
             'mtu': 1500,
             'ipv4': {
                 'enabled': False
             },
             'ipv6': {
                 'enabled': False
             }
         }, {
             'name': 'ovirtmgmt',
             'type': 'linux-bridge',
             'state': 'up',
             'mtu': 1500,
             'bridge': {
                 'port': [{
                         'name': 'enp4s0.4000'
                     }
                 ],
                 'options': {
                     'stp': {
                         'enabled': False
                     }
                 }
             },
             'ipv4': {
                 'enabled': True,
                 'address': [{
                         'ip': '172.27.1.1',
                         'prefix-length': 24
                     }
                 ],
                 'dhcp': False
             },
             'ipv6': {
                 'enabled': False
             }
         }
     ],
     'dns-resolver': {
         'config'
         : {
             'server': ['213.133.98.98']
         }
     }
}


This is my interfaces before vdsm attemtpts to change the config:

enp4s0: flags=4163  mtu 1500
     inet 144.76.84.73  netmask 255.255.255.255  broadcast 0.0.0.0
     inet6 fe80::62a4:4cff:fee9:4ac  prefixlen 64  scopeid 0x20
     inet6 2a01:4f8:192:1148::2  prefixlen 64  scopeid 0x0
     ether 60:a4:4c:e9:04:ac  txqueuelen 1000  (Ethernet)
     RX packets 293442  bytes 385541799 (367.6 MiB)
     RX errors 0  dropped 0  overruns 0  frame 0
     TX packets 91095  bytes 31160348 (29.7 MiB)
     TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
     device interrupt 17  memory 0xf7d0-f7d2

enp4s0.4000: flags=4163  mtu 1500
     inet 172.27.1.1  netmask 255.255.255.0  broadcast 172.27.1.255
     inet6 fe80::62a4:4cff:fee9:4ac  prefixlen 64  scopeid 0x20
     ether 60:a4:4c:e9:04:ac  txqueuelen 1000  (Ethernet)
     RX packets 0  bytes 0 (0.0 B)
     RX errors 0  dropped 0  overruns 0  frame 0
     TX packets 13  bytes 938 (938.0 B)
     TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I.e. enp4s0 is the external interface that must not be changed, bridge
must be created on the vlan interface. I would prefer to create the
bridge manually and not through vdsm if that is possible.

/Sverker

Den 2020-09-02 kl. 19:14, skrev Sverker Abrahamsson via Users:

Hi,
I'm attempting to install hosted engine but getting this failure:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg":
"The host has been set in non_operational status, deployment errors:
code 505: Host h1-mgmt.limetransit.com installation failed. Failed to
configure management network on the host.,    code 1120: Failed to
configure management network on host h1-mgmt.limetransit.com due to
setup networks failure., code 9000: Failed to verify Power Management
configuration for Host h1-mgmt.limetransit.com.,    code 10802: VDSM
h1-mgmt.limetransit.com command HostSetupNetworksVDS failed: Internal
JSON-RPC error: {'reason': 'Unexpected failure of libnm when running
the mainloop: run execution'},   fix accordingly and re-deploy."}

Looking in vdsm.log I find this which I believe is the root cause:

MainProcess|jsonrpc/0::DEBUG::2020-09-02
16:38:25,897::supervdsm_server::93::SuperVdsm.ServerCallback::(wrapper)
call setupNetworks with ({'ovirtmgmt': {'vlan': '4000', 'netmask':
'255.255.255.0', 'ipv6autoconf': False,
'nic': 'enp4s0', 'bridged': 'true', 'ipaddr': '172.27.

[ovirt-users] Hosted engine + OVN

2020-09-02 Thread Sverker Abrahamsson via Users
Was it ever solved to install hosted engine with ovn? I tried a few 
years ago, got it almost to work but then gave up.

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/6KWV2MKV6E3ABQL6DGKVJ7FZTGNG3JPK/


[ovirt-users] Re: Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-02 Thread Sverker Abrahamsson via Users
Pretty formatting the "desired state" it seems that vdsm tries to remove 
the ip of my underlying interface, that is enp4s0:


{
    'interfaces': [{
            'name': 'enp4s0',
            'state': 'up',
            'mtu': 1500
        }, {
            'vlan': {
                'id': 4000,
                'base-iface': 'enp4s0'
            },
            'name': 'enp4s0.4000',
            'type': 'vlan',
            'state': 'up',
            'mtu': 1500,
            'ipv4': {
                'enabled': False
            },
            'ipv6': {
                'enabled': False
            }
        }, {
            'name': 'ovirtmgmt',
            'type': 'linux-bridge',
            'state': 'up',
            'mtu': 1500,
            'bridge': {
                'port': [{
                        'name': 'enp4s0.4000'
                    }
                ],
                'options': {
                    'stp': {
                        'enabled': False
                    }
                }
            },
            'ipv4': {
                'enabled': True,
                'address': [{
                        'ip': '172.27.1.1',
                        'prefix-length': 24
                    }
                ],
                'dhcp': False
            },
            'ipv6': {
                'enabled': False
            }
        }
    ],
    'dns-resolver': {
        'config'
        : {
            'server': ['213.133.98.98']
        }
    }
}


This is my interfaces before vdsm attemtpts to change the config:

enp4s0: flags=4163  mtu 1500
    inet 144.76.84.73  netmask 255.255.255.255  broadcast 0.0.0.0
    inet6 fe80::62a4:4cff:fee9:4ac  prefixlen 64  scopeid 0x20
    inet6 2a01:4f8:192:1148::2  prefixlen 64  scopeid 0x0
    ether 60:a4:4c:e9:04:ac  txqueuelen 1000  (Ethernet)
    RX packets 293442  bytes 385541799 (367.6 MiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 91095  bytes 31160348 (29.7 MiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    device interrupt 17  memory 0xf7d0-f7d2

enp4s0.4000: flags=4163  mtu 1500
    inet 172.27.1.1  netmask 255.255.255.0  broadcast 172.27.1.255
    inet6 fe80::62a4:4cff:fee9:4ac  prefixlen 64  scopeid 0x20
    ether 60:a4:4c:e9:04:ac  txqueuelen 1000  (Ethernet)
    RX packets 0  bytes 0 (0.0 B)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 13  bytes 938 (938.0 B)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I.e. enp4s0 is the external interface that must not be changed, bridge 
must be created on the vlan interface. I would prefer to create the 
bridge manually and not through vdsm if that is possible.


/Sverker

Den 2020-09-02 kl. 19:14, skrev Sverker Abrahamsson via Users:

Hi,
I'm attempting to install hosted engine but getting this failure:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": 
"The host has been set in non_operational status, deployment errors:   
code 505: Host h1-mgmt.limetransit.com installation failed. Failed to 
configure management network on the host.,    code 1120: Failed to 
configure management network on host h1-mgmt.limetransit.com due to 
setup networks failure., code 9000: Failed to verify Power Management 
configuration for Host h1-mgmt.limetransit.com.,    code 10802: VDSM 
h1-mgmt.limetransit.com command HostSetupNetworksVDS failed: Internal 
JSON-RPC error: {'reason': 'Unexpected failure of libnm when running 
the mainloop: run execution'},   fix accordingly and re-deploy."}


Looking in vdsm.log I find this which I believe is the root cause:

MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,897::supervdsm_server::93::SuperVdsm.ServerCallback::(wrapper) 
call setupNetworks with ({'ovirtmgmt': {'vlan': '4000', 'netmask': 
'255.255.255.0', 'ipv6autoconf': False,
'nic': 'enp4s0', 'bridged': 'true', 'ipaddr': '172.27.1.1', 
'defaultRoute': True, 'dhcpv6': False, 'STP': 'no', 'mtu': 1500, 
'switch': 'legacy'}}, {}, {'connectivityTimeout': 120, 
'commitOnSuccess': True, 'connectivityCh

eck': 'true'}) {}
MainProcess|jsonrpc/0::INFO::2020-09-02 
16:38:25,897::api::220::root::(setupNetworks) Setting up network 
according to configuration: networks:{'ovirtmgmt': {'vlan': '4000', 
'netmask': '255.255.255.0', 'ipv6autoconf': Fal
se, 'nic': 'enp4s0', 'bridged': 'true', 'ipaddr': '172.27.1.1', 
'defaultRoute': True, 'dhcpv6': False, 'STP': 'no', 'mtu': 1500, 
'switch': 'legacy'}}, bondings:{}, options:{'connectivityTimeout': 
120, 'commitOnSuccess':

True, 'connectivityCheck': 'true'}
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,902::cmdutils::130::root::(exec_cmd) /sbin/tc qdisc show (cwd 
None)
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,906::cmdutils::138::root::(exec_cmd) SUCCESS:  = b''; 
 = 0
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,945::vsctl::74::root::(commit) Executing commands

[ovirt-users] Hosted engine install failure: ipv6.gateway: gateway cannot be set if there are no addresses configured

2020-09-02 Thread Sverker Abrahamsson via Users

Hi,
I'm attempting to install hosted engine but getting this failure:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The 
host has been set in non_operational status, deployment errors:   code 
505: Host h1-mgmt.limetransit.com installation failed. Failed to 
configure management network on the host.,    code 1120: Failed to 
configure management network on host h1-mgmt.limetransit.com due to 
setup networks failure., code 9000: Failed to verify Power Management 
configuration for Host h1-mgmt.limetransit.com.,    code 10802: VDSM 
h1-mgmt.limetransit.com command HostSetupNetworksVDS failed: Internal 
JSON-RPC error: {'reason': 'Unexpected failure of libnm when running the 
mainloop: run execution'},   fix accordingly and re-deploy."}


Looking in vdsm.log I find this which I believe is the root cause:

MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,897::supervdsm_server::93::SuperVdsm.ServerCallback::(wrapper) 
call setupNetworks with ({'ovirtmgmt': {'vlan': '4000', 'netmask': 
'255.255.255.0', 'ipv6autoconf': False,
'nic': 'enp4s0', 'bridged': 'true', 'ipaddr': '172.27.1.1', 
'defaultRoute': True, 'dhcpv6': False, 'STP': 'no', 'mtu': 1500, 
'switch': 'legacy'}}, {}, {'connectivityTimeout': 120, 
'commitOnSuccess': True, 'connectivityCh

eck': 'true'}) {}
MainProcess|jsonrpc/0::INFO::2020-09-02 
16:38:25,897::api::220::root::(setupNetworks) Setting up network 
according to configuration: networks:{'ovirtmgmt': {'vlan': '4000', 
'netmask': '255.255.255.0', 'ipv6autoconf': Fal
se, 'nic': 'enp4s0', 'bridged': 'true', 'ipaddr': '172.27.1.1', 
'defaultRoute': True, 'dhcpv6': False, 'STP': 'no', 'mtu': 1500, 
'switch': 'legacy'}}, bondings:{}, options:{'connectivityTimeout': 120, 
'commitOnSuccess':

True, 'connectivityCheck': 'true'}
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,902::cmdutils::130::root::(exec_cmd) /sbin/tc qdisc show (cwd None)
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,906::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,945::vsctl::74::root::(commit) Executing commands: 
/usr/bin/ovs-vsctl --timeout=5 --oneline --format=json -- list Bridge -- 
list Port -- list Interface
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,945::cmdutils::130::root::(exec_cmd) /usr/bin/ovs-vsctl 
--timeout=5 --oneline --format=json -- list Bridge -- list Port -- list 
Interface (cwd None)
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,952::cmdutils::138::root::(exec_cmd) SUCCESS:  = b'';  = 0
MainProcess|jsonrpc/0::INFO::2020-09-02 
16:38:25,957::netconfpersistence::58::root::(setNetwork) Adding network 
ovirtmgmt({'vlan': 4000, 'netmask': '255.255.255.0', 'ipv6autoconf': 
False, 'nic': 'enp4s0', 'bridged': True
, 'ipaddr': '172.27.1.1', 'defaultRoute': True, 'dhcpv6': False, 'mtu': 
1500, 'switch': 'legacy', 'stp': False, 'bootproto': 'none', 
'nameservers': ['213.133.98.98']})
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:25,958::commands::153::common.commands::(start) /usr/bin/taskset 
--cpu-list 0-7 /usr/libexec/vdsm/hooks/before_network_setup/50_fcoe (cwd 
None)
MainProcess|jsonrpc/0::INFO::2020-09-02 
16:38:26,154::hooks::122::root::(_runHooksDir) 
/usr/libexec/vdsm/hooks/before_network_setup/50_fcoe: rc=0 err=b''
MainProcess|jsonrpc/0::INFO::2020-09-02 
16:38:26,155::configurator::195::root::(_setup_nmstate) Processing setup 
through nmstate
MainProcess|jsonrpc/0::INFO::2020-09-02 
16:38:26,175::configurator::197::root::(_setup_nmstate) Desired state: 
{'interfaces': [{'name': 'enp4s0', 'state': 'up', 'mtu': 1500}, {'vlan': 
{'id': 4000, 'base-iface': 'enp4s0'}
, 'name': 'enp4s0.4000', 'type': 'vlan', 'state': 'up', 'mtu': 1500, 
'ipv4': {'enabled': False}, 'ipv6': {'enabled': False}}, {'name': 
'ovirtmgmt', 'type': 'linux-bridge', 'state': 'up', 'mtu': 1500, 
'bridge': {'port': [
{'name': 'enp4s0.4000'}], 'options': {'stp': {'enabled': False}}}, 
'ipv4': {'enabled': True, 'address': [{'ip': '172.27.1.1', 
'prefix-length': 24}], 'dhcp': False}, 'ipv6': {'enabled': False}}], 
'dns-resolver': {'config'

: {'server': ['213.133.98.98']}}}
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:26,217::checkpoint::121::root::(create) Checkpoint 
/org/freedesktop/NetworkManager/Checkpoint/1 created for all devices: 60
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:26,218::netapplier::239::root::(_add_interfaces) Adding new 
interfaces: ['ovirtmgmt']
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:26,221::netapplier::251::root::(_edit_interfaces) Editing 
interfaces: ['enp4s0.4000', 'enp4s0']
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:26,224::nmclient::136::root::(execute_next_action) Executing NM 
action: func=add_connection_async
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:26,231::connection::329::root::(_add_connection_callback) 
Connection adding succeeded: dev=ovirtmgmt
MainProcess|jsonrpc/0::DEBUG::2020-09-02 
16:38:26,232::nmclient::136::root::(execute_next_action) Executing NM 
action: