Bug 1465488
| Summary: | [REST] Disk attachment doesn't show logical_name value for direct LUNs | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-guest-agent | Reporter: | Lilach Zitnitski <lzitnits> |
| Component: | General | Assignee: | Tomáš Golembiovský <tgolembi> |
| Status: | CLOSED DUPLICATE | QA Contact: | Pavel Stehlik <pstehlik> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | --- | CC: | amureini, bugs, lzitnits, tnisan, ylavi |
| Target Milestone: | ovirt-4.1.7 | Keywords: | Automation |
| Target Release: | --- | Flags: | rule-engine:
ovirt-4.1+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-09-12 19:41:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Lilach, does this work properly on 4.2.0, or did it never work? (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. 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. 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. 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.
(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> 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 *** |
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