[ovirt-users] Re: ovirt

2020-07-16 Thread kmajumde
Hi,
Since the volume is full you will not be able to do any kind of file operations 
until some space is free.
Go to Storage -> Disks in ui and find a disk which you are sure is safe to 
delete and you won't miss it.
Note down the disk id.
locate the disk directory under the volume mount.
cd /rhev/data-center/mnt/glusterSD/:/vmstore//images/
you will see three files there.

.lease
.meta
Run the following
$ true >| ./  #removes file contents without changing the directory 
entry
Now you can remove the file safely.
Head over to Storage -> Disks and delete the entry from the ui.
I think this should help you clear up some storage.
___
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/RNES6YA4JOKHEULJ2AGASSBGGS3SLCRF/


[ovirt-users] what is OVF_STORE ?

2020-07-16 Thread 崔涛的公司邮箱
Could anyone give me some explain?

 

 

___
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/L7CEJC2NKBGGOPTL6MHMG2WLT2YAXOBT/


[ovirt-users] Re: what is OVF_STORE ?

2020-07-16 Thread Yedidyah Bar David
On Thu, Jul 16, 2020 at 12:00 PM 崔涛的公司邮箱  wrote:
>
> Could anyone give me some explain?

It's a place (virtual disk) on shared storage where the engine keeps
information about VMs (and templates). See also e.g.:

https://www.ovirt.org/develop/release-management/features/storage/importstoragedomain.html

Before that, such information was saved only in the engine's database.

Best regards,
-- 
Didi
___
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/4O6IH42D3KFOWECWYNSR7A6NGSH6OGBF/


[ovirt-users] VDSM HOST ISSUE - Message timeout which can be caused by communication issues

2020-07-16 Thread lu . alfonsi
Good morning, i have installed a new ovirt 4.3.10 enviroment but sometimes on 
the events of some hosts i read this error message:

VDSM node-1-ra command Get Host Capabilities failed: Message timeout which can 
be caused by communication issues
 
Due to this issue hosts are in unresponsive state and the only way to resolve 
this is and activate host in the cluster, is to restart the ovirt engine 
service. Can anyone help me?

Thanks in advance

Luigi
___
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/LRZLORSREVEYXJHD6GX5NZGV6NM7EL2Z/


[ovirt-users] Re: VDSM HOST ISSUE - Message timeout which can be caused by communication issues

2020-07-16 Thread lu . alfonsi
i attach the hosts info :

Software
OS Version:
RHEL - 7 - 8.2003.0.el7.centos
OS Description:
CentOS Linux 7 (Core)
Kernel Version:
3.10.0 - 1062.el7.x86_64
KVM Version:
2.12.0 - 44.1.el7_8.1
LIBVIRT Version:
libvirt-4.5.0-33.el7_8.1
VDSM Version:
vdsm-4.30.46-1.el7
___
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/7SZVPDQSIJVDHQW4LMFFT633MOPDZFX5/


[ovirt-users] Re: Strange SD problem

2020-07-16 Thread Arsène Gschwind
Hi,

We did compare engine backups and found some differences in the LUNs

"public"."luns"  (restored db from 2020.04.09)


physical_volume_id  lun_idvolume_group_id   
serial lun_mapping  
vendor_id   product_id   device_sizediscard_max_size

wEx3tY-OELy-gOtD-CFDp-az4D-EyYO-1SAAqd  repl_HanaDB_osd_01
a1q5Jr-Bd7h-wEVJ-9b0C-Ggnr-M1JI-kyXeDVSHUAWEI_XSG1_2102350RMG10HC210053 
 6HUAWEI  XSG1 4096   268435456

DPUtaW-Q5zp-aZos-HriP-5Z0v-hiWO-w7rmwG  repl_HanaLogs_osd_01  
4TCXZ7-R1l1-xkdU-u0vx-S3n4-JWcE-qksPd1SHUAWEI_XSG1_2102350RMG10HC200035 
 7HUAWEI  XSG1 2048   268435456


"public"."luns"  (current db)



physical_volume_id  lun_idvolume_group_id   
serial lun_mapping  
vendor_id   product_id   device_sizediscard_max_size

wEx3tY-OELy-gOtD-CFDp-az4D-EyYO-1SAAqd  repl_HanaDB_osd_01
a1q5Jr-Bd7h-wEVJ-9b0C-Ggnr-M1JI-kyXeDVSHUAWEI_XSG1_2102350RMG10HC210053 
 6HUAWEI  XSG1 4096   268435456

repl_HanaLogs_osd_01
SHUAWEI_XSG1_2102350RMG10HC210054  7
HUAWEI  XSG1 2548   268435456

We observed that the physical_volume_id and volume_group_id is missing from the 
corrupt SD.
We also observed that the serial has changed on the corrupted SD/LUN.
Is the serial calculated or read somewhere?
Would it be possible to inject the missing values in the engine DB to recover 
to a consistent state?

Thanks for any help.
Arsene


On Wed, 2020-07-15 at 13:24 +0300, Ahmad Khiet wrote:
Hi Arsène,

