RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1477880 - can't use default LUN of iscsi protocol used in network type virtual disk when don't specify the LUN
Summary: can't use default LUN of iscsi protocol used in network type virtual disk whe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: John Ferlan
QA Contact: Meina Li
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-03 06:53 UTC by Meina Li
Modified: 2018-04-10 10:54 UTC (History)
5 users (show)

Fixed In Version: libvirt-3.8.0-1.el7
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2018-04-10 10:52:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0704 0 None None None 2018-04-10 10:54:52 UTC

Description Meina Li 2017-08-03 06:53:34 UTC 
Description of problem:
can't use default LUN of iscsi protocol used in network type virtual disk when don't specify the LUN, which don't match our documentation that indicate "The above page indicate some points:For "iscsi" (since 1.0.4), the name attribute may include a logical unit number, separated from the target's name by a slash (e.g.,iqn.2013-07.com.example:iscsi-pool/1). If not specified, the default LUN is zero" in http://libvirt.org/formatdomain.html#elementsDisks.

Version-Release number of selected component (if applicable):
libvirt-3.2.0-14.virtcov.el7_4.2.x86_64
kernel-3.10.0-693.el7.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.3.x86_64

How reproducible:
100%

Steps to Reproduce:
1. On the iscsi-initiator machine, define and start a guest.

2.Attach a iscsi network disk with xml below:
#more iscsi.xml
<disk type='network' device='disk'>
<driver name="qemu" type="raw"/>
<source protocol="iscsi" name="iqn.2013-10.com.example:iscsi/0">
<host name="10.66.4.164" port="3260"/>
</source>
<target dev="vdb" bus="virtio"/>
</disk>
# virsh attach-device r7-qcow2 iscsi.xml
Device attached successfully
# virsh detach-device r7-qcow2 iscsi.xml
Device detached successfull

3.Modify iscsi.xml and ttach a iscsi network disk with xml below:
#more iscsi.xml
<disk type='network' device='disk'>
<driver name="qemu" type="raw"/>
<source protocol="iscsi" name="iqn.2013-10.com.example:iscsi">
<host name="10.66.4.164" port="3260"/>
</source>
<target dev="vdb" bus="virtio"/>
</disk>
# virsh attach-device r7-qcow2 iscsi.xml
error: Failed to attach device from iscsi.xml
error: internal error: unable to execute QEMU command '__com.redhat_drive_add': Device 'drive-virtio-disk1' could not be initialized

Actual results:
step3:
# virsh attach-device r7-qcow2 iscsi.xml
error: Failed to attach device from iscsi.xml
error: internal error: unable to execute QEMU command '__com.redhat_drive_add': Device 'drive-virtio-disk1' could not be initialized

Expected results:
step3:
# virsh attach-device r7-qcow2 iscsi.xml
Device attached successfully

Additional info:
http://libvirt.org/formatdomain.html#elementsDisks: For "iscsi" (since 1.0.4), the name attribute may include a logical unit number, separated from the target's name by a slash (e.g.,iqn.2013-07.com.example:iscsi-pool/1). If not specified, the default LUN is zero
Comment 2 yisun 2017-08-04 03:25:38 UTC 
not related to npiv, remove it from white board key word
Comment 3 John Ferlan 2017-09-06 16:09:39 UTC 
Strange this was never checked before - sometimes the power of the documentation does make believers.  In any case, posted the following patch upstream to resolve:

https://www.redhat.com/archives/libvir-list/2017-September/msg00122.html
Comment 4 John Ferlan 2017-09-11 23:28:05 UTC 
First patch had negative review, so v2 was generated:

https://www.redhat.com/archives/libvir-list/2017-September/msg00248.html

Primary difference is the XML is adjusted during post parse processing rather than during command creation. This results in a change to the output XML as well.

Since QEMU didn't really support a non-supplied value, this should be fine.
Comment 5 John Ferlan 2017-09-12 14:50:36 UTC 
Patch has been pushed:

commit f64f03b5b1e6f3ecd6c6d79316c3efedc00c2167
Author: John Ferlan <jferlan>
Date:   Mon Sep 11 19:18:21 2017 -0400

    qemu: Provide default LUN=0 for iSCSI if not provided
    
