Bug 1916159

Summary:	[RFE] GET diskattachments for a VM using qemu-guest-agent is missing a logical_name for disks without monted file-system [RHV clone - 4.3.14]
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	RHV bug bot <rhv-bugzilla-bot>
Component:	vdsm	Assignee:	Tomáš Golembiovský <tgolembi>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Tamir <tamir>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.3.9	CC:	aefrat, ahadas, bugs, cshao, emarcus, gveitmic, jko, lsurette, lsvaty, marcandre.lureau, mavital, mkalinin, mtessun, pelauter, sbonazzo, srevivo, tamir, tgolembi, ycui
Target Milestone:	ovirt-4.3.13	Keywords:	FutureFeature, TestOnly, ZStream
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	vdsm-4.30.51-1.el7ev	Doc Type:	Enhancement
Doc Text:	Previously the logical names for disks without a mounted filesystem were not displayed in the oVirt Engine. In this release, logical names for such disks are now properly reported provided the version of QEMU Guest Agent in the VM is 5.2 or higher.	Story Points:	---
Clone Of:	1836661	Environment:
Last Closed:	2021-02-16 15:33:54 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1836661, 1913818
Bug Blocks:

Description RHV bug bot 2021-01-14 11:27:17 UTC

+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1836661 +++
======================================================================

Description of problem:
The REST api for "diskattachments" should have for each disk its logical name as appears in the VM, but this value is missing from the diskattachments.
This issue appears when it is a VM using "qemu-guest-agent", and when using "ovirt-guest-agent" it displays logical-name.


Version-Release number of selected component (if applicable):
* RHVM:
 - rhvm-4.3.9.4-11.el7.noarch
 - ovirt-engine-4.3.9.4-11.el7.noarch
* RHVHs:
 - vdsm-4.30.44-1.el7ev.x86_64
 - qemu-kvm-rhev-2.12.0-44.el7_8.2.x86_64

* Guest VMs:
 - Test VM1 (e.g. 91860544-b90e-4b0d-a4e3-20f0d7c72acf)
  * REHL7.8 with overt-guest-agent 
  * with attached two more unmounded disk
 - Test VM2 (e.g. 50016c46-c626-4dd0-aba4-d80f27005357)
  * REHL8.2(or rhel7.8) with qemu-guest-agent-2.12.0-99.module+el8.2.0+5827+8c39933c.x86_64
  * with attached two more unmounded disk


How reproducible:
100%


Steps to Reproduce:
1. Create Rhel8.x VM(with qemu-guest-agent)
2. Create and attach a new Disk and this disk is not mounted
3. Check Logical Name of the disks via UI and REST API


Actual results:
The newly attached and unmouned disk of the VM using "qemu-guest-agent" is missing logical name.


Expected results:
A VM using ovirt-guest-agent can appear the logical name of a new unmounted disk.
Disk's Logical Name should be there for each disk attachments on REST API and UI even though using qemu-geust-agent.
This should be included in RHV 4.3.z as well as the master version.


Additional info:
VM1 using Ovirt-guest-agent and VM2 using qemu-guest-agent are compared.

* VM1
===============================================================
- Disk information on DB ————————————
[root@rhvm ~]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select device_id,logical_name from vm_device_view where device='disk' and vm_id = '91860544-b90e-4b0d-a4e3-20f0d7c72acf'"
              device_id               | logical_name
--------------------------------------+--------------
 d3cf2b14-0bcf-44b5-86fd-30d3d2373d27 | /dev/sda
 5eee50c0-23e9-4053-a44b-101c924bf149 | /dev/sdb
 8290b2a2-a7d9-4f2f-a23e-1110c66dd3da | /dev/sdc
 