can you please send which version are you referring to?

as shown in the log: Storage domains with IDs 
[6b82f31b-fa2a-406b-832d-64d9666e1bcc] could not be synchronized. To 
synchronize them, please move them to maintenance and then activate.
can you put them in maintenance and then activate them back so it will be 
synced?
I guess that it is out of sync, that's why the "Add" button appears to already 
added LUNs



On Tue, Jul 14, 2020 at 4:58 PM Arsène Gschwind 
mailto:arsene.gschw...@unibas.ch>> wrote:
Hi Ahmad,

I did the following:

1. Storage -> Storage Domains
2 Click the existing Storage Domain and click "Manage Domain"
and then I see next to the LUN which is already part of the SD the "Add" button

I do not want to click add since it may destroy the existing SD or the content 
of the LUNs.
In the Engine Log I see the following:


020-07-14 09:57:45,131+02 WARN  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-20) [277145f2] EVENT_ID: 
STORAGE_DOMAINS_COULD_NOT_BE_SYNCED(1,046), Storage domains with IDs 
[6b82f31b-fa2a-406b-832d-64d9666e1bcc] could not be synchronized. To 
synchronize them, please move them to maintenance and then activate.

Thanks a lot

On Tue, 2020-07-14 at 16:07 +0300, Ahmad Khiet wrote:
Hi Arsène Gschwind,

it's really strange that you see "Add" on a LUN that already has been added to 
the database.
to verify the steps you did make at first,
1- Storage -> Storage Domains
2- New Domain - [ select iSCSI ]
3- click on "+" on the iscsi target, then you see the "Add" button is available
4- after clicking add and ok, then this error will be shown in the logs
is that right?

can you also attach vdsm log?




On Tue, Jul 14, 2020 at 1:15 PM Arsène Gschwind 
mailto:arsene.gschw...@unibas.ch>> wrote:
Hello all,

I've checked all my multipath configuration and everything seems korrekt.
Is there a way to correct this, may be in the DB?

I really need some help, thanks a lot.
Arsène

On Tue, 2020-07-14 at 00:29 +, Arsène Gschwind wrote:
HI,

I'm having a strange behavior with a SD. When trying to manage the SD I see 
they "Add" button for the LUN which should already be the one use for that SD.
In the Logs I see the following:

2020-07-13 17:48:07,292+02 ERROR 
[org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] 
(EE-ManagedThreadFactory-engine-Thread-95) [51091853] Can't execute batch: 
Batch entry 0 select * from public.insertluns(CAST ('repl_HanaLogs_osd_01' AS 
varchar),CAST ('DPUtaW-Q5zp-aZos-HriP-5Z0v-hiWO-w7rmwG' AS varchar),CAST 
('4TCXZ7-R1l1-xkdU-u0vx-S3n4-JWcE-qksPd1' AS varchar),CAST 
('SHUAWEI_XSG1_2102350RMG10HC200035' AS varchar),CAST (7 AS int4),CAST 
('HUAWEI' AS varchar),CAST ('XSG1' AS varchar),CAST (2548 AS int4),CAST 
(268435456 AS int8)) as result was aborted: ERROR: duplicate key value violates 
unique constraint "pk_luns"
  Detail: Key (lun_id)=(repl_HanaLogs_osd_01) already exists.
  Where: SQL statement "INSERT INTO LUNs (
   

[ovirt-users] Re: VDSM HOST ISSUE - Message timeout which can be caused by communication issues

2020-07-16 Thread Strahil Nikolov via Users
What do you see  in the engine's logs ?

Best Regards,
Strahil Nikolov

На 16 юли 2020 г. 13:24:03 GMT+03:00, lu.alfo...@almaviva.it написа:
>i attach the hosts info :
>
>Software
>OS Version:
>RHEL - 7 - 8.2003.0.el7.centos
>OS Description:
>CentOS Linux 7 (Core)
>Kernel Version:
>3.10.0 - 1062.el7.x86_64
>KVM Version:
>2.12.0 - 44.1.el7_8.1
>LIBVIRT Version:
>libvirt-4.5.0-33.el7_8.1
>VDSM Version:
>vdsm-4.30.46-1.el7
>___
>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/7SZVPDQSIJVDHQW4LMFFT633MOPDZFX5/
___
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/GTJNI5FH4ZVAQMBOUQSZN5WW2JFDH2XT/


