Bug 1130475

Summary: fail to specify wwn for virtual IDE CD-ROM
Product: Red Hat Enterprise Linux 6 Reporter: Sibiao Luo <sluo>
Component: qemu-kvmAssignee: John Snow <jsnow>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.5CC: chayang, famz, jsnow, juzhang, kwolf, mazhang, michen, mkenneth, pbonzini, qzhang, rbalakri, rpacheco, virt-maint, xigao
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-0.12.1.2-2.449.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1131316 (view as bug list) Environment:
Last Closed: 2015-07-22 06:07:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 1130438, 1220617    
Bug Blocks: 1131316, 1150820    

Description Sibiao Luo 2014-08-15 10:30:28 UTC
Description of problem:
fail to specify wwn for virtual IDE CD-ROM, but it can specify wwn for virtual SCSI CD-ROM.
BTW, we have fixed it for the virtual IDE disk in bug 1032443.

Version-Release number of selected component (if applicable):
host info:
# uname -r && rpm -q qemu-kvm-rhev
2.6.32-496.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.437.el6.x86_64
guest info:
2.6.32-496.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot guest with setting <wwn> to ide-dirve for virtual IDE CD-ROM/disk.
e.g.:...-drive file=/home/RHEL-Server-6.5-64-virtio.qcow2,if=none,id=drive-virtio-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device ide-drive,bus=ide.0,unit=0,wwn=0x5000c50015ea71bb,drive=drive-virtio-disk,id=virtio-disk,bootindex=1...-drive file=/home/en_windows_server_2012_r2_x64_dvd_2707946.iso,if=none,id=hd,format=raw,media=cdrom,readonly=on,cache=none,werror=stop,rerror=stop -device ide-drive,bus=ide.0,unit=1,wwn=0x5000c50015ea71ad,drive=hd,id=cdrom
2.check the device identification.
# ls -l /dev/disk/by-id/wwn*
# sg_inq -p 0x83 /dev/srX (or sg_vpd)

Actual results:
after step 2, it fail to specify wwn for virtual IDE CD-ROM.
# ls -l /dev/disk/by-id/wwn*
lrwxrwxrwx. 1 root root  9 Aug 15 09:38 /dev/disk/by-id/wwn-0x5000c50015ea71bb -> ../../sda
lrwxrwxrwx. 1 root root 10 Aug 15 09:38 /dev/disk/by-id/wwn-0x5000c50015ea71bb-part1 -> ../../sda1
lrwxrwxrwx. 1 root root 10 Aug 15 09:38 /dev/disk/by-id/wwn-0x5000c50015ea71bb-part2 -> ../../sda2
# ls -lh /dev/cdrom2 
lrwxrwxrwx. 1 root root 3 Aug 15 09:38 /dev/cdrom2 -> sr0
# sg_inq -p 0x83 /dev/sda
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 24
    designator_type: vendor specific [0x0],  code_set: ASCII
    associated with the addressed logical unit
      vendor specific: QM00001             
  Designation descriptor number 2, descriptor length: 72
    designator_type: T10 vendor identification,  code_set: ASCII
    associated with the addressed logical unit
      vendor id: ATA     
      vendor specific: QEMU HARDDISK                           QM00001             
  Designation descriptor number 3, descriptor length: 12
    designator_type: NAA,  code_set: Binary
    associated with the addressed logical unit
      NAA 5, IEEE Company_id: 0xc50
      Vendor Specific Identifier: 0x15ea71bb
      [0x5000c50015ea71bb]
# sg_inq -p 0x83 /dev/sr0 
VPD INQUIRY: Device Identification page
invalid VPD response; probably a STANDARD INQUIRY response

Expected results:
it can specify wwn for virtual IDE CD-ROM correctly.

Additional info:
Also tried to specify the wwn for virtual *SCSI* CD-ROM which did not hit this issue.
# ls -lh /dev/disk/by-id/wwn*
lrwxrwxrwx. 1 root root  9 Aug 15 12:01 /dev/disk/by-id/scsi-35000c50015ea71ad -> ../../sr1
lrwxrwxrwx. 1 root root  9 Aug 15 12:01 /dev/disk/by-id/wwn-0x5000c50015ea71ad -> ../../sr1
# sg_inq -p 0x83 /dev/sr1
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 10
    designator_type: vendor specific [0x0],  code_set: ASCII
    associated with the addressed logical unit
      vendor specific: ababab
  Designation descriptor number 2, descriptor length: 12
    designator_type: NAA,  code_set: Binary
    associated with the addressed logical unit
      NAA 5, IEEE Company_id: 0xc50
      Vendor Specific Identifier: 0x15ea71ad
      [0x5000c50015ea71ad]

