Upgrade ovirt from 3.4 to 4.3
by lu.alfonsi＠almaviva.it
Good morning,
i have a difficult enviroment with 20 Hypervisors based on ovirt 3.4.3-1 and i would like to reach the 4.3 version. Which are the best steps to achieve these objective?
Thanks in advance
Luigi
5 years
KeyCloak Integration
by Anton Louw
Hi Everybody,
So I have implemented KeyCloak into our oVirt environment, which works, up until a point. So WebUI access works, but when calling the API, using:
curl -k -H "Accept: application/json" 'https://virt.example.co.za/ovirt-engine/sso/oauth/token?grant_type=passwo...'
I get the below error:
{"error_description":"Cannot authenticate user Invalid scopes: ovirt-app-api ovirt-ext=revoke:revoke-all ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=token:password-access.","error":"access_denied"}
If my configs are removed, and I use "admin@internal" for my username, then it works.
I followed the below article step by step, and I double checked that all the scopes are added into KeyCloak (ovirt-app-api and ovirt-app-admin)
https://blogs.ovirt.org/2019/01/federate-ovirt-engine-authentication-to-o...
Anybody have any ideas?
Thank you
Anton Louw
Cloud Engineer: Storage and Virtualization
______________________________________
D: 087 805 1572 | M: N/A
A: Rutherford Estate, 1 Scott Street, Waverley, Johannesburg
anton.louw(a)voxtelecom.co.za
www.vox.co.za
5 years
Update to Ovirt 4.3.10-4-1 causes XFS issue
by Chaz Vidal
Hi All
I think I have come across this bug:
https://access.redhat.com/solutions/5075561
Updating Ovirt to 4.3.10 shows that the kernel installed on the hosts is the version that has the issue:
3.10.0-1127.8.2.el7.x86_64
The RedHat article suggests updating to kernel-3.10.0-1127.10.1.el7 but running engine-upgrade-check now shows no updates available from my engine manager.
Is this something I can fix myself or would the updated kernel be available?
Appreciate the advice as new to Ovirt. Normally I would point the hosts to the new kernel but I think it should be updated through Ovirt manager, correct?
Thanks!
Chaz
5 years
Host has time-drift of xxx seconds
by Strahil Nikolov
Hello All,
I have a strange error that should be fixed but the event log is still filling with the following after the latest patching (4.3.10):
Host ovirt2.localdomain has time-drift of 2909848 seconds while maximum configured value is 300 seconds.
Host ovirt3.localdomain has time-drift of 2909848 seconds while maximum configured value is 300 seconds.
As it blamed only 2 out of 3 systems, I checked what has happened on ovirt1 and that one was far behind the other servers.
Once I fixed the issue, I kept receiving those errors despite tthe fact that I fixed the time drift on ovirt1 several days ago.
Currently the hosts and the engine are OK, but I got no idea how to 'fix' the issue.
I have also noticed that the 2 errors had a date of 2 PM which is not possible with my current timezone.
Here is a one-shot query from all nodes:
[root@ovirt1 ~]# for i in ovirt{1..3}; do ssh $i "ntpdate -q office.ipacct.com"; done
server 195.85.215.8, stratum 1, offset 0.001233, delay 0.03105
11 Jun 05:48:16 ntpdate[5224]: adjust time server 195.85.215.8 offset 0.001233 sec
server 195.85.215.8, stratum 1, offset -0.000200, delay 0.02821
11 Jun 05:48:23 ntpdate[6637]: adjust time server 195.85.215.8 offset -0.000200 sec
server 195.85.215.8, stratum 1, offset 0.000243, delay 0.02914
11 Jun 05:48:30 ntpdate[14215]: adjust time server 195.85.215.8 offset 0.000243 sec
[root@ovirt1 ~]# ssh engine 'ntpdate -q office.ipacct.com'
root@engine's password:
server 195.85.215.8, stratum 1, offset 0.000291, delay 0.02888
11 Jun 05:49:15 ntpdate[13911]: adjust time server 195.85.215.8 offset 0.000291 sec
Any ideas ?
Best Regards,
Strahil Nikolov
5 years
Fwd: Issues with Gluster Domain
by C Williams
Resending to deal with possible email issues
---------- Forwarded message ---------
From: C Williams <cwilliams3320(a)gmail.com>
Date: Thu, Jun 18, 2020 at 2:07 PM
Subject: Re: [ovirt-users] Issues with Gluster Domain
To: Strahil Nikolov <hunter86_bg(a)yahoo.com>
More
[root@ov06 ~]# for i in $(gluster volume list); do echo $i;echo; gluster
volume info $i; echo;echo;gluster volume status $i;echo;echo;echo;done
images3
Volume Name: images3
Type: Replicate
Volume ID: 0243d439-1b29-47d0-ab39-d61c2f15ae8b
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: 192.168.24.18:/bricks/brick04/images3
Brick2: 192.168.24.19:/bricks/brick05/images3
Brick3: 192.168.24.20:/bricks/brick06/images3
Options Reconfigured:
performance.client-io-threads: on
nfs.disable: on
transport.address-family: inet
user.cifs: off
auth.allow: *
performance.quick-read: off
performance.read-ahead: off
performance.io-cache: off
performance.low-prio-threads: 32
network.remote-dio: off
cluster.eager-lock: enable
cluster.quorum-type: auto
cluster.server-quorum-type: server
cluster.data-self-heal-algorithm: full
cluster.locking-scheme: granular
cluster.shd-max-threads: 8
cluster.shd-wait-qlength: 10000
features.shard: on
cluster.choose-local: off
client.event-threads: 4
server.event-threads: 4
storage.owner-uid: 36
storage.owner-gid: 36
performance.strict-o-direct: on
network.ping-timeout: 30
cluster.granular-entry-heal: enable
Status of volume: images3
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.24.18:/bricks/brick04/images3 49152 0 Y
6666
Brick 192.168.24.19:/bricks/brick05/images3 49152 0 Y
6779
Brick 192.168.24.20:/bricks/brick06/images3 49152 0 Y
7227
Self-heal Daemon on localhost N/A N/A Y
6689
Self-heal Daemon on ov07.ntc.srcle.com N/A N/A Y
6802
Self-heal Daemon on ov08.ntc.srcle.com N/A N/A Y
7250
Task Status of Volume images3
------------------------------------------------------------------------------
There are no active volume tasks
[root@ov06 ~]# ls -l /rhev/data-center/mnt/glusterSD/
total 16
drwxr-xr-x. 5 vdsm kvm 8192 Jun 18 14:04 192.168.24.15:_images
drwxr-xr-x. 5 vdsm kvm 8192 Jun 18 14:05 192.168.24.18:_images3
[root@ov06 ~]#
On Thu, Jun 18, 2020 at 2:03 PM C Williams <cwilliams3320(a)gmail.com> wrote:
> Strahil,
>
> Here you go -- Thank You For Your Help !
>
> BTW -- I can write a test file to gluster and it replicates properly.
> Thinking something about the oVirt Storage Domain ?
>
> [root@ov08 ~]# gluster pool list
> UUID Hostname State
> 5b40c659-d9ab-43c3-9af8-18b074ea0b83 ov06 Connected
> 36ce5a00-6f65-4926-8438-696944ebadb5 ov07.ntc.srcle.com Connected
> c7e7abdb-a8f4-4842-924c-e227f0db1b29 localhost Connected
> [root@ov08 ~]# gluster volume list
> images3
>
> On Thu, Jun 18, 2020 at 1:13 PM Strahil Nikolov <hunter86_bg(a)yahoo.com>
> wrote:
>
>> Log to the oVirt cluster and provide the output of:
>> gluster pool list
>> gluster volume list
>> for i in $(gluster volume list); do echo $i;echo; gluster volume info
>> $i; echo;echo;gluster volume status $i;echo;echo;echo;done
>>
>> ls -l /rhev/data-center/mnt/glusterSD/
>>
>> Best Regards,
>> Strahil Nikolov
>>
>>
>> На 18 юни 2020 г. 19:17:46 GMT+03:00, C Williams <cwilliams3320(a)gmail.com>
>> написа:
>> >Hello,
>> >
>> >I recently added 6 hosts to an existing oVirt compute/gluster cluster.
>> >
>> >Prior to this attempted addition, my cluster had 3 Hypervisor hosts and
>> >3
>> >gluster bricks which made up a single gluster volume (replica 3 volume)
>> >. I
>> >added the additional hosts and made a brick on 3 of the new hosts and
>> >attempted to make a new replica 3 volume. I had difficulty creating
>> >the
>> >new volume. So, I decided that I would make a new compute/gluster
>> >cluster
>> >for each set of 3 new hosts.
>> >
>> >I removed the 6 new hosts from the existing oVirt Compute/Gluster
>> >Cluster
>> >leaving the 3 original hosts in place with their bricks. At that point
>> >my
>> >original bricks went down and came back up . The volume showed entries
>> >that
>> >needed healing. At that point I ran gluster volume heal images3 full,
>> >etc.
>> >The volume shows no unhealed entries. I also corrected some peer
>> >errors.
>> >
>> >However, I am unable to copy disks, move disks to another domain,
>> >export
>> >disks, etc. It appears that the engine cannot locate disks properly and
>> >I
>> >get storage I/O errors.
>> >
>> >I have detached and removed the oVirt Storage Domain. I reimported the
>> >domain and imported 2 VMs, But the VM disks exhibit the same behaviour
>> >and
>> >won't run from the hard disk.
>> >
>> >
>> >I get errors such as this
>> >
>> >VDSM ov05 command HSMGetAllTasksStatusesVDS failed: low level Image
>> >copy
>> >failed: ("Command ['/usr/bin/qemu-img', 'convert', '-p', '-t', 'none',
>> >'-T', 'none', '-f', 'raw',
>> >u'/rhev/data-center/mnt/glusterSD/192.168.24.18:
>> _images3/5fe3ad3f-2d21-404c-832e-4dc7318ca10d/images/3ea5afbd-0fe0-4c09-8d39-e556c66a8b3d/fe6eab63-3b22-4815-bfe6-4a0ade292510',
>> >'-O', 'raw',
>> >u'/rhev/data-center/mnt/192.168.24.13:
>> _stor_import1/1ab89386-a2ba-448b-90ab-bc816f55a328/images/f707a218-9db7-4e23-8bbd-9b12972012b6/d6591ec5-3ede-443d-bd40-93119ca7c7d5']
>> >failed with rc=1 out='' err=bytearray(b'qemu-img: error while reading
>> >sector 135168: Transport endpoint is not connected\\nqemu-img: error
>> >while
>> >reading sector 131072: Transport endpoint is not connected\\nqemu-img:
>> >error while reading sector 139264: Transport endpoint is not
>> >connected\\nqemu-img: error while reading sector 143360: Transport
>> >endpoint
>> >is not connected\\nqemu-img: error while reading sector 147456:
>> >Transport
>> >endpoint is not connected\\nqemu-img: error while reading sector
>> >155648:
>> >Transport endpoint is not connected\\nqemu-img: error while reading
>> >sector
>> >151552: Transport endpoint is not connected\\nqemu-img: error while
>> >reading
>> >sector 159744: Transport endpoint is not connected\\n')",)
>> >
>> >oVirt version is 4.3.82-1.el7
>> >OS CentOS Linux release 7.7.1908 (Core)
>> >
>> >The Gluster Cluster has been working very well until this incident.
>> >
>> >Please help.
>> >
>> >Thank You
>> >
>> >Charles Williams
>>
>
5 years
Fwd: Issues with Gluster Domain
by C Williams
Resending to deal with possible email issues
Thank You For Your Help !!
---------- Forwarded message ---------
From: C Williams <cwilliams3320(a)gmail.com>
Date: Thu, Jun 18, 2020 at 2:03 PM
Subject: Re: [ovirt-users] Issues with Gluster Domain
To: Strahil Nikolov <hunter86_bg(a)yahoo.com>
Strahil,
Here you go -- Thank You For Your Help !
BTW -- I can write a test file to gluster and it replicates properly.
Thinking something about the oVirt Storage Domain ?
[root@ov08 ~]# gluster pool list
UUID Hostname State
5b40c659-d9ab-43c3-9af8-18b074ea0b83 ov06 Connected
36ce5a00-6f65-4926-8438-696944ebadb5 ov07.ntc.srcle.com Connected
c7e7abdb-a8f4-4842-924c-e227f0db1b29 localhost Connected
[root@ov08 ~]# gluster volume list
images3
On Thu, Jun 18, 2020 at 1:13 PM Strahil Nikolov <hunter86_bg(a)yahoo.com>
wrote:
> Log to the oVirt cluster and provide the output of:
> gluster pool list
> gluster volume list
> for i in $(gluster volume list); do echo $i;echo; gluster volume info
> $i; echo;echo;gluster volume status $i;echo;echo;echo;done
>
> ls -l /rhev/data-center/mnt/glusterSD/
>
> Best Regards,
> Strahil Nikolov
>
>
> На 18 юни 2020 г. 19:17:46 GMT+03:00, C Williams <cwilliams3320(a)gmail.com>
> написа:
> >Hello,
> >
> >I recently added 6 hosts to an existing oVirt compute/gluster cluster.
> >
> >Prior to this attempted addition, my cluster had 3 Hypervisor hosts and
> >3
> >gluster bricks which made up a single gluster volume (replica 3 volume)
> >. I
> >added the additional hosts and made a brick on 3 of the new hosts and
> >attempted to make a new replica 3 volume. I had difficulty creating
> >the
> >new volume. So, I decided that I would make a new compute/gluster
> >cluster
> >for each set of 3 new hosts.
> >
> >I removed the 6 new hosts from the existing oVirt Compute/Gluster
> >Cluster
> >leaving the 3 original hosts in place with their bricks. At that point
> >my
> >original bricks went down and came back up . The volume showed entries
> >that
> >needed healing. At that point I ran gluster volume heal images3 full,
> >etc.
> >The volume shows no unhealed entries. I also corrected some peer
> >errors.
> >
> >However, I am unable to copy disks, move disks to another domain,
> >export
> >disks, etc. It appears that the engine cannot locate disks properly and
> >I
> >get storage I/O errors.
> >
> >I have detached and removed the oVirt Storage Domain. I reimported the
> >domain and imported 2 VMs, But the VM disks exhibit the same behaviour
> >and
> >won't run from the hard disk.
> >
> >
> >I get errors such as this
> >
> >VDSM ov05 command HSMGetAllTasksStatusesVDS failed: low level Image
> >copy
> >failed: ("Command ['/usr/bin/qemu-img', 'convert', '-p', '-t', 'none',
> >'-T', 'none', '-f', 'raw',
> >u'/rhev/data-center/mnt/glusterSD/192.168.24.18:
> _images3/5fe3ad3f-2d21-404c-832e-4dc7318ca10d/images/3ea5afbd-0fe0-4c09-8d39-e556c66a8b3d/fe6eab63-3b22-4815-bfe6-4a0ade292510',
> >'-O', 'raw',
> >u'/rhev/data-center/mnt/192.168.24.13:
> _stor_import1/1ab89386-a2ba-448b-90ab-bc816f55a328/images/f707a218-9db7-4e23-8bbd-9b12972012b6/d6591ec5-3ede-443d-bd40-93119ca7c7d5']
> >failed with rc=1 out='' err=bytearray(b'qemu-img: error while reading
> >sector 135168: Transport endpoint is not connected\\nqemu-img: error
> >while
> >reading sector 131072: Transport endpoint is not connected\\nqemu-img:
> >error while reading sector 139264: Transport endpoint is not
> >connected\\nqemu-img: error while reading sector 143360: Transport
> >endpoint
> >is not connected\\nqemu-img: error while reading sector 147456:
> >Transport
> >endpoint is not connected\\nqemu-img: error while reading sector
> >155648:
> >Transport endpoint is not connected\\nqemu-img: error while reading
> >sector
> >151552: Transport endpoint is not connected\\nqemu-img: error while
> >reading
> >sector 159744: Transport endpoint is not connected\\n')",)
> >
> >oVirt version is 4.3.82-1.el7
> >OS CentOS Linux release 7.7.1908 (Core)
> >
> >The Gluster Cluster has been working very well until this incident.
> >
> >Please help.
> >
> >Thank You
> >
> >Charles Williams
>
5 years
Issues with Gluster Domain
by C Williams
Hello,
I recently added 6 hosts to an existing oVirt compute/gluster cluster.
Prior to this attempted addition, my cluster had 3 Hypervisor hosts and 3
gluster bricks which made up a single gluster volume (replica 3 volume) . I
added the additional hosts and made a brick on 3 of the new hosts and
attempted to make a new replica 3 volume. I had difficulty creating the
new volume. So, I decided that I would make a new compute/gluster cluster
for each set of 3 new hosts.
I removed the 6 new hosts from the existing oVirt Compute/Gluster Cluster
leaving the 3 original hosts in place with their bricks. At that point my
original bricks went down and came back up . The volume showed entries that
needed healing. At that point I ran gluster volume heal images3 full, etc.
The volume shows no unhealed entries. I also corrected some peer errors.
However, I am unable to copy disks, move disks to another domain, export
disks, etc. It appears that the engine cannot locate disks properly and I
get storage I/O errors.
I have detached and removed the oVirt Storage Domain. I reimported the
domain and imported 2 VMs, But the VM disks exhibit the same behaviour and
won't run from the hard disk.
I get errors such as this
VDSM ov05 command HSMGetAllTasksStatusesVDS failed: low level Image copy
failed: ("Command ['/usr/bin/qemu-img', 'convert', '-p', '-t', 'none',
'-T', 'none', '-f', 'raw',
u'/rhev/data-center/mnt/glusterSD/192.168.24.18:_images3/5fe3ad3f-2d21-404c-832e-4dc7318ca10d/images/3ea5afbd-0fe0-4c09-8d39-e556c66a8b3d/fe6eab63-3b22-4815-bfe6-4a0ade292510',
'-O', 'raw', u'/rhev/data-center/mnt/192.168.24.13:_stor_import1/1ab89386-a2ba-448b-90ab-bc816f55a328/images/f707a218-9db7-4e23-8bbd-9b12972012b6/d6591ec5-3ede-443d-bd40-93119ca7c7d5']
failed with rc=1 out='' err=bytearray(b'qemu-img: error while reading
sector 135168: Transport endpoint is not connected\\nqemu-img: error while
reading sector 131072: Transport endpoint is not connected\\nqemu-img:
error while reading sector 139264: Transport endpoint is not
connected\\nqemu-img: error while reading sector 143360: Transport endpoint
is not connected\\nqemu-img: error while reading sector 147456: Transport
endpoint is not connected\\nqemu-img: error while reading sector 155648:
Transport endpoint is not connected\\nqemu-img: error while reading sector
151552: Transport endpoint is not connected\\nqemu-img: error while reading
sector 159744: Transport endpoint is not connected\\n')",)
oVirt version is 4.3.82-1.el7
OS CentOS Linux release 7.7.1908 (Core)
The Gluster Cluster has been working very well until this incident.
Please help.
Thank You
Charles Williams
5 years
Ovirt fails to retrieve iSCSI targets during installation
by Ricardo Alonso
Trying to connect to a an iSCSI target (no chap/secrets) is failing with the message:
2020-06-17 05:25:40,050-0300 ERROR ansible failed {
"ansible_host": "localhost",
"ansible_playbook": "/usr/share/ovirt-hosted-engine-setup/ansible/trigger_role.yml",
"ansible_result": {
"_ansible_no_log": false,
"changed": false,
"connection": "close",
"content": "{\n \"detail\" : \"For correct usage, see: https://ovirt.<removed>/ovirt-engine/apidoc#services/host/methods/iscsi_discover\",\n \"reason\" : \"Request syntactically incorrect.\"\n}",
"content_encoding": "identity",
"content_type": "application/json",
"correlation_id": "a5ba94a7-b22b-4ed6-9a47-87a87186c341",
"date": "Wed, 17 Jun 2020 08:25:38 GMT",
"elapsed": 0,
"invocation": {
"module_args": {
"attributes": null,
"backup": null,
"body": "{\"iscsi\": {\"address\": \"192.168.6.1\", \"port\": \"3260,3260\", \"username\": null, \"password\": \"\"}}",
"body_format": "json",
"client_cert": null,
"client_key": null,
"content": null,
"creates": null,
"delimiter": null,
"dest": null,
"directory_mode": null,
"follow": false,
"follow_redirects": "safe",
"force": false,
"force_basic_auth": false,
"group": null,
"headers": {
"Accept": "application/json",
"Authorization": "Basic YWRtaW5AaW50ZXJuYWw6cGQyMDAx",
"Content-Type": "application/json"
},
"http_agent": "ansible-httpget",
"method": "POST",
"mode": null,
"owner": null,
"regexp": null,
"remote_src": null,
"removes": null,
"return_content": true,
"selevel": null,
"serole": null,
"setype": null,
"seuser": null,
"src": null,
"status_code": [
"200"
],
"timeout": 30,
"unix_socket": null,
"unsafe_writes": null,
"url": "https://ovirt.<removed>/ovirt-engine/api/hosts/2c173b7f-9f9e-4046-890a-ab16d1babc35/iscsidiscover",
"url_password": null,
"url_username": null,
"use_proxy": true,
"validate_certs": false
}
},
"json": {
"detail": "For correct usage, see: https://ovirt.<removed>/ovirt-engine/apidoc#services/host/methods/iscsi_discover",
"reason": "Request syntactically incorrect."
},
"msg": "Status code was 400 and not [200]: HTTP Error 400: Bad Request",
"redirected": false,
"server": "Apache/2.4.37 (centos) OpenSSL/1.1.1c mod_wsgi/4.6.4 Python/3.6",
"status": 400,
"transfer_encoding": "chunked",
"url": "https://ovirt.<removed>/ovirt-engine/api/hosts/2c173b7f-9f9e-4046-890a-ab16d1babc35/iscsidiscover"
},
"ansible_task": "iSCSI discover with REST API",
"ansible_type": "task",
"status": "FAILED",
"task_duration": 4
}
I found this old bug, but doesn't seams to have a resolution. Any clue/tips?
5 years
Re: Cannot authenticate user Invalid scopes: ovirt-app-api
by Anton Louw
So I think I have narrowed it down to the OVN settings. The only problem now is, is that when I want to update the OVN settings, it fails with “Failed to communicate with External Provider. See logs for details”
When checking the logs, I see an error stating the “root hostname does not match” (In the OVN settings via the WebUI, I see that it also points to the old hostname)
A bit of background on this, when the engine was initially built, it was configured with a different hostname, which was then changed, but somehow it is still referencing the old hostname. When I run the change hostname scripts (/usr/share/ovirt-engine/setup/bin/ovirt-engine-rename) it runs through everything, until it needs to modify the certs. (I have attached the screenshot)
I am really not sure where to go from here, and I believe that most of this has to do with the certs (And I am just grasping at straws here)
I am starting to think that it would just be easier to deploy everything from scratch, but if anybody has any ideas, I would appreciate it.
Thank you
Anton Louw
Cloud Engineer: Storage and Virtualization
______________________________________
D: 087 805 1572 | M: N/A
A: Rutherford Estate, 1 Scott Street, Waverley, Johannesburg
anton.louw(a)voxtelecom.co.za
www.vox.co.za
From: Anton Louw via Users <users(a)ovirt.org>
Sent: 18 June 2020 12:39
To: users(a)ovirt.org
Subject: [ovirt-users] Cannot authenticate user Invalid scopes: ovirt-app-api
Hi All,
A new issue 😊
We have configured oVirt to use KeyCloak for authentication. This all works, I can log into the WebUI etc, but as soon as I need to talk to the API, it gives me the “invalid scopes” error. I have double checked KeyCloak, and the scopes are added. I went through the logs, but there is nothing telling me exactly what the actual cause is.
I get the below when trying to get a token from the engine:
“{"error_code":"access_denied","error":"Cannot authenticate user Invalid scopes: ovirt-app-api ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=token:password-access."}”
Does anybody have any idea where this is going wrong?
Thanks
Anton Louw
Cloud Engineer: Storage and Virtualization at Vox
________________________________
T: 087 805 0000 | D: 087 805 1572
M: N/A
E: anton.louw(a)voxtelecom.co.za<mailto:anton.louw@voxtelecom.co.za>
A: Rutherford Estate, 1 Scott Street, Waverley, Johannesburg
www.vox.co.za<http://www.vox.co.za>
[F]<https://www.facebook.com/voxtelecomZA>
[T]<https://www.twitter.com/voxtelecom>
[I]<https://www.instagram.com/voxtelecomza>
[L]<https://www.linkedin.com/company/voxtelecom>
[Y]<https://www.youtube.com/user/VoxTelecom>
[#VoxBrand]<https://www.vox.co.za/fibre/fibre-to-the-home/?prod=HOME>
Disclaimer
The contents of this email are confidential to the sender and the intended recipient. Unless the contents are clearly and entirely of a personal nature, they are subject to copyright in favour of the holding company of the Vox group of companies. Any recipient who receives this email in error should immediately report the error to the sender and permanently delete this email from all storage devices.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here<https://www.voxtelecom.co.za/security/mimecast/?prod=Enterprise>.
5 years
Cannot authenticate user Invalid scopes: ovirt-app-api
by Anton Louw
Hi All,
A new issue 😊
We have configured oVirt to use KeyCloak for authentication. This all works, I can log into the WebUI etc, but as soon as I need to talk to the API, it gives me the “invalid scopes” error. I have double checked KeyCloak, and the scopes are added. I went through the logs, but there is nothing telling me exactly what the actual cause is.
I get the below when trying to get a token from the engine:
“{"error_code":"access_denied","error":"Cannot authenticate user Invalid scopes: ovirt-app-api ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=token:password-access."}”
Does anybody have any idea where this is going wrong?
Thanks
Anton Louw
Cloud Engineer: Storage and Virtualization
______________________________________
D: 087 805 1572 | M: N/A
A: Rutherford Estate, 1 Scott Street, Waverley, Johannesburg
anton.louw(a)voxtelecom.co.za
www.vox.co.za
5 years
