Bug 1904774

Summary: Direct lun disk is reflected on the guest by lun ID instead of disk ID
Product: [oVirt] ovirt-engine Reporter: Ilan Zuckerman <izuckerm>
Component: BLL.VirtAssignee: Liran Rotenberg <lrotenbe>
Status: CLOSED CURRENTRELEASE QA Contact: Ilan Zuckerman <izuckerm>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.4.3CC: ahadas, bugs, lrotenbe, sfishbai, tnisan
Target Milestone: ovirt-4.4.4Flags: pm-rhel: ovirt-4.4+
pm-rhel: planning_ack+
ahadas: devel_ack+
pm-rhel: testing_ack+
Target Release: 4.4.4.4   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: vdsm-4.40.40 ovirt-engine-4.4.4.4 Doc Type: Bug Fix
Doc Text:
Previously, we had LUNs with serial set with the LUN ID. Now, it will be with the image ID as other disk types. The only different case is when the LUN is using VirtIO-SCSI interface with pass-through. In that case, it will have the LUN ID set as serial.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2021-01-22 12:51:29 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:
Attachments:
Description Flags
VM dumpxml comparison. left: 4.4.4-3 right: 4.4.4-2
none
VM dumpxmls none

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