- Diskattachments REST api ———————————
[root@rhvm ~]# curl --request GET --header 'Version: 4' --header "Accept: application/json" --cacert rhvm_ca.pem --user "admin@internal:redhat" https://rhvm.jtredhat.com/ovirt-engine/api/vms/91860544-b90e-4b0d-a4e3-20f0d7c72acf/diskattachments
{
  "disk_attachment" : [ {
    "active" : "true",
    "bootable" : "true",
    "interface" : "virtio_scsi",
    "logical_name" : "/dev/sda",
    "pass_discard" : "false",
    "read_only" : "false",
    "uses_scsi_reservation" : "false",
    "disk" : {
      "href" : "/ovirt-engine/api/disks/d3cf2b14-0bcf-44b5-86fd-30d3d2373d27",
      "id" : "d3cf2b14-0bcf-44b5-86fd-30d3d2373d27"
    },
    "vm" : {
      "href" : "/ovirt-engine/api/vms/91860544-b90e-4b0d-a4e3-20f0d7c72acf",
      "id" : "91860544-b90e-4b0d-a4e3-20f0d7c72acf"
    },
    "href" : "/ovirt-engine/api/vms/91860544-b90e-4b0d-a4e3-20f0d7c72acf/diskattachments/d3cf2b14-0bcf-44b5-86fd-30d3d2373d27",
    "id" : "d3cf2b14-0bcf-44b5-86fd-30d3d2373d27"
  }, {
    "active" : "true",
    "bootable" : "false",
    "interface" : "virtio_scsi",
    "logical_name" : "/dev/sdb",
    "pass_discard" : "false",
    "read_only" : "false",
    "uses_scsi_reservation" : "false",
    "disk" : {
      "href" : "/ovirt-engine/api/disks/5eee50c0-23e9-4053-a44b-101c924bf149",
      "id" : "5eee50c0-23e9-4053-a44b-101c924bf149"
    },
    "vm" : {
      "href" : "/ovirt-engine/api/vms/91860544-b90e-4b0d-a4e3-20f0d7c72acf",
      "id" : "91860544-b90e-4b0d-a4e3-20f0d7c72acf"
    },
    "href" : "/ovirt-engine/api/vms/91860544-b90e-4b0d-a4e3-20f0d7c72acf/diskattachments/5eee50c0-23e9-4053-a44b-101c924bf149",
    "id" : "5eee50c0-23e9-4053-a44b-101c924bf149"
  }, {
    "active" : "true",
    "bootable" : "false",
    "interface" : "virtio_scsi",
    "logical_name" : "/dev/sdc",
    "pass_discard" : "false",
    "read_only" : "false",
    "uses_scsi_reservation" : "false",
    "disk" : {
      "href" : "/ovirt-engine/api/disks/8290b2a2-a7d9-4f2f-a23e-1110c66dd3da",
      "id" : "8290b2a2-a7d9-4f2f-a23e-1110c66dd3da"
    },
    "vm" : {
      "href" : "/ovirt-engine/api/vms/91860544-b90e-4b0d-a4e3-20f0d7c72acf",
      "id" : "91860544-b90e-4b0d-a4e3-20f0d7c72acf"
    },
    "href" : "/ovirt-engine/api/vms/91860544-b90e-4b0d-a4e3-20f0d7c72acf/diskattachments/8290b2a2-a7d9-4f2f-a23e-1110c66dd3da",
    "id" : "8290b2a2-a7d9-4f2f-a23e-1110c66dd3da"
  } ]
}

* VM2
===============================================================
- Disk information on DB ————————————
[root@rhvm ~]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select device_id,logical_name from vm_device_view where device='disk' and vm_id = '50016c46-c626-4dd0-aba4-d80f27005357'"
              device_id               | logical_name
--------------------------------------+--------------
 d8dce279-94f9-452e-bfa3-b3a291cc3f7e |
 f93ac8ba-00c3-4167-99c3-8e3ca5f2513b | /dev/sda2
 63141989-2ee5-4f06-ae1f-cfea33475727 |

- Diskattachments REST api ———————————
[root@rhvm ~]# curl --request GET --header 'Version: 4' --header "Accept: application/json" --cacert rhvm_ca.pem --user "admin@internal:redhat" https://rhvm.jtredhat.com/ovirt-engine/api/vms/50016c46-c626-4dd0-aba4-d80f27005357/diskattachments
{
  "disk_attachment" : [ {
    "active" : "true",
    "bootable" : "false",
    "interface" : "virtio_scsi",
    "pass_discard" : "false",
    "read_only" : "false",
    "uses_scsi_reservation" : "false",
    "disk" : {
      "href" : "/ovirt-engine/api/disks/d8dce279-94f9-452e-bfa3-b3a291cc3f7e",
      "id" : "d8dce279-94f9-452e-bfa3-b3a291cc3f7e"
    },
    "vm" : {
      "href" : "/ovirt-engine/api/vms/50016c46-c626-4dd0-aba4-d80f27005357",
      "id" : "50016c46-c626-4dd0-aba4-d80f27005357"
    },
    "href" : "/ovirt-engine/api/vms/50016c46-c626-4dd0-aba4-d80f27005357/diskattachments/d8dce279-94f9-452e-bfa3-b3a291cc3f7e",
    "id" : "d8dce279-94f9-452e-bfa3-b3a291cc3f7e"
  }, {
    "active" : "true",
    "bootable" : "true",
    "interface" : "virtio_scsi",
    "logical_name" : "/dev/sda2",
    "pass_discard" : "false",
    "read_only" : "false",
    "uses_scsi_reservation" : "false",
    "disk" : {
      "href" : "/ovirt-engine/api/disks/f93ac8ba-00c3-4167-99c3-8e3ca5f2513b",
      "id" : "f93ac8ba-00c3-4167-99c3-8e3ca5f2513b"
    },
    "vm" : {
      "href" : "/ovirt-engine/api/vms/50016c46-c626-4dd0-aba4-d80f27005357",
      "id" : "50016c46-c626-4dd0-aba4-d80f27005357"
    },
    "href" : "/ovirt-engine/api/vms/50016c46-c626-4dd0-aba4-d80f27005357/diskattachments/f93ac8ba-00c3-4167-99c3-8e3ca5f2513b",
    "id" : "f93ac8ba-00c3-4167-99c3-8e3ca5f2513b"
  }, {
    "active" : "true",
    "bootable" : "false",
    "interface" : "virtio_scsi",
    "pass_discard" : "false",
    "read_only" : "false",
    "uses_scsi_reservation" : "false",
    "disk" : {
      "href" : "/ovirt-engine/api/disks/63141989-2ee5-4f06-ae1f-cfea33475727",
      "id" : "63141989-2ee5-4f06-ae1f-cfea33475727"
    },
    "vm" : {
      "href" : "/ovirt-engine/api/vms/50016c46-c626-4dd0-aba4-d80f27005357",
      "id" : "50016c46-c626-4dd0-aba4-d80f27005357"
    },
    "href" : "/ovirt-engine/api/vms/50016c46-c626-4dd0-aba4-d80f27005357/diskattachments/63141989-2ee5-4f06-ae1f-cfea33475727",
    "id" : "63141989-2ee5-4f06-ae1f-cfea33475727"
  } ]
}


