Bug 607988 - [NPIV] Invalid WWNs are not rejected by the kernel.
Summary: [NPIV] Invalid WWNs are not rejected by the kernel.
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt   
(Show other bugs)
Version: 6.0
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Dave Allan
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 608955
TreeView+ depends on / blocked
 
Reported: 2010-06-25 11:09 UTC by wangyimiao
Modified: 2016-04-26 13:52 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 608955 (view as bug list)
Environment:
Last Closed: 2010-06-29 02:11:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description wangyimiao 2010-06-25 11:09:59 UTC
Description of problem:
 1.Invalid WWNs are rejected by the kernel and libvirt reports the failure in the rhel5 , but accept in the rhel6. 

so I do not known what is the expected result.

Version-Release number of selected component (if applicable):
- libvirt-0.8.1-10.el6
- kernel-2.6.32-36.el6.x86_64
- qemu-img-0.12.1.2-2.80.el6.x86_64
- qemu-kvm-0.12.1.2-2.80.el6.x86_64


Steps to Reproduce:
1.
# ls /sys/class/fc_host/
host4  host5 

2.
cat badhba.xml 
<device>
  <parent>scsi_host5</parent>
  <capability type='scsi_host'>
    <capability type='fc_host'>
    <wwnn>5555666677778888</wwnn>
    <wwpn>1111222233334444</wwpn>
    </capability>
  </capability>
</device>

3.
virsh nodedev-create badhba.xml
 Node device scsi_host6 created from newhba.xml

Comment 2 RHEL Product and Program Management 2010-06-25 11:22:53 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Dave Allan 2010-06-25 15:26:44 UTC
There's something strange in the output you posted.  The command says you used badhba.xml as a source, but the response says you used newhba.xml:

virsh nodedev-create badhba.xml
 Node device scsi_host6 created from newhba.xml

Can you post the output from the nodedev-create with badhba.xml?

Comment 4 wangyimiao 2010-06-28 01:41:14 UTC
Sorry for step 3,I just want let others easy to known that XML is bad, so I change the 'newhba.xml' to the 'badhba.xml' but I lost change the XML name of the result.

So steps is that:
1.
# ls /sys/class/fc_host/
host4  host5 
2.
cat badhba.xml 
<device>
  <parent>scsi_host5</parent>
  <capability type='scsi_host'>
    <capability type='fc_host'>
    <wwnn>5555666677778888</wwnn>
    <wwpn>1111222233334444</wwpn>
    </capability>
  </capability>
</device>
3.
virsh nodedev-create badhba.xml
 Node device scsi_host6 created from badhba.xml

Comment 5 Dave Allan 2010-06-28 19:14:24 UTC
Did the HBA actually get created correctly?

Can you provide:
/sys/class/fc_host/hostX/port_name
/sys/class/fc_host/hostX/node_name

for the HBA you created, or let me know if those files don't exist.

Comment 6 wangyimiao 2010-06-29 01:50:46 UTC
Hi,'Allan',
  
 After I created the HBA,those file are exist in the hostX folder.
 
1.# cat /sys/class/fc_host/host9/port_name
0x1111222233334444


2.# cat /sys/class/fc_host/host9/node_name 
0x5555666677778888

Comment 7 Dave Allan 2010-06-29 02:11:18 UTC
Well, then the kernel thinks those WWNs are ok, and libvirt by design accepts what the kernel tells it.  I'm not sure why the kernel is now accepting those WWNs when it didn't before, but libvirt is doing the right thing.  If you think the kernel is wrong to accept those WWNs, please file a bug against the kernel.  I'm going to close this as not a bug as libvirt is behaving properly.

Comment 8 Johnny Liu 2010-07-08 02:32:02 UTC
This issue also reproduced on libvirt-0.8.1-13.el6.x86_64. 
According to comment 7, libvirt is behaving properly. 
So my comment is only for tracking this issue.


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