Bug 1465488 - [REST] Disk attachment doesn't show logical_name value for direct LUNs
[REST] Disk attachment doesn't show logical_name value for direct LUNs
Status: CLOSED DUPLICATE of bug 1477600
Product: ovirt-guest-agent
Classification: oVirt
Component: General (Show other bugs)
---
Unspecified Unspecified
medium Severity medium (vote)
: ovirt-4.1.7
: ---
Assigned To: Tomáš Golembiovský
Pavel Stehlik
: Automation
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-27 10:08 EDT by Lilach Zitnitski
Modified: 2017-09-12 15:41 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-09-12 15:41:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.1+


Attachments (Terms of Use)

  None (edit)
Description Lilach Zitnitski 2017-06-27 10:08:43 EDT
Description of problem:
When creating VM and attaching direct LUN to it, the direct LUN's logical name does not appear in the REST diskattachments, while for regular disks (images) the logical name does appear. 

Version-Release number of selected component (if applicable):
ovirt-engine-4.2.0-0.0.master.20170625221420.git9d461c8.el7.centos.noarch
vdsm-4.20.1-67.git4721d69.el7.centos.x86_64

How reproducible:
100%

Steps to Reproduce:
1. create new VM
2. create and attach direct LUN to this VM
3. start the VM
4. in REST /ovirt-engine/api/v4/vms/{vm_id}/diskattachments look for <logical_name> in the direct lun attachment

Actual results:
Direct LUN disk attachment does not have logical_name value

Expected results:
It should have 

Additional info:

<disk_attachments>
<disk_attachment href= "/ovirt-engine/api/v4/vms/6a73ebb7-0d3c-43bd-88cb-5752797b99ef/diskattachments/496e772d-e23d-4f42-aaab-715e6dec2e3a" id="496e772d-e23d-4f42-aaab-715e6dec2e3a">
<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/v4/disks/496e772d-e23d-4f42-aaab-715e6dec2e3a" id="496e772d-e23d-4f42-aaab-715e6dec2e3a"/>
<vm href= "/ovirt-engine/api/v4/vms/6a73ebb7-0d3c-43bd-88cb-5752797b99ef" id="6a73ebb7-0d3c-43bd-88cb-5752797b99ef"/>
</disk_attachment>
<disk_attachment href= "/ovirt-engine/api/v4/vms/6a73ebb7-0d3c-43bd-88cb-5752797b99ef/diskattachments/db21d54a-6939-4551-8621-4bbb93e2cdbf" id="db21d54a-6939-4551-8621-4bbb93e2cdbf">
<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/v4/disks/db21d54a-6939-4551-8621-4bbb93e2cdbf" id="db21d54a-6939-4551-8621-4bbb93e2cdbf"/>
<vm href= "/ovirt-engine/api/v4/vms/6a73ebb7-0d3c-43bd-88cb-5752797b99ef" id="6a73ebb7-0d3c-43bd-88cb-5752797b99ef"/>
</disk_attachment>
</disk_attachments>

The logical_name doesn't appear for virtio_scsi as well
Comment 1 Allon Mureinik 2017-06-27 11:03:51 EDT
Lilach, does this work properly on 4.2.0, or did it never work?
Comment 2 Lilach Zitnitski 2017-07-02 04:03:52 EDT
(In reply to Allon Mureinik from comment #1)
> Lilach, does this work properly on 4.2.0, or did it never work?

It doesn't work on 4.2.0, also not on 4.1.3. 
I don't have older version to test it on, but it's written in one of our automation tests, which is why I believe it used to work in the past.
Comment 3 Lilach Zitnitski 2017-08-03 03:13:54 EDT
This is also happening for image type disks, sometimes the disk attachment doesn't show logical_name even after more than 5 minutes after starting the VM.
Comment 6 Tal Nisan 2017-08-29 11:43:44 EDT
Tried to reproduce, it takes time indeed until the logical names data is populated in the engine but this info is coming from the guest agent, from the storage aspect we have not much to do about it, data comes in from the guest agent, stored in the DB and displayed though the REST.
Moving to guest agent to investigate their aspect of the bug.
Comment 7 Tomáš Golembiovský 2017-08-29 18:39:58 EDT
Could you please send what is the guest OS, version of oVirt GA and the output of
command '/usr/share/ovirt-guest-agent/diskmapper.script' run as root?

This feature relies on the definition of serial number of the disk. And as the
libvirt documentation says for the <serial> element:

    Not supported for scsi-block devices, that is those using disk type 'block' using device 'lun' on bus 'scsi'.

So please check also the domain XML to make sure whether this is or is not the case.
Comment 8 Lilach Zitnitski 2017-09-06 07:23:22 EDT
(In reply to Tomáš Golembiovský from comment #7)
> Could you please send what is the guest OS, version of oVirt GA and the
> output of
> command '/usr/share/ovirt-guest-agent/diskmapper.script' run as root?
> 

Red Hat Enterprise Linux Server release 7.3 (Maipo)

ovirt-guest-agent-common-1.0.13-3.el7ev.noarch

[root@localhost ~]# /usr/share/ovirt-guest-agent/diskmapper
/dev/sr0|QEMU_DVD-ROM_QM00003
/dev/vda|79395864-a30d-413b-a

> This feature relies on the definition of serial number of the disk. And as
> the
> libvirt documentation says for the <serial> element:
> 
>     Not supported for scsi-block devices, that is those using disk type
> 'block' using device 'lun' on bus 'scsi'.
> 
> So please check also the domain XML to make sure whether this is or is not
> the case.

Wasn't really sure what domain xml you meant, this is the direct lun's part in the xml output in the vdsm.log. Hope this will be helpful

<disk device="disk" snapshot="no" type="block">
    <source dev="/dev/mapper/3514f0c5a51600286" />
    <target bus="virtio" dev="vdb" />
    <readonly />
    <driver cache="none" error_policy="stop" io="native" name="qemu" type="raw" />
</disk>
Comment 9 Tomáš Golembiovský 2017-09-12 15:41:05 EDT
This looks OK and reporting should work. I'd say it is the same issue as in bug 1477600.

*** This bug has been marked as a duplicate of bug 1477600 ***

Note You need to log in before you can comment on or make changes to this bug.