Bug 607988 - [NPIV] Invalid WWNs are not rejected by the kernel.
[NPIV] Invalid WWNs are not rejected by the kernel.
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.0
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Dave Allan
Virtualization Bugs
:
Depends On:
Blocks: 608955
  Show dependency treegraph
 
Reported: 2010-06-25 07:09 EDT by wangyimiao
Modified: 2016-04-26 09:52 EDT (History)
4 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description wangyimiao 2010-06-25 07:09:59 EDT
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 07:22:53 EDT
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 11:26:44 EDT
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-27 21:41:14 EDT
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 15:14:24 EDT
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-28 21:50:46 EDT
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-28 22:11:18 EDT
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-07 22:32:02 EDT
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.