[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-16 Thread dominique . deschenes
I also have this message with the deployment of Gluster. I tried the 
modifications and it doesn't seem to work. Did you succeed ?

here error : 

TASK [gluster.infra/roles/backend_setup : Change to Install lvm tools for RHEL 
systems.] ***
task path: 
/etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/main.yml:33
fatal: [ovnode2.telecom.lan]: FAILED! => {"changed": false, "msg": "The Python 
2 yum module is needed for this module. If you require Python 3 support use the 
`dnf` Ansible module instead."}
fatal: [ovnode1.telecom.lan]: FAILED! => {"changed": false, "msg": "The Python 
2 yum module is needed for this module. If you require Python 3 support use the 
`dnf` Ansible module instead."}
fatal: [ovnode3.telecom.lan]: FAILED! => {"changed": false, "msg": "The Python 
2 yum module is needed for this module. If you require Python 3 support use the 
`dnf` Ansible module instead."}
___
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/VZVYGT7QUVWGQZERFYQ54I7VYPOM4ALL/


[ovirt-users] qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-16 Thread Florian Schmid via Users
Hi,

I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the engine.
Starting with this release, the ovirt-guest-agent is not available anymore.

Therefore, I have installed qemu-geust-agent with package defaults.

Now in the Engine, I only see the hostname under FQDN tab, instead the real 
full name with domain.

I'm running an oVirt environment on 4.3.8.

The VM is resolveable, forward and reverse DNS entries are working.
hostname -f shows the correct FQDN.

Even adding IP and FQDN to /etc/hosts file doesn't change anything.

qemu-guest-agent version: 4.2-3ubuntu6.3

I manage this VM via ansible 2.9 and ansible is able to get the FQDN of the VM 
without any issues...

What can I do here to debug my issue?
Does the engine cache the wrong result? Even after stopping and starting the VM 
again, engine is only showing the hostname instead of the FQDN.

Best regards,
Florian
___
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/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/


[ovirt-users] Re: Strange SD problem

2020-07-16 Thread Ahmad Khiet
Hi,
if its the same LUN, then why not remove and import back?


On Thu, Jul 16, 2020 at 3:21 PM Arsène Gschwind 
wrote:

> Hi,
>
> We did compare engine backups and found some differences in the LUNs
>
> "public"."luns"  (restored db from 2020.04.09)
> 
>
> physical_volume_id  lun_idvolume_group_id 
>   serial lun_mapping  
> vendor_id   product_id   device_sizediscard_max_size
>
> wEx3tY-OELy-gOtD-CFDp-az4D-EyYO-1SAAqd  repl_HanaDB_osd_01
> a1q5Jr-Bd7h-wEVJ-9b0C-Ggnr-M1JI-kyXeDV
> SHUAWEI_XSG1_2102350RMG10HC210053  6HUAWEI  XSG1 
> 4096   268435456
>
> DPUtaW-Q5zp-aZos-HriP-5Z0v-hiWO-w7rmwG  repl_HanaLogs_osd_01  
> 4TCXZ7-R1l1-xkdU-u0vx-S3n4-JWcE-qksPd1
> SHUAWEI_XSG1_2102350RMG10HC200035  7HUAWEI  XSG1 
> 2048   268435456
>
>
> "public"."luns"  (current db)
>
> 
>
> physical_volume_id  lun_idvolume_group_id 
>   serial lun_mapping  
> vendor_id   product_id   device_sizediscard_max_size
>
> wEx3tY-OELy-gOtD-CFDp-az4D-EyYO-1SAAqd  repl_HanaDB_osd_01
> a1q5Jr-Bd7h-wEVJ-9b0C-Ggnr-M1JI-kyXeDV
> SHUAWEI_XSG1_2102350RMG10HC210053  6HUAWEI  XSG1 
> 4096   268435456
>
> repl_HanaLogs_osd_01  
>   SHUAWEI_XSG1_2102350RMG10HC210054  7
> HUAWEI  XSG1 2548   268435456
>
>
> We observed that the physical_volume_id and volume_group_id is missing
> from the corrupt SD.
> We also observed that the serial has changed on the corrupted SD/LUN.
> Is the serial calculated or read somewhere?
> Would it be possible to inject the missing values in the engine DB to
> recover to a consistent state?
>
> Thanks for any help.
> Arsene
>
>
> On Wed, 2020-07-15 at 13:24 +0300, Ahmad Khiet wrote:
>
> Hi Arsène,
>
> can you please send which version are you referring to?
>
> as shown in the log: Storage domains with IDs 
> [6b82f31b-fa2a-406b-832d-64d9666e1bcc]
> could not be synchronized. To synchronize them, please move them to
> maintenance and then activate.
> can you put them in maintenance and then activate them back so it will be
> synced?
> I guess that it is out of sync, that's why the "Add" button appears to
> already added LUNs
>
>
>
> On Tue, Jul 14, 2020 at 4:58 PM Arsène Gschwind 
> wrote:
>
> Hi Ahmad,
>
> I did the following:
>
> 1. Storage -> Storage Domains
> 2 Click the existing Storage Domain and click "Manage Domain"
> and then I see next to the LUN which is already part of the SD the "Add"
> button
>
> I do not want to click add since it may destroy the existing SD or the
> content of the LUNs.
> In the Engine Log I see the following:
>
> 020-07-14 09:57:45,131+02 WARN  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engine-Thread-20) [277145f2] EVENT_ID: 
> STORAGE_DOMAINS_COULD_NOT_BE_SYNCED(1,046), Storage domains with IDs 
> [6b82f31b-fa2a-406b-832d-64d9666e1bcc] could not be synchronized. To 
> synchronize them, please move them to maintenance and then activate.
>
>
> Thanks a lot
>
> On Tue, 2020-07-14 at 16:07 +0300, Ahmad Khiet wrote:
>
> Hi Arsène Gschwind,
>
> it's really strange that you see "Add" on a LUN that already has been
> added to the database.
> to verify the steps you did make at first,
> 1- Storage -> Storage Domains
> 2- New Domain - [ select iSCSI ]
> 3- click on "+" on the iscsi target, then you see the "Add" button is
> available
> 4- after clicking add and ok, then this error will be shown in the logs
> is that right?
>
> can you also attach vdsm log?
>
>
>
>
> On Tue, Jul 14, 2020 at 1:15 PM Arsène Gschwind 
> wrote:
>
> Hello all,
>
> I've checked all my multipath configuration and everything seems korrekt.
> Is there a way to correct this, may be in the DB?
>
> I really need some help, thanks a lot.
> Arsène
>
> On Tue, 2020-07-14 at 00:29 +, Arsène Gschwind wrote:
>
> HI,
>
> I'm having a strange behavior with a SD. When trying to manage the SD I
> see they "Add" button for the LUN which should already be the one use for
> that SD.
> In the Logs I see the following:
>
> 2020-07-13 17:48:07,292+02 ERROR
> [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback]
> (EE-ManagedThreadFactory-engine-Thread-95) [51091853] Can't execute batch:
> Batch entry 0 select * from public.insertluns(CAST ('repl_HanaLogs_osd_01'
> AS varchar),CAST ('DPUtaW-Q5zp-aZos-HriP-5Z0v-hiWO-w7rmwG' AS varchar),CAST
> ('4TCXZ7-R1l1-xkdU-u0vx-S3n4-JWcE-qksPd1' AS varchar),CAST
> ('SHUAWEI_XSG1_2102350RMG10HC200035' AS varchar),CAST (7 AS int4),CAST
> ('HUAWEI' A

[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-16 Thread Edward Berger
Same issue with ovirt-node-ng-installer 4.4.1-2020071311.el8 iso
[image: gluster-fail.PNG]

On Thu, Jul 16, 2020 at 9:33 AM  wrote:

> I also have this message with the deployment of Gluster. I tried the
> modifications and it doesn't seem to work. Did you succeed ?
>
> here error :
>
> TASK [gluster.infra/roles/backend_setup : Change to Install lvm tools for
> RHEL systems.] ***
> task path:
> /etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/main.yml:33
> fatal: [ovnode2.telecom.lan]: FAILED! => {"changed": false, "msg": "The
> Python 2 yum module is needed for this module. If you require Python 3
> support use the `dnf` Ansible module instead."}
> fatal: [ovnode1.telecom.lan]: FAILED! => {"changed": false, "msg": "The
> Python 2 yum module is needed for this module. If you require Python 3
> support use the `dnf` Ansible module instead."}
> fatal: [ovnode3.telecom.lan]: FAILED! => {"changed": false, "msg": "The
> Python 2 yum module is needed for this module. If you require Python 3
> support use the `dnf` Ansible module instead."}
> ___
> 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/VZVYGT7QUVWGQZERFYQ54I7VYPOM4ALL/
>
___
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/GV6MIO2V5F75QDFSWEDUBDTY4G4O74FM/


[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-16 Thread Strahil Nikolov via Users
Have you tried to replace 'package' with 'dnf' in 
/etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/main.yml (somewhere 
around line 33).

Best Regards,
Strahil Nikolov

На 16 юли 2020 г. 16:30:04 GMT+03:00, dominique.desche...@gcgenicom.com написа:
>I also have this message with the deployment of Gluster. I tried the
>modifications and it doesn't seem to work. Did you succeed ?
>
>here error : 
>
>TASK [gluster.infra/roles/backend_setup : Change to Install lvm tools
>for RHEL systems.] ***
>task path:
>/etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/main.yml:33
>fatal: [ovnode2.telecom.lan]: FAILED! => {"changed": false, "msg": "The
>Python 2 yum module is needed for this module. If you require Python 3
>support use the `dnf` Ansible module instead."}
>fatal: [ovnode1.telecom.lan]: FAILED! => {"changed": false, "msg": "The
>Python 2 yum module is needed for this module. If you require Python 3
>support use the `dnf` Ansible module instead."}
>fatal: [ovnode3.telecom.lan]: FAILED! => {"changed": false, "msg": "The
>Python 2 yum module is needed for this module. If you require Python 3
>support use the `dnf` Ansible module instead."}
>___
>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/VZVYGT7QUVWGQZERFYQ54I7VYPOM4ALL/
___
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/K7YEXJ2NYPLED6II2W5ZPCBGAKITDPUI/


[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-16 Thread Strahil Nikolov via Users
Can you share your /etc/hosts.
As far as I remember there was an entry like:

127.0.1.2 hostname

So you have to comment it out.

Best Regards,
Strahil Nikolov

На 16 юли 2020 г. 16:53:36 GMT+03:00, Florian Schmid via Users 
 написа:
>Hi,
>
>I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the
>engine.
>Starting with this release, the ovirt-guest-agent is not available
>anymore.
>
>Therefore, I have installed qemu-geust-agent with package defaults.
>
>Now in the Engine, I only see the hostname under FQDN tab, instead the
>real full name with domain.
>
>I'm running an oVirt environment on 4.3.8.
>
>The VM is resolveable, forward and reverse DNS entries are working.
>hostname -f shows the correct FQDN.
>
>Even adding IP and FQDN to /etc/hosts file doesn't change anything.
>
>qemu-guest-agent version: 4.2-3ubuntu6.3
>
>I manage this VM via ansible 2.9 and ansible is able to get the FQDN of
>the VM without any issues...
>
>What can I do here to debug my issue?
>Does the engine cache the wrong result? Even after stopping and
>starting the VM again, engine is only showing the hostname instead of
>the FQDN.
>
>Best regards,
>Florian
>___
>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/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/
___
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/2LLFPK2FDRBDLIJ22HFIWSDDLYWVQMT3/


[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-16 Thread clam2718
Dear Strahil, Dominique and Edward:

I reimaged the three hosts with 
ovirt-node-ng-installer-4.4.1-2020071311.el8.iso just to be sure everything was 
stock (I had upgraded from v4.4) and attempted a redeploy with all suggested 
changes EXCEPT replacing "package" with "dnf" --> same failure.  I then made 
Strahil's recommended replacement of "package" with "dnf" and the Gluster 
deployment succeeded through that section of main.yml only to fail a little 
later at:

- name: Install python-yaml package for Debian systems
  package:
name: python-yaml
state: present
  when: ansible_distribution == "Debian" or ansible_distribution == "Ubuntu"

I found this notable given that I had not replaced "package" with "dnf" in the 
prior section:

- name: Change to Install lvm tools for debian systems.
  package:
name: thin-provisioning-tools
state: present
  when: ansible_distribution == "Debian" or ansible_distribution == "Ubuntu"

and deployment had not failed here.  Anyhow, I deleted the two Debian 
statements as I am deploying from Node (CentOS based), cleaned up, cleaned up 
my drives ('dmsetup remove eui.xxx...' and 'wipefs --all --force /dev/nvme0n1 
/dev/nvmeXn1 ...')  and redeployed again.  This time Gluster deployment seemed 
to execute main.yml OK only to fail in a new file, vdo_create.yml:

TASK [gluster.infra/roles/backend_setup : Install VDO dependencies] 
task path: 
/etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/vdo_create.yml:26
fatal: [fmov1n1.sn.dtcorp.com]: FAILED! => {"changed": false, "msg": "The 
Python 2 yum module is needed for this module. If you require Python 3 support 
use the `dnf` Ansible module instead."}
fatal: [fmov1n3.sn.dtcorp.com]: FAILED! => {"changed": false, "msg": "The 
Python 2 yum module is needed for this module. If you require Python 3 support 
use the `dnf` Ansible module instead."}
fatal: [fmov1n2.sn.dtcorp.com]: FAILED! => {"changed": false, "msg": "The 
Python 2 yum module is needed for this module. If you require Python 3 support 
use the `dnf` Ansible module instead."}

Expecting that this might continue, I have been looking into the documentation 
of how "package" works and if I can find a root cause for this rather than 
reviewing n *.yml files and replacing "package" with "dnf" in all of them.  
Thank you VERY much to Strahil for helping me!

If Strahil or anyone else has any additional troubleshooting tips, suggestions, 
insight or solutions I am all ears.  I will continue to update as I progress.

Respectfully,
Charles
___
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/3JTZX2OF4JTGRECMZLZXZQT5IWR4PFSG/


[ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster deploy fails insufficient free space no matter how small the volume is set

2020-07-16 Thread Dominique Deschênes


HI, 
Thank you for your answers

I tried to replace the "package" with "dnf".  the installation of the gluster 
seems to work well but I had the similar message during the deployment of the 
Hosted engine.

Here is the error

[ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 10, "changed": false, 
"msg": "The Python 2 yum module is needed for this module. If you require 
Python 3 support use the `dnf` Ansible module instead."} 





Dominique Deschênes
Ingénieur chargé de projets, Responsable TI
816, boulevard Guimond, Longueuil J4G 1T5
 450 670-8383 x105  450 670-2259


          

- Message reçu -
De: clam2...@gmail.com
Date: 16/07/20 13:40
À: users@ovirt.org
Objet: [ovirt-users] Re: oVirt Node 4.4.1.1 Cockpit Hyperconverged Gluster 
deploy fails insufficient free space no matter how small the volume is set

Dear Strahil, Dominique and Edward:

I reimaged the three hosts with 
ovirt-node-ng-installer-4.4.1-2020071311.el8.iso just to be sure everything was 
stock (I had upgraded from v4.4) and attempted a redeploy with all suggested 
changes EXCEPT replacing "package" with "dnf" --> same failure.  I then made 
Strahil's recommended replacement of "package" with "dnf" and the Gluster 
deployment succeeded through that section of main.yml only to fail a little 
later at:

- name: Install python-yaml package for Debian systems
 package:
   name: python-yaml
   state: present
 when: ansible_distribution == "Debian" or ansible_distribution == "Ubuntu"

I found this notable given that I had not replaced "package" with "dnf" in the 
prior section:

- name: Change to Install lvm tools for debian systems.
 package:
   name: thin-provisioning-tools
   state: present
 when: ansible_distribution == "Debian" or ansible_distribution == "Ubuntu"

and deployment had not failed here.  Anyhow, I deleted the two Debian 
statements as I am deploying from Node (CentOS based), cleaned up, cleaned up 
my drives ('dmsetup remove eui.xxx...' and 'wipefs --all --force /dev/nvme0n1 
/dev/nvmeXn1 ...')  and redeployed again.  This time Gluster deployment seemed 
to execute main.yml OK only to fail in a new file, vdo_create.yml:

TASK [gluster.infra/roles/backend_setup : Install VDO dependencies] 
task path: 
/etc/ansible/roles/gluster.infra/roles/backend_setup/tasks/vdo_create.yml:26
fatal: [fmov1n1.sn.dtcorp.com]: FAILED! => {"changed": false, "msg": "The 
Python 2 yum module is needed for this module. If you require Python 3 support 
use the `dnf` Ansible module instead."}
fatal: [fmov1n3.sn.dtcorp.com]: FAILED! => {"changed": false, "msg": "The 
Python 2 yum module is needed for this module. If you require Python 3 support 
use the `dnf` Ansible module instead."}
fatal: [fmov1n2.sn.dtcorp.com]: FAILED! => {"changed": false, "msg": "The 
Python 2 yum module is needed for this module. If you require Python 3 support 
use the `dnf` Ansible module instead."}

Expecting that this might continue, I have been looking into the documentation 
of how "package" works and if I can find a root cause for this rather than 
reviewing n *.yml files and replacing "package" with "dnf" in all of them.  
Thank you VERY much to Strahil for helping me!

If Strahil or anyone else has any additional troubleshooting tips, suggestions, 
insight or solutions I am all ears.  I will continue to update as I progress.

Respectfully,
Charles
___
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/3JTZX2OF4JTGRECMZLZXZQT5IWR4PFSG/


___
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/OGMHY4KGT45UC5FPF7HHH53YJ62IKFC4/


[ovirt-users] Re: qemu-guest-agent on Ubuntu doesn't report FQDN

2020-07-16 Thread Florian Schmid via Users
Hi Strahil,

no, the hosts file should be OK:
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts


When adding an additional line, like this:
192.168.1.1 FQDN hostname

it is also not working.

This is the same hosts file like on our older Ubuntu 18.04 systems, but with 
ovirt-guest-agent installed.

BR Florian


- Ursprüngliche Mail -
Von: "Strahil Nikolov" 
An: "Florian Schmid" , "users" 
Gesendet: Donnerstag, 16. Juli 2020 18:17:22
Betreff: Re: [ovirt-users] qemu-guest-agent on Ubuntu doesn't report FQDN

Can you share your /etc/hosts.
As far as I remember there was an entry like:

127.0.1.2 hostname

So you have to comment it out.

Best Regards,
Strahil Nikolov

На 16 юли 2020 г. 16:53:36 GMT+03:00, Florian Schmid via Users 
 написа:
>Hi,
>
>I have a problem with Ubuntu 20.04 VM reporting the correct FQDN to the
>engine.
>Starting with this release, the ovirt-guest-agent is not available
>anymore.
>
>Therefore, I have installed qemu-geust-agent with package defaults.
>
>Now in the Engine, I only see the hostname under FQDN tab, instead the
>real full name with domain.
>
>I'm running an oVirt environment on 4.3.8.
>
>The VM is resolveable, forward and reverse DNS entries are working.
>hostname -f shows the correct FQDN.
>
>Even adding IP and FQDN to /etc/hosts file doesn't change anything.
>
>qemu-guest-agent version: 4.2-3ubuntu6.3
>
>I manage this VM via ansible 2.9 and ansible is able to get the FQDN of
>the VM without any issues...
>
>What can I do here to debug my issue?
>Does the engine cache the wrong result? Even after stopping and
>starting the VM again, engine is only showing the hostname instead of
>the FQDN.
>
>Best regards,
>Florian
>___
>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/BGGFBU24SQAJICU5OR7VOZLBQUZ3CWNJ/
___
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/AEGO7OBASTEDT66MZSW2TSYC3RPMC6PI/


[ovirt-users] ovirt-node-ng-image-update 4.4.1 to 4.4.1.1

2020-07-16 Thread David M. Hornsby
All,

I applied the recent update 4.4.1 -> 4.4.1.1 to a host in a cluster and it 
failed. After reboot it was hund at the emergency console. I reinstalled 4.4.1 
fresh on the host. Prior to adding it back to the cluster I applied the same 
update with the same result. Is this just a bad update or is the post install 
script bad.

Thanks,
David.
___
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/AY65GWXHPUTIET7DOTQZQJOKZ24CRG4L/


[ovirt-users] Re: VM Portal on a stand alone server

2020-07-16 Thread Gal Villaret
Thanks.

Using a proxy is my plan.
I was asked by my security team to add some more "distance" from users to
the server running the engine and the database.
Coming to think of it, maybe deploying the DB on a standalone server is a
better approach.







On Wed, Jul 15, 2020 at 10:08 PM Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
>
> On 15 Jul 2020, at 17:12, Gal Villaret  wrote:
>
> I have the engine running on a dedicated server.
>
> I would like to separate the VM Portal to another server or maybe have
> another instance of VM portal on another server.
>
> The idea is to be able to put the VM Portal on a different subnet and to
> put a firewall between it and the engine.
>
>
> it’s possible in devel mode, see docker container at
> https://github.com/oVirt/ovirt-web-ui
> but we’re not really updating it very often, I wouldn’t recommend it for
> production
>
> What’s the concern if you limit access to :443 and use a proxy? There’s
> not much more a random joe can do without a permission to log into
> webadmin, there’s just a static landing page with few links.
>
>
> Thanks.
>
> On Wed, Jul 15, 2020, 17:18 Sandro Bonazzola  wrote:
>
>>
>>
>> Il giorno mer 15 lug 2020 alle ore 12:26  ha
>> scritto:
>>
>>> Hi Folks,
>>>
>>> I'm rather new to oVirt and loving it.
>>> running 4.4.1.
>>> I would like to be able to run the VM Portal on a stand-alone server for
>>> security concerns.
>>>
>>> Can anyone point in the right direction for achieving this?
>>>
>>
>> Can you please elaborate?
>> Are you asking for having the admin portal and the VM user portal running
>> on 2 different servers?
>> Or running the engine on a dedicated server instead of on self hosted
>> engine VM?
>>
>>
>>
>>
>>>
>>> Thanks,
>>>
>>> Gal Villaret
>>> ___
>>> 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/3BE6CNDNLDKZQW5ANOC3UFT3BQZZFGHC/
>>>
>>
>>
>> --
>> Sandro Bonazzola
>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>
>> Red Hat EMEA 
>> sbona...@redhat.com
>> 
>>
>> *Red Hat respects your work life balance. Therefore there is no need to
>> answer this email out of your office hours.
>> *
>>
> ___
> 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/EDCHL6QLGDWU2GASCOXHC4B3DFHJNPBC/
>
>
>
___
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/W7S2KFDTCRV3HDV5MYQQTPID2ZWMLLCX/


[ovirt-users] Engine deployment fails with engine booting to grub rescue

2020-07-16 Thread Andy via Users
After working through some DNS problems I was able to install oVirt 4.4.1.1 and 
progress the engine deployment stops within the ansible scripts.  The system 
deploys the gluster domain, creates the engine, starts the engine, however it 
will never fully boot and complete the deployment.  Bringing up the console of 
the engine sets it into rescue mode.  I have attempted to set the appropriate 
variables in grub rescue 
set root=(hd0,msdos1)
set prefix=(hd0,msdos1)/boot/grub
insmod normal And this will not boot the engine.  Is there a procedure to mount 
a CENTOS 8 rescue CD/ISO to troubleshoot this or is there a specific fix 
published for this problem?   The specific error I am seeing in the Engine 
Console is "attempt to read outside of HD0. I upgraded the ovirt engine 
appliance package to ovirt-engine-appliance-4.4-20200716090128.1.el8.x86_64 
which produces the same result.  I have gotten this error deploying on both my 
Intel and AMD based servers.  

any help is appreciated. 

thanks
Andy



___
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/6XCAJ7MP4MIYVSE42XALJ2QY3ZXLNFU3/


[ovirt-users] Re: Engine deployment fails with engine booting to grub rescue

2020-07-16 Thread AK via Users
After doing a bit more research,  I was able to get the engine to boot by 
issuing CTRL-ALT-DEL through remote viewer. I am uncertain as to why that 
appears to fix the problem with the engine, however after such I have added 
additional hosts, and reinstalled the first host that failed on the original 
deployment.   

During the three previous failed deployments, using the OVIRT rpms from the 
resources site, I manually specified the engine OVA path, which produced the 
same results.  I dont know if this install problem has to do with imageio or 
how all the OVA's were sealed on creation but the logs from the engine doesnt 
show anything out of the ordinary and the engine has all the environment 
variables inputted during the deployment.  Will attach the setup and imageIO 
logs for reference. 

thanks
___
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/ZKNNUN3DGCVWDZH3BFKADNSIJGYYRC2K/


[ovirt-users] Re: Strange SD problem

2020-07-16 Thread Arsène Gschwind
Hi,

I have some running VM on it, this isn't easy...
If I remove that LUN from the SD, what will happen to the disk defined in that 
SD? will they get lost?


On Thu, 2020-07-16 at 17:58 +0300, Ahmad Khiet wrote:
Hi,
if its the same LUN, then why not remove and import back?


On Thu, Jul 16, 2020 at 3:21 PM Arsène Gschwind 
mailto:arsene.gschw...@unibas.ch>> wrote:
Hi,

We did compare engine backups and found some differences in the LUNs

"public"."luns"  (restored db from 2020.04.09)


physical_volume_id  lun_idvolume_group_id   
serial lun_mapping  
vendor_id   product_id   device_sizediscard_max_size

wEx3tY-OELy-gOtD-CFDp-az4D-EyYO-1SAAqd  repl_HanaDB_osd_01
a1q5Jr-Bd7h-wEVJ-9b0C-Ggnr-M1JI-kyXeDVSHUAWEI_XSG1_2102350RMG10HC210053 
 6HUAWEI  XSG1 4096   268435456

DPUtaW-Q5zp-aZos-HriP-5Z0v-hiWO-w7rmwG  repl_HanaLogs_osd_01  
4TCXZ7-R1l1-xkdU-u0vx-S3n4-JWcE-qksPd1SHUAWEI_XSG1_2102350RMG10HC200035 
 7HUAWEI  XSG1 2048   268435456


"public"."luns"  (current db)



physical_volume_id  lun_idvolume_group_id   
serial lun_mapping  
vendor_id   product_id   device_sizediscard_max_size

wEx3tY-OELy-gOtD-CFDp-az4D-EyYO-1SAAqd  repl_HanaDB_osd_01
a1q5Jr-Bd7h-wEVJ-9b0C-Ggnr-M1JI-kyXeDVSHUAWEI_XSG1_2102350RMG10HC210053 
 6HUAWEI  XSG1 4096   268435456

repl_HanaLogs_osd_01
SHUAWEI_XSG1_2102350RMG10HC210054  7
HUAWEI  XSG1 2548   268435456

We observed that the physical_volume_id and volume_group_id is missing from the 
corrupt SD.
We also observed that the serial has changed on the corrupted SD/LUN.
Is the serial calculated or read somewhere?
Would it be possible to inject the missing values in the engine DB to recover 
to a consistent state?

Thanks for any help.
Arsene


On Wed, 2020-07-15 at 13:24 +0300, Ahmad Khiet wrote:
Hi Arsène,

can you please send which version are you referring to?

as shown in the log: Storage domains with IDs 
[6b82f31b-fa2a-406b-832d-64d9666e1bcc] could not be synchronized. To 
synchronize them, please move them to maintenance and then activate.
can you put them in maintenance and then activate them back so it will be 
synced?
I guess that it is out of sync, that's why the "Add" button appears to already 
added LUNs



On Tue, Jul 14, 2020 at 4:58 PM Arsène Gschwind 
mailto:arsene.gschw...@unibas.ch>> wrote:
Hi Ahmad,

I did the following:

1. Storage -> Storage Domains
2 Click the existing Storage Domain and click "Manage Domain"
and then I see next to the LUN which is already part of the SD the "Add" button

I do not want to click add since it may destroy the existing SD or the content 
of the LUNs.
In the Engine Log I see the following:


020-07-14 09:57:45,131+02 WARN  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-20) [277145f2] EVENT_ID: 
STORAGE_DOMAINS_COULD_NOT_BE_SYNCED(1,046), Storage domains with IDs 
[6b82f31b-fa2a-406b-832d-64d9666e1bcc] could not be synchronized. To 
synchronize them, please move them to maintenance and then activate.

Thanks a lot

On Tue, 2020-07-14 at 16:07 +0300, Ahmad Khiet wrote:
Hi Arsène Gschwind,

it's really strange that you see "Add" on a LUN that already has been added to 
the database.
to verify the steps you did make at first,
1- Storage -> Storage Domains
2- New Domain - [ select iSCSI ]
3- click on "+" on the iscsi target, then you see the "Add" button is available
4- after clicking add and ok, then this error will be shown in the logs
is that right?

can you also attach vdsm log?




On Tue, Jul 14, 2020 at 1:15 PM Arsène Gschwind 
mailto:arsene.gschw...@unibas.ch>> wrote:
Hello all,

I've checked all my multipath configuration and everything seems korrekt.
Is there a way to correct this, may be in the DB?

I really need some help, thanks a lot.
Arsène

On Tue, 2020-07-14 at 00:29 +, Arsène Gschwind wrote:
HI,

I'm having a strange behavior with a SD. When trying to manage the SD I see 
they "Add" button for the LUN which should already be the one use for that SD.
In the Logs I see the following:

2020-07-13 17:48:07,292+02 ERROR 
[org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] 
(EE-ManagedThreadFactory-engine-Thread-95) [51091853] Can't execute batch: 
Batch entry 0 select * from public.insertluns(CAST ('repl_HanaLogs_osd_01' AS 
varchar),CAST ('DPUtaW-Q5zp-aZos-HriP-5Z0v-hiWO-w7rmwG' AS varchar),CAST 
('4TCXZ7-R1l1-xkdU-u0vx-S3n4-JWcE-qksPd1' AS varchar),CAST 
(