Comment 1 Sibiao Luo 2014-08-19 02:47:51 UTC
ide-drive.wwn, ide-hd.wwn, ide-cd.wwn were supported at the same time and they similar for scsi-disk.wwn, scsi-hd.wwn, and scsi-cd.wwn.

We should high night it somewhere if not support specifying wwn for virtual IDE CD-ROM.

Best Regards,
sluo

Comment 3 John Snow 2014-08-27 16:24:29 UTC
A fix was posted upstream, http://lists.gnu.org/archive/html/qemu-devel/2014-08/msg03295.html, and reviewed by Fam Zheng but has not been pulled or merged yet.

Comment 4 Jeff Nelson 2014-12-19 18:50:27 UTC
Fix included in qemu-kvm-0.12.1.2-2.449.el6

Comment 6 Sibiao Luo 2015-02-26 08:49:07 UTC
Try to verify this issue, but still fail to specify wwn for virtual IDE CD-ROM.

host info:
# uname -r && rpm -q qemu-kvm
2.6.32-538.el6.x86_64
qemu-kvm-0.12.1.2-2.454.el6.x86_64

e.g.:...-drive file=/home/my-cdrom.iso,if=none,id=hd,format=raw,media=cdrom,readonly=on,cache=none,werror=stop,rerror=stop -device ide-drive,bus=ide.0,unit=1,wwn=0x5000c50015ea71ad,drive=hd,id=cdrom

guest ]# ls -lh /dev/cdrom*
lrwxrwxrwx. 1 root root 3 Feb 26 11:33 /dev/cdrom2 -> sr0
guest ]# ls -l /dev/disk/by-id/wwn*
lrwxrwxrwx. 1 root root  9 Feb 26 11:33 /dev/disk/by-id/wwn-0x5000c50015ea71aa -> ../../sda
lrwxrwxrwx. 1 root root 10 Feb 26 11:33 /dev/disk/by-id/wwn-0x5000c50015ea71aa-part1 -> ../../sda1
lrwxrwxrwx. 1 root root 10 Feb 26 11:33 /dev/disk/by-id/wwn-0x5000c50015ea71aa-part2 -> ../../sda2

Base on above, this issue did not fix at all, re-assign it to fix.

Best Regards,
sluo

Comment 7 Paolo Bonzini 2015-03-27 10:30:34 UTC
Try with RHEL7 guest.  There is a bug open, IIRC, about CD-ROM WWNs in RHEL6 guests.

Comment 8 Paolo Bonzini 2015-03-27 10:31:03 UTC
Yes, it's bug 1130438, now ON_QA.

Comment 9 Sibiao Luo 2015-03-31 06:46:20 UTC
Verified this issue.

###### rhel6.7 host + rhel7.1 guest.
host info:
# uname -r && rpm -q qemu-kvm
2.6.32-546.el6.x86_64
qemu-kvm-0.12.1.2-2.462.el6.x86_64
guest info:
# uname -r
3.10.0-229.1.2.el7.x86_64

Result:
# ls -lh /dev/cdrom*
ls -lh /dev/cdrom*
lrwxrwxrwx. 1 root root 3 Mar 31 22:23 /dev/cdrom -> sr0
# ls -l /dev/disk/by-id/wwn*
ls -l /dev/disk/by-id/wwn*
lrwxrwxrwx. 1 root root  9 Mar 31 22:23 /dev/disk/by-id/wwn-0x5000c50015ea71aa -> ../../sda
lrwxrwxrwx. 1 root root 10 Mar 31 22:23 /dev/disk/by-id/wwn-0x5000c50015ea71aa-part1 -> ../../sda1
lrwxrwxrwx. 1 root root 10 Mar 31 22:23 /dev/disk/by-id/wwn-0x5000c50015ea71aa-part2 -> ../../sda2
lrwxrwxrwx. 1 root root  9 Mar 31 22:23 /dev/disk/by-id/wwn-0x5000c50015ea71ad -> ../../sr0

