Bug 1904774 - Direct lun disk is reflected on the guest by lun ID instead of disk ID
Summary: Direct lun disk is reflected on the guest by lun ID instead of disk ID
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.4.3
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ovirt-4.4.4
: 4.4.4.4
Assignee: Liran Rotenberg
QA Contact: Ilan Zuckerman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-06 10:09 UTC by Ilan Zuckerman
Modified: 2021-11-04 19:28 UTC (History)
5 users (show)

Fixed In Version: vdsm-4.40.40 ovirt-engine-4.4.4.4
Clone Of:
Environment:
Last Closed: 2021-01-22 12:51:29 UTC
oVirt Team: Virt
Embargoed:
pm-rhel: ovirt-4.4+
pm-rhel: planning_ack+
ahadas: devel_ack+
pm-rhel: testing_ack+


Attachments (Terms of Use)
VM dumpxml comparison. left: 4.4.4-3 right: 4.4.4-2 (111.53 KB, image/png)
2020-12-06 10:09 UTC, Ilan Zuckerman
no flags Details
VM dumpxmls (6.99 KB, application/zip)
2020-12-06 10:09 UTC, Ilan Zuckerman
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 112528 0 master MERGED vdsbroker: change the serial to image id 2021-01-22 12:51:13 UTC
oVirt gerrit 112529 0 master MERGED vmdevices: handle mapping of luns with image id 2021-01-22 12:51:54 UTC

Description Ilan Zuckerman 2020-12-06 10:09:04 UTC
Created attachment 1736912 [details]
VM dumpxml comparison. left: 4.4.4-3 right: 4.4.4-2

Description of problem:

When comparing rhv-4.4.4-3 with 4.4.4-2 on how a direct lun disk attached to a VM is identified on the guest OS, there is difference between the two versions.
When looking at dumpxml of the same VM, On the 4.4.4-3 it is identified both, by 'serial' and by 'alias name' as opposed to only having the 'alias name' in 4.4.4-2.
See image attached.

This may break backup vendors using the image id to find the backup disk
inside the backup appliance.
https://www.ovirt.org/documentation/administration_guide/#sect-Backing_Up_and_Restoring_Virtual_Machines_Using_the_Backup_and_Restore_API

It also makes direct LUN and images behave differently. Previously you could
find the disk inside a vm by the image id (/dev/disk/by-id/*image-id*), regardless
of the type of the disk, but now you have to write special code for each type.

For example:

on rhv-4.4.4-2 (this is by disk ID):

[root@localhost ~]# ls -l /dev/disk/by-id
lrwxrwxrwx. 1 root root  9 Nov 29 15:09 scsi-0QEMU_QEMU_HARDDISK_drive-ua-69585e80-5f5e-47fe-8322-f9f132ba78ad -> ../../sda


on 4.4.4-3 (this is by lun id):

[root@vm-83-53 ~]# ls -l /dev/disk/by-id
lrwxrwxrwx. 1 root root  9 Nov 29 15:16 scsi-360002ac000000000000012fe00021f6b -> ../../sda


VM dumpXMLs are stored here, in order to compare them:
rhv-4.4.4-3 :
4.4.4-3.xml

rhv-4.4.4-2 :
4.4.4-2.xml


Version-Release number of selected component (if applicable):
rhv-4.4.4-3

How reproducible:
100%

Steps to Reproduce:
1. Have VM rhel 8.2
2. Attach to it a direct lun disk
3. Compare the dumpxml with: 'virsh -r dumpxml vm-name'
4. Issue ls -l /dev/disk/by-id on the guest to see how the direct lun disk represented

Actual results:
4: Identified by direct lun ID
lrwxrwxrwx. 1 root root  9 Nov 29 15:16 scsi-360002ac000000000000012fe00021f6b -> ../../sda

Expected results:
Should have been identified by Disk ID:
lrwxrwxrwx. 1 root root  9 Nov 29 15:09 scsi-0QEMU_QEMU_HARDDISK_drive-ua-69585e80-5f5e-47fe-8322-f9f132ba78ad -> ../../sda

Comment 1 Ilan Zuckerman 2020-12-06 10:09:45 UTC
Created attachment 1736913 [details]
VM dumpxmls

Comment 2 Liran Rotenberg 2020-12-06 10:17:30 UTC
This is due to bz 1859092. We added serial to the LUNs, having the LUN ID.
After fixing it back to image ID, when using virtio-scsi interface and pass-through is on it still will be the LUN ID, as always.
The other interfaces and when the lun won't be pass-through, the image ID should be set.

Comment 4 Ilan Zuckerman 2021-01-20 09:21:24 UTC
Verified on rhv-release-4.4.5-1

Direct lun disk is now identified by the partial disk ID on the guest.

[root@vm-13-49 ~]# ls -l /dev/disk/by-id
total 0
lrwxrwxrwx. 1 root root  9 Jan 20 11:10 ata-QEMU_DVD-ROM_QM00005 -> ../../sr0
lrwxrwxrwx. 1 root root  9 Jan 20 11:10 scsi-0QEMU_QEMU_HARDDISK_0e1a4432-0f47-481c-aa1f-e1a72e7f0bd9 -> ../../sda
lrwxrwxrwx. 1 root root  9 Jan 20 11:10 scsi-SQEMU_QEMU_HARDDISK_0e1a4432-0f47-481c-aa1f-e1a72e7f0bd9 -> ../../sda
lrwxrwxrwx. 1 root root  9 Jan 20 11:10 virtio-dd9dd5a7-8ae5-4359-8 -> ../../vda
lrwxrwxrwx. 1 root root 10 Jan 20 11:10 virtio-dd9dd5a7-8ae5-4359-8-part1 -> ../../vda1
lrwxrwxrwx. 1 root root 10 Jan 20 11:10 virtio-dd9dd5a7-8ae5-4359-8-part2 -> ../../vda2
lrwxrwxrwx. 1 root root 10 Jan 20 11:10 virtio-dd9dd5a7-8ae5-4359-8-part3 -> ../../vda3


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