This problem seems to be a bug because it was provided by ovirt-qemu-agent, but if not, please treat it as a REF.

(Originally by Jeongtae Kim)

Comment 1 RHV bug bot 2021-01-14 11:27:26 UTC

Not a regression. It's a documented change in functionality. This is a clear duplicate of the RFE. Any reason to keep it open?

(Originally by rbarry)

Comment 2 RHV bug bot 2021-01-14 11:27:31 UTC

(In reply to Germano Veit Michel from comment #3)
> (In reply to Ryan Barry from comment #2)
> > Not a regression. It's a documented change in functionality. This is a clear
> > duplicate of the RFE. Any reason to keep it open?
> 
> Do you mean BZ1793290? That is a bug for incorrect parsing of logical_name,
> not the RFE.
> Or is there another RFE for this somewhere else?

I don't think anyone has opened the RFE bug yet, so let's use this one for it.

Note that this requires fix in QEMU Guest Agent

(Originally by Tomas Golembiovsky)

Comment 15 RHV bug bot 2021-01-14 11:28:07 UTC

(In reply to Ryan Barry from comment #2)
> Not a regression. It's a documented change in functionality. This is a clear
> duplicate of the RFE. Any reason to keep it open?

Do you mean BZ1793290? That is a bug for incorrect parsing of logical_name, not the RFE.
Or is there another RFE for this somewhere else?

(Originally by Germano Veit Michel)

Comment 24 RHV bug bot 2021-01-14 11:31:47 UTC

This bug is in POST status for ovirt 4.4.4. We are now in blocker only phase, please either mark this as a blocker or please re-target.

(Originally by Sandro Bonazzola)

Comment 29 Sandro Bonazzola 2021-02-02 14:31:29 UTC

Moving out to 4.3.14, needs RHEL 8.3.1 to be released.

Comment 31 Sandro Bonazzola 2021-02-02 14:35:20 UTC

Fix for this bugzilla was shipped with 4.3.13 milestone but couldn't be tested due to missing updated qemu-guest-agent on RHEL 8.
Moving to test only for 4.3.14.

Comment 38 Tamir 2021-02-14 09:15:20 UTC

Verified on RHV 4.3.11-8. All looks good to me.

Env:
  - Engine instance with RHV 4.3.11-8 (ovirt-engine-4.3.11.4-0.1.el7) and RHEL 7.9 installed.
  - A host with RHV 4.3.11-8 and RHEL 7.9 with vdsm-4.30.51-1.el7ev and qemu-kvm-rhev.x86_64 10:2.12.0-48.el7_9.1

Steps:
1. Create a 4.3 data center and a 4.3 cluster.
2. Install the host and create a new NFS storage domain.
3. Import a RHEL 8.3 template from glance.
4. Create a VM from the RHEL 8.3 template with another disk.
5. Install qemu-guest-agent-4.2.0-34.module+el8.3.0+9828+7aab3355.3.x86_64.rpm in the VM.
6. Reboot the VM.
7. Check that the logical name of the created disk is visible both in GUI and DB.  


Results (As Expected):
Actual results:
1. The 4.3 data center and the 4.3 cluster were created.
2. The host was installed and the NFS storage domain was created.
3. The template was imported.
4. The VM was created.
5. The qemu-guest-agent-4.2.0-34.module+el8.3.0+9828+7aab3355.3.x86_64.rpm is installed in the VM.
6. The VM was shutdown and gone up.
7. The logical name of the created disk is visible both in GUI and DB.