###### rhel6.7 host + rhel6.7 guest.
It fail to fix at all, still blocked by bug 1130438#c18.
host info:
# uname -r && rpm -q qemu-kvm
2.6.32-546.el6.x86_64
qemu-kvm-0.12.1.2-2.462.el6.x86_64
guest info:
2.6.32-540.el6.x86_64
udev-147-2.61.el6.x86_64

Result:
# ls -lh /dev/cdrom*
lrwxrwxrwx. 1 root root 3 Mar 31 22:20 /dev/cdrom2 -> sr0

# ls -l /dev/disk/by-id/wwn*
lrwxrwxrwx. 1 root root  9 Mar 31 22:20 /dev/disk/by-id/wwn-0x5000c50015ea71aa -> ../../sda
lrwxrwxrwx. 1 root root 10 Mar 31 22:20 /dev/disk/by-id/wwn-0x5000c50015ea71aa-part1 -> ../../sda1
lrwxrwxrwx. 1 root root 10 Mar 31 22:20 /dev/disk/by-id/wwn-0x5000c50015ea71aa-part2 -> ../../sda2

Comment 12 Sibiao Luo 2015-04-24 03:09:52 UTC
Tried to verify this bug, but still hit this issue again, there is no any 

host info:
# uname -r && rpm -q qemu-kvm
2.6.32-544.el6.x86_64
qemu-kvm-0.12.1.2-2.466.el6.x86_64
guest info:
2.6.32-540.el6.x86_64
udev-147-2.62.el6.x86_64 (bug 1130438 has been fixed)

e.g:...-drive file=/home/RHEL6.7_Server_x86_64.qcow2,if=none,id=drive-virtio-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device ide-drive,bus=ide.0,unit=0,wwn=0x5000c50015ea71bb,drive=drive-virtio-disk,id=virtio-disk,bootindex=1...-drive file=/home/RHEL-6.7-20150415.0-Server-x86_64-dvd1.iso,if=none,id=hd,format=raw,media=cdrom,readonly=on,cache=none,werror=stop,rerror=stop -device ide-drive,bus=ide.0,unit=1,wwn=0x5000c50015ea71ad,drive=hd,id=cdrom

Results:
# ls -lh /dev/cdrom*
lrwxrwxrwx. 1 root root 3 Apr 24 18:56 /dev/cdrom2 -> sr0

# ls -lh /dev/disk/by-path/* | grep sr
lrwxrwxrwx. 1 root root  9 Apr 24 18:56 /dev/disk/by-path/pci-0000:00:01.1-scsi-0:0:1:0 -> ../../sr0

# ls -lh /dev/disk/by-id/* | grep sr
lrwxrwxrwx. 1 root root  9 Apr 24 18:56 /dev/disk/by-id/ata-QEMU_DVD-ROM_QM00002 -> ../../sr0

# ls -l /dev/disk/by-id/wwn*
lrwxrwxrwx. 1 root root  9 Apr 24 18:56 /dev/disk/by-id/wwn-0x5000c50015ea71bb -> ../../sda
lrwxrwxrwx. 1 root root 10 Apr 24 18:56 /dev/disk/by-id/wwn-0x5000c50015ea71bb-part1 -> ../../sda1
lrwxrwxrwx. 1 root root 10 Apr 24 18:56 /dev/disk/by-id/wwn-0x5000c50015ea71bb-part2 -> ../../sda2

# sg_inq -p 0x83 /dev/sr0
VPD INQUIRY: Device Identification page
invalid VPD response; probably a STANDARD INQUIRY response

Best Regards,
sluo

Comment 13 John Snow 2015-05-06 20:55:13 UTC
(1) sg_inq -p 0x83 /dev/sr0 can't be used as a tool for validating this bug for ATAPI devices, because even though ATAPI devices are supposed to respond to this query (0x83), in practice, no CDROM I have ever owned appears to respond to it.

For this reason we have decided not to backport a fix to allow QEMU's CDROM to respond to 0x83 queries, but that was a different BZ.

(2) Even using upstream QEMU which does respond to 0x83, this bug still exists only in RHEL6.7.

(3) It appears as though RHEL7.1 guest finds the WWN correctly, but RHEL6.7 guest does not. I am not sure why RHEL6.7's udev does not see the WWN, but it's present in the IDENTIFY data:

sg_inq --ata --hex /dev/sda
...
68 0000 0000 6000 0000 5000 c500 15ea 71bb
...

