I don't see anything related to VM 5322c11a-d7d1-4c3f-ae38-421bf6b49349 or to disk 77a3aafc-c946-4ac6-b174-d170fe27db2b in the attached logs, can you please double check that those are the right logs?

(In reply to Arik from comment #2)
> I don't see anything related to VM 5322c11a-d7d1-4c3f-ae38-421bf6b49349 or
> to disk 77a3aafc-c946-4ac6-b174-d170fe27db2b in the attached logs, can you
> please double check that those are the right logs?

This VM is not related to the logs of the test that failed.
I tried to reproduce it manually and check on rest-api if it is really missing, so this VM is from my manual testing.
The logs I attached are from our automation test that tests this flow.

I was able to reproduce this on 4.4.1.10-0.1.el8ev, but the data are reported properly from EL8 guest. Probably engine just fails to map the serial number to the actual disk.

Thanks Tomáš, your observation is correct:
https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/libvirt/VmDevicesConverter.java;h=42c3d5d9df6e76fd31c1b95f700204500ec4c6f8;hb=290adfb533cbc8a3be24267d0f7d55ea7f92f99b#l100

Bare in mind that until BZ 1836661 is resolved, the LUN must be mounted in the guest.

Created attachment 1724116 [details]
logs

Tested with:
ovirt-engine-4.4.3.7-0.22.el8ev.noarch
vdsm-4.40.34-1.el8ev.x86_64

Steps:
1. Create a VM with disk
2. Run VM
3. Create iSCSI direct lun
4. Attach direct lun as RO to the VM
5. Mount the lun in the guest
6. Get vm diskattachments via API

Results:
No logical name for the direct lun on REST API.

API message:
<disk_attachments>
    <disk_attachment href="/ovirt-engine/api/vms/20880dbd-8970-426a-a31c-08204bbbdd39/diskattachments/3eaad627-8d86-4397-bf88-c26c03b6e2fb" id="3eaad627-8d86-4397-bf88-c26c03b6e2fb">
        <active>true</active>
        <bootable>true</bootable>
        <interface>virtio</interface>
        <logical_name>/dev/vda</logical_name>
        <pass_discard>false</pass_discard>
        <read_only>false</read_only>
        <uses_scsi_reservation>false</uses_scsi_reservation>
        <disk href="/ovirt-engine/api/disks/3eaad627-8d86-4397-bf88-c26c03b6e2fb" id="3eaad627-8d86-4397-bf88-c26c03b6e2fb"/>
        <vm href="/ovirt-engine/api/vms/20880dbd-8970-426a-a31c-08204bbbdd39" id="20880dbd-8970-426a-a31c-08204bbbdd39"/>
    </disk_attachment>
    <disk_attachment href="/ovirt-engine/api/vms/20880dbd-8970-426a-a31c-08204bbbdd39/diskattachments/a4d5c7c7-19d9-4c69-b64c-2f7b8657d89a" id="a4d5c7c7-19d9-4c69-b64c-2f7b8657d89a">
        <active>true</active>
        <bootable>false</bootable>
        <interface>virtio</interface>
        <pass_discard>false</pass_discard>
        <read_only>true</read_only>
        <uses_scsi_reservation>false</uses_scsi_reservation>
        <disk href="/ovirt-engine/api/disks/a4d5c7c7-19d9-4c69-b64c-2f7b8657d89a" id="a4d5c7c7-19d9-4c69-b64c-2f7b8657d89a"/>
        <vm href="/ovirt-engine/api/vms/20880dbd-8970-426a-a31c-08204bbbdd39" id="20880dbd-8970-426a-a31c-08204bbbdd39"/>
    </disk_attachment>
</disk_attachments>

Check inside VM:
[root@vm-30-85 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0     11:0    1 1024M  0 rom  
vda    253:0    0   10G  0 disk 
├─vda1 253:1    0    1M  0 part 
├─vda2 253:2    0  100M  0 part /boot/efi
└─vda3 253:3    0  9.9G  0 part /
vdb    253:16   0    3G  1 disk 
└─vdb1 253:17   0    3G  1 part /mnt/test

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Verified with:
ovirt-engine-4.4.4.6-0.1.el8ev.noarch

Steps:
1. Create a VM with disk
2. Run VM
3. Create iSCSI direct lun
4. Attach direct lun as RO to the VM
5. Mount the lun in the guest
6. Get vm diskattachments via API

Result:
The logical name of direct lun is present.

<disk_attachments>
    <disk_attachment href="/ovirt-engine/api/vms/6f0a90f4-eb0e-44f8-a9bc-d051557316de/diskattachments/9a8c4fbf-202a-43d8-b116-7e14a8f1ca37" id="9a8c4fbf-202a-43d8-b116-7e14a8f1ca37">
        <active>true</active>
        <bootable>true</bootable>
        <interface>virtio</interface>
        <logical_name>/dev/vda</logical_name>
        <pass_discard>false</pass_discard>
        <read_only>false</read_only>
        <uses_scsi_reservation>false</uses_scsi_reservation>
        <disk href="/ovirt-engine/api/disks/9a8c4fbf-202a-43d8-b116-7e14a8f1ca37" id="9a8c4fbf-202a-43d8-b116-7e14a8f1ca37"/>
        <vm href="/ovirt-engine/api/vms/6f0a90f4-eb0e-44f8-a9bc-d051557316de" id="6f0a90f4-eb0e-44f8-a9bc-d051557316de"/>
    </disk_attachment>
    <disk_attachment href="/ovirt-engine/api/vms/6f0a90f4-eb0e-44f8-a9bc-d051557316de/diskattachments/63525a05-140d-4c5e-9df9-6a2a109db4fd" id="63525a05-140d-4c5e-9df9-6a2a109db4fd">
        <active>true</active>
        <bootable>false</bootable>
        <interface>virtio</interface>
        <logical_name>/dev/vdb</logical_name>
        <pass_discard>false</pass_discard>
        <read_only>true</read_only>
        <uses_scsi_reservation>false</uses_scsi_reservation>
        <disk href="/ovirt-engine/api/disks/63525a05-140d-4c5e-9df9-6a2a109db4fd" id="63525a05-140d-4c5e-9df9-6a2a109db4fd"/>
        <vm href="/ovirt-engine/api/vms/6f0a90f4-eb0e-44f8-a9bc-d051557316de" id="6f0a90f4-eb0e-44f8-a9bc-d051557316de"/>
    </disk_attachment>
</disk_attachments>

This bugzilla is included in oVirt 4.4.4 release, published on December 21st 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.4 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.