Bug 1130475
| Summary: | fail to specify wwn for virtual IDE CD-ROM | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Sibiao Luo <sluo> | |
| Component: | qemu-kvm | Assignee: | John Snow <jsnow> | |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 6.5 | CC: | 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: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1130438, 1220617 | |||
| Bug Blocks: | 1131316, 1150820 | |||
|
Description
Sibiao Luo
2014-08-15 10:30:28 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 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. Fix included in qemu-kvm-0.12.1.2-2.449.el6 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 Try with RHEL7 guest. There is a bug open, IIRC, about CD-ROM WWNs in RHEL6 guests. Yes, it's bug 1130438, now ON_QA. 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 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 (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. 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>
Date: Thu Nov 4 08:55:58 2010 -0400
Use ata_id, not scsi_id, on ATAPI devices
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. (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 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 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. 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. 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 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 |