sg_inq --ata --hex /dev/sr0
...
68 0000 0000 0000 0000 5000 c500 15ea 71ad
...



I suspect more problems with udev. 

(A) Is it possible to request a udev developer attempt to debug the issue using qemu-kvm? They can likely find the reason the wwn is not appearing quicker than I will be able to; if the problem is how the device is responding I can fix it in QEMU, but given that:

(i) The IDENTIFY data looks correct to me, and
(ii) the scsi inquiry 0x83 data cannot be relied on for real hardware

I will need some more information to be able to fix this for you in RHEL6.7.

Comment 14 John Snow 2015-05-06 22:35:13 UTC
I am not 100%, but it appears that upstream udev (in systemd) has support for sending the 0xA1 PACKET_IDENTIFY command instead of the 0xEC IDENTIFY command which only works for ATA disks.

If you want to see WWN in rhel6.7 udev, you'll need to send the correct command to the device. Where I am confused is why sending the wrong command does *anything* at all, like getting the right model information and so on.

I suspect this is what you want (commit id taken from the upstream systemd git repo)

commit 560de575148b7efda3b34a7f7073abd483c5f08e
Author: David Zeuthen <davidz@redhat.com>
Date:   Thu Nov 4 08:55:58 2010 -0400

    Use ata_id, not scsi_id, on ATAPI devices

Comment 15 John Snow 2015-05-07 18:01:19 UTC
Moving back to ON_QA as this is another udev issue that prevents verification, but not a QEMU bug. If you make the determination that we want this in 6.7, I suggest opening a udev bug.