...
    
    If the "/#" is missing from the provided iSCSI path, then we need
    to provide the default LUN of /0; otherwise, QEMU will fail to parse
    the URL causing a failure to either create the guest or hotplug
    attach the storage.
    
    During post parse, for any iSCSI disk or hostdev, scan the source
    path looking for the presence of '/', if found, then we can assume
    the LUN is provided.  If not found, alter the input XML to add the
    "/0".  This will cause the generated XML to have the generated
    value when the domain config is saved after post parse.

$ git describe f64f03b5b1e6f3ecd6c6d79316c3efedc00c2167
v3.7.0-52-gf64f03b5b
$
Comment 7 Meina Li 2017-10-20 10:33:09 UTC 
Test env components:
kernel-3.10.0-734.el7.x86_64
libvirt-3.8.0-1.el7.x86_64
qemu-kvm-rhev-2.10.0-2.el7.x86_64

Steps to verify:
Scenario 1:
1. iSCSI network disk XML(network-disk.xml):
 <disk type='network' device='disk'>
      <driver name='qemu' type='raw'/>
      <source protocol='iscsi' name='iqn.2003-01.org.linux-iscsi.hostname.x8664:sn.target1'>
        <host name='10.73.224.151' port='3260'/>
      </source>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
  </disk>

2. Attach/detach the disk and check the status:
# virsh attach-device lmn network-disk.xml 
Device attached successfully

# virsh domblklist lmn
Target     Source
------------------------------------------------
vda        /var/lib/libvirt/images/lmn.qcow2
vdb        iqn.2003-01.org.linux-iscsi.hostname.x8664:sn.target1/0

# virsh detach-device lmn network-disk.xml 
Device detached successfully

Scenario 2:
1. iSCSI network lun XML(network-lun.xml):
 <disk type='network' device='lun'>
      <driver name='qemu' type='raw'/>
      <source protocol='iscsi' name='iqn.2003-01.org.linux-iscsi.hostname.x8664:sn.target1'>
        <host name='10.73.224.151' port='3260'/>
      </source>
      <target dev='sdb' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>

2. Attach/detach the disk and check the status:
# virsh attach-device lmn network-lun.xml 
Device attached successfully

# virsh domblklist lmn
Target     Source
------------------------------------------------
vda        /var/lib/libvirt/images/lmn.qcow2
sdb        iqn.2003-01.org.linux-iscsi.hostname.x8664:sn.target1/0

# virsh detach-device lmn network-lun.xml 
Device detached successfully


Scenario 3:
1. iSCSI hostdev with no scsi controller model:
1)Domain's scsi controller in XML:
<controller type='scsi' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</controller>
2)iSCSI hostdev XML(hostdev-lsi.xml)
<hostdev mode='subsystem' type='scsi' managed='yes'>
      <source protocol='iscsi' name='iqn.2003-01.org.linux-iscsi.hostname.x8664:sn.target1'>
        <host name='10.73.224.151' port='3260'/>
      </source>
      <alias name='hostdev0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='4'/>
    </hostdev>

2. Attach/ the host device and use 'fdisk -l' to check the device in guest:
# virsh attach-device lmn hostdev-lsi.xml 
Device attached successfully

# virsh detach-device lmn hostdev-lsi.xml 
Device detached successfully

Scenario 4:
1. iSCSI hostdev with scsi controller model='virtio-scsi':
1)Domain's scsi controller in XML:
<controller type='scsi' index='0' model='virtio-scsi'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</controller>
2)iSCSI hostdev XML(hostdev-virtio.xml)
<hostdev mode='subsystem' type='scsi' managed='yes'>
      <source protocol='iscsi' name='iqn.2003-01.org.linux-iscsi.hostname.x8664:sn.target1'>
        <host name='10.73.224.151' port='3260'/>
      </source>
      <alias name='hostdev0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='4'/>
    </hostdev>

2. Attach the host device and use 'fdisk -l' to check the device in guest:
# virsh attach-device lmn hostdev-virtio.xml 
Device attached successfully

# virsh detach-device lmn hostdev-virtio.xml 
Device detached successfully

The results are as expected, move this bug to be verified.
Comment 11 errata-xmlrpc 2018-04-10 10:52:40 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://access.redhat.com/errata/RHEA-2018:0704
Note You need to log in before you can comment on or make changes to this bug.