Comment 16 Sibiao Luo 2015-05-12 02:46:21 UTC
(In reply to John Snow from comment #13)
> (1) sg_inq -p 0x83 /dev/sr0 can't be used as a tool for validating this bug
> for ATAPI devices, because even though ATAPI devices are supposed to respond
> to this query (0x83), in practice, no CDROM I have ever owned appears to
> respond to it.
> 
> For this reason we have decided not to backport a fix to allow QEMU's CDROM
> to respond to 0x83 queries, but that was a different BZ.
FYI: Bug 1169630#c3, do not use sg3_utils with the --id flag or --page=0x83 to try to get the WWN of an ATAPI device. Use --ata instead.

> 
> (2) Even using upstream QEMU which does respond to 0x83, this bug still
> exists only in RHEL6.7.
> 
> (3) It appears as though RHEL7.1 guest finds the WWN correctly, but RHEL6.7
> guest does not. I am not sure why RHEL6.7's udev does not see the WWN, but
> it's present in the IDENTIFY data:
> 
> sg_inq --ata --hex /dev/sda
> ...
> 68 0000 0000 6000 0000 5000 c500 15ea 71bb
> ...
> 
> sg_inq --ata --hex /dev/sr0
> ...
> 68 0000 0000 0000 0000 5000 c500 15ea 71ad
> ...
> 
> 
> 
> I suspect more problems with udev. 
> 
> (A) Is it possible to request a udev developer attempt to debug the issue
> using qemu-kvm? They can likely find the reason the wwn is not appearing
> quicker than I will be able to; if the problem is how the device is
> responding I can fix it in QEMU, but given that:
> 
> (i) The IDENTIFY data looks correct to me, and
> (ii) the scsi inquiry 0x83 data cannot be relied on for real hardware
> 
> I will need some more information to be able to fix this for you in RHEL6.7.

And I have separated a udev new bug to track the wwn for ide cdrom.
Bug 1220617 - udev(in systemd) fail to identify WWN for ata DVD/CD

Best Regards,
sluo

Comment 18 Qunfang Zhang 2015-05-26 03:41:45 UTC
Hi, John

Do you have some suggestion on the verification for this bug if the udev bug 1220617 is not fixed in rhel6.7 on time?  It blocks us to verify this one. 

Thanks,
Qunfang

Comment 19 John Snow 2015-05-28 15:33:04 UTC
Honestly, I would say that the fact that a RHEL7 guest running under this RHEL6 qemu-kvm package proves that the QEMU component is already fixed. Since we have a bug for the udev component now, I think that's sufficient to verify this bug.

If you'd like to test it out: Use the rhel6 qemu-kvm on the host and install a rhel7 guest, then verify the WWN appears in the /dev/disk/by-id directory. This should be sufficient proof that QEMU supports WWNs for CDROM devices.

Comment 20 mazhang 2015-05-29 07:09:00 UTC
Reproduce this bug on qemu-kvm-0.12.1.2-2.445.el6.x86_64.

Host:
qemu-kvm-0.12.1.2-2.445.el6.x86_64
2.6.32-563.el6.x86_64

Guest:
2.6.32-563.el6.x86_64

Steps:
1. boot guest:
/usr/libexec/qemu-kvm \
-M pc \
-cpu SandyBridge \
-m 2G \
-smp 4,sockets=1,cores=2,threads=2 \
-enable-kvm \
-name rhel6.7 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-rtc base=localtime,driftfix=slew \
-nodefaults \
-monitor stdio \
-qmp tcp:0:6666,server,nowait \
-serial unix:/tmp/console0,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-vga std \
-vnc :0 \
-netdev tap,id=tap0 \
-usb -device usb-tablet,id=tblt0 \
-device virtio-net-pci,netdev=tap0,id=nic0,mac=1a:59:0a:4b:5a:94 \
-drive file=/home/boot.iso,if=none,media=cdrom,id=drive-ide0,readonly=on,format=raw \
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,wwn=0x5000c50015ea71ad \
-drive file=/home/rhel6.7.qcow2,if=none,id=drive-scsi-disk,format=qcow2,cache=none,werror=stop,rerror=stop \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,drive=drive-scsi-disk,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk,bootindex=1 \

2. Query the IDE CD-ROM in guest.

[root@test ~]# uname -r
2.6.32-563.el6.x86_64
[root@test ~]# ll /dev/cdrom 
lrwxrwxrwx. 1 root root 3 May 29 21:20 /dev/cdrom -> sr0
[root@test ~]# ls -l /dev/disk/by-id/wwn*
ls: cannot access /dev/disk/by-id/wwn*: No such file or directory



As comment#19 said , rhel6.7 have a bug for udev component, so update to qemu-kvm-0.12.1.2-2.475.el6.x86_64 and install a rhel7 guest to verify this bug.

Host:
qemu-kvm-0.12.1.2-2.475.el6.x86_64
2.6.32-563.el6.x86_64

Guest:
3.10.0-229.el7.x86_64

In guest:
[root@unused ~]# uname -r
3.10.0-229.el7.x86_64
[root@unused ~]# ll /dev/cdrom 
lrwxrwxrwx. 1 root root 3 May 29 23:00 /dev/cdrom -> sr0
[root@unused ~]# ls -l /dev/disk/by-id/wwn*
lrwxrwxrwx. 1 root root 9 May 29 23:00 /dev/disk/by-id/wwn-0x5000c50015ea71ad -> ../../sr0

So this bug has been fixed.

Comment 21 mazhang 2015-05-29 07:38:44 UTC
Also reproduce this bug on qemu-img-0.12.1.2-2.445.el6.x86_64 with rhel7 guest.

Host:
qemu-kvm-0.12.1.2-2.445.el6.x86_64
2.6.32-563.el6.x86_64

Guest:
3.10.0-229.el7.x86_64

CMD:
/usr/libexec/qemu-kvm \
-M pc \
-cpu SandyBridge \
-m 2G \
-smp 4,sockets=1,cores=2,threads=2 \
-enable-kvm \
-name rhel6.7 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-rtc base=localtime,driftfix=slew \
-nodefaults \
-monitor stdio \
-qmp tcp:0:6666,server,nowait \
-serial unix:/tmp/console0,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-vga std \
-vnc :0 \
-netdev tap,id=tap0 \
-usb -device usb-tablet,id=tblt0 \
-device virtio-net-pci,netdev=tap0,id=nic0,mac=54:52:00:B6:40:21 \
-drive file=/home/boot.iso,if=none,media=cdrom,id=drive-ide0,readonly=on,format=raw \
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,wwn=0x5000c50015ea71ad \
-drive file=/home/RHEL-Server-7.2-64-virtio.qcow2,if=none,id=drive-scsi-disk,format=qcow2,cache=none,werror=stop,rerror=stop \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,drive=drive-scsi-disk,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk,bootindex=1 \

Result:
[root@unused ~]# uname -r
3.10.0-229.el7.x86_64
[root@unused ~]# ls -l /dev/disk/by-id/wwn*
ls: cannot access /dev/disk/by-id/wwn*: No such file or directory

Comment 23 errata-xmlrpc 2015-07-22 06:07:07 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1275.html