Patches describing the code changes were posted here:

https://www.redhat.com/archives/libvir-list/2013-July/msg01268.html

Changes except for one set of tests were pushed upstream: 

http://libvirt.org/git/?p=libvirt.git;a=commit;h=b6c162d3bbc7f43f7756a56b3d646c4bdaafe2dc

The design is to add a 'mode=direct' to the domain XML which then causes the domain startup disk translation code to add the 'host' information from the source pool which is then used to generate an iSCSI/URI connection to the volume when it's sent to qemu.

Hi Paolo,
I try to verify this bug with below steps, will you please help to confirm it is right?
Version:

libvirt-1.1.1-1.el7.x86_64

Steps:
0. exist an guest
1. define a iscsi pool
# virsh pool-list
Name                 State      Autostart 
-----------------------------------------
default              active     no        
iscsi                active     yes
# virsh vol-list iscsi
Name                 Path                                    
-----------------------------------------
unit:0:0:0           /dev/disk/by-path/ip-10.66.90.100:3260-iscsi-iqn.2001-05.com.equallogic:0-8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-131842-lun-0

# virsh pool-dumpxml iscsi
<pool type='iscsi'>
  <name>iscsi</name>
  <uuid>22fa5b38-07a9-42db-ae60-a5a6988af43d</uuid>
  <capacity unit='bytes'>21485322240</capacity>
  <allocation unit='bytes'>21485322240</allocation>
  <available unit='bytes'>0</available>
  <source>
    <host name='10.66.90.100' port='3260'/>
    <device path='iqn.2001-05.com.equallogic:0-8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-131842'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

2. edit guest, add below to guest.
...
<disk type='volume' device='disk'>
      <driver name='qemu'/>
      <source pool='iscsi' volume='unit:0:0:0'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
...
# virsh edit kvm-rhel6.4-x86_64-qcow2-virtio
Domain kvm-rhel6.4-x86_64-qcow2-virtio XML configuration edited.

3. start guest
# virsh start kvm-rhel6.4-x86_64-qcow2-virtio
Domain kvm-rhel6.4-x86_64-qcow2-virtio started

4. edit guest, add below to guest.
....
 <disk type='network' device='disk'>
      <driver name='qemu' type='raw'/>
      <source protocol='iscsi' name='iqn.2001-05.com.equallogic:0-8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-131842'>
        <host name='10.66.90.100' port='3260'/>
      </source>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
....
#  iscsiadm --mode discovery --type sendtargets --portal 10.66.90.100
10.66.90.100:3260,1 iqn.2001-05.com.equallogic:0-8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-131842
# virsh edit kvm-rhel6.4-x86_64-qcow2-virtio
Domain kvm-rhel6.4-x86_64-qcow2-virtio XML configuration edited.

5. start the guest
# virsh start kvm-rhel6.4-x86_64-qcow2-virtio
error: Failed to start domain kvm-rhel6.4-x86_64-qcow2-virtio
error: internal error: process exited while connecting to monitor: char device redirected to /dev/pts/1 (label charserial0)
qemu-kvm: -drive file=iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic%3A0-8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-131842,if=none,id=drive-virtio-disk0,format=raw: could not open disk image iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic%3A0-8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-131842: Operation not supported

I found a bug 923843 releated with step 5. So before BG 923843 is fixed, this bug can't be verified. Am I right?
Thank

Some notes based on recent testing I've done as well...  I would like to point out first though that steps 4 & 5 appear to be out of the scope this particular set of changes.  Rather those steps appear to me to be more related to allowing iSCSI as a network disk (git commit id '1a308ee01' and 'c820fbff9').  Although based on what I see from the error message, I wonder if the problem is related to a libiscsi bug for which I don't have a bz on, only email between Paolo and I. Furthermore I think I have to assume (although not specifically stated) that in between step 3 and 4, you destroyed the guest, right?  Because in step 4, it appears to my eyes that you are using the same iSCSI target as step 2, so rather than "adding" as you note - you are really editing the existing entry, correct?  I was not able to get that to work either, yet.  I'm not sure if there's a bz related to adding a network disk directly, but if there is that should be used to test this. It could also be that I tried to follow the pass through setup using a 'scsi' bus. Hopefully Paolo can elaborate further with respect to whether there's a bz specifically for that.  That probably could be added as a reference for this bz.

In any case, this bz should be more related to testing just the source pool usage. I have a couple of notes:
 
Step 1 (iscsi pool)

Your "<device path=" is quite a bit longer than what I have... Mine is simply:

"<device path='iqn.2013-07.localhost:iscsi.net.pool'/>

where

# virsh vol-list iscsi-net-pool
Name                 Path
-----------------------------------------
unit:0:0:1           /dev/disk/by-path/ip-192.168.1.5:3260-iscsi-iqn.2013-07.localhost:iscsi.net.pool-lun-1
unit:0:0:2           /dev/disk/by-path/ip-192.168.1.5:3260-iscsi-iqn.2013-07.localhost:iscsi.net.pool-lun-2


Step 2 (domain def)

Your "<source pool='iscsi' volume='unit:0:0:0'/>" will result in the LUN that's presented to QEMU to essentially use the "Path" as seen from the virsh vol-list. That is, it will not use the 'source/host' path from the pool. This is what's known as the 'host' mode.

If you add a "mode='direct'" to your source pool xml, then the source/host from the pool xml would be referenced and you'd get something like "iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic%3A0-8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-131842/0" as the LUN to be presented. Although that does fail as well, but according to Paolo there is a libisci bug upstream that will resolve the issue. The issue being the "%3A" rather than ":".



FWIW: Here's my 'configuration'.  I created 3 sets of targets - one to handle the 'host' pool, one to handle the 'direct' pool, and one to not use the pool.  I can get the host and direct pool working, although I needed to work around the "%3A" bug by changing it to a ":" in my unpushed source.  I have not yet figured out how to get the non pool connection to work, but that's a bit outside this.

For each pair of LUN's there is a 2G and a 10G file.  The 'disk2' in each case is used as the install/boot target.

# tail -15 /etc/tgt/targets.conf

<target iqn.2013-07.localhost:iscsi.no.pool>
backing-store /home/tgtd/iscsi/disk1
backing-store /home/tgtd/iscsi/disk2
</target>

<target iqn.2013-07.localhost:iscsi.lcl.pool>
backing-store /home/tgtd/iscsi-pool-lcl/disk1
backing-store /home/tgtd/iscsi-pool-lcl/disk2
</target>

<target iqn.2013-07.localhost:iscsi.net.pool>
backing-store /home/tgtd/iscsi-pool-net/disk1
backing-store /home/tgtd/iscsi-pool-net/disk2
</target>

# iscsiadm --mode session
tcp: [3] 192.168.1.5:3260,1 iqn.2013-07.localhost:iscsi.lcl.pool
tcp: [4] 192.168.1.5:3260,1 iqn.2013-07.localhost:iscsi.net.pool
#
# iscsiadm --mode discovery --type sendtargets --portal 192.168.1.5:3260
192.168.1.5:3260,1 iqn.2013-07.localhost:iscsi.lcl.pool
192.168.1.5:3260,1 iqn.2013-07.localhost:iscsi.net.pool
192.168.1.5:3260,1 iqn.2013-07.localhost:iscsi.no.pool
#

My pools are the same except for the <name> and <device path=> :

# cat $HOME/iscsi-lcl-pool.xml
  <pool type='iscsi'>
    <name>iscsi-lcl-pool</name>
    <source>
      <host name='192.168.1.5'/>
      <device path='iqn.2013-07.localhost:iscsi.lcl.pool'/>
    </source>
    <target>
      <path>/dev/disk/by-path</path>
    </target>
  </pool>

# cat $HOME/iscsi-net-pool.xml
  <pool type='iscsi'>
    <name>iscsi-net-pool</name>
    <source>
      <host name='192.168.1.5'/>
      <device path='iqn.2013-07.localhost:iscsi.net.pool'/>
    </source>
    <target>
      <path>/dev/disk/by-path</path>
    </target>
  </pool>

I have a 'host' guest and a 'direct' guest definition that uses the source pools as follows:

...
  <disk type='volume' device='disk'>
    <driver name='qemu' type='raw'/>
    <source pool='iscsi-lcl-pool' volume='unit:0:0:2' mode='host'/>
    <target dev='vda' bus='virtio'/>
    <alias name='virtio-disk0'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
  </disk>
  <disk type='volume' device='disk'>
    <driver name='qemu' type='raw'/>
    <source pool='iscsi-lcl-pool' volume='unit:0:0:1' mode='host'/>
    <target dev='vdb' bus='virtio'/>
    <shareable/>
    <alias name='virtio-disk1'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
  </disk>

...

  <disk type='volume' device='disk'>
    <driver name='qemu' type='raw'/>
    <source pool='iscsi-net-pool' volume='unit:0:0:2' mode='direct'/>
    <target dev='vda' bus='virtio'/>
    <alias name='virtio-disk0'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
  </disk>
  <disk type='volume' device='disk'>
    <driver name='qemu' type='raw'/>
    <source pool='iscsi-net-pool' volume='unit:0:0:1' mode='direct'/>
    <target dev='vdb' bus='virtio'/>
    <shareable/>
    <alias name='virtio-disk1'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
  </disk>

Hope this helps a bit.  I am interested in figuring out why my non pool configuration doesn't quite work.

Well I got the non pool configuration to work in my hacked environment to adjust the "%3A" to ":" using:

  <disk type='network' device='disk'>
    <driver name='qemu' type='raw'/>
    <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/2'>
      <host name='192.168.1.5' port='3260'/>
    </source>
    <target dev='vda' bus='virtio'/>
  </disk>
  <disk type='network' device='disk'>
    <driver name='qemu' type='raw'/>
    <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/1'>
      <host name='192.168.1.5' port='3260'/>
    </source>
    <target dev='vdb' bus='virtio'/>
  </disk>

NOTE: Although it doesn't read that way in the documentation, if I omit the <host> from the <source> I get a failure at startup:

# virsh start if18nopool
error: Failed to start domain if18nopool
error: internal error: iscsi accepts only one host
#

As there is code that makes sure that at least/most 1 <host> defined for iscsi.


However, the configuration which did not work for me was the scsi passthrough:

    <disk type='network' device='lun'>
      <driver name='qemu' type='raw'/>
      <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/2'>
        <host name='192.168.1.5' port='3260'/>
      </source>
      <target dev='sda' bus='scsi'/>
    </disk>

with

    <controller type='scsi' index='0' model='virtio-scsi'/>

eliciting the error:

# virsh start if18nopool
error: Failed to start domain if18nopool
error: Unable to get device ID 'iqn.2013-07.localhost:iscsi.no.pool/2': No such file or directory
#


It may be because I haven't configured something properly though. I was trying to follow the examples from the commit (c820fbff9), but it seems I've missed something.

Again this is all outside the scope of this bz, but while it was all fresh in my mind and on my screen I figured I'd add it.

(In reply to Shanzhi Yu from comment #3)
> Hi Paolo,
> I try to verify this bug with below steps, will you please help to confirm
> it is right?
> Version:
> 
> libvirt-1.1.1-1.el7.x86_64
> 
> Steps:
> 0. exist an guest
> 1. define a iscsi pool
> # virsh pool-list
> Name                 State      Autostart 
> -----------------------------------------
> default              active     no        
> iscsi                active     yes
> # virsh vol-list iscsi
> Name                 Path                                    
> -----------------------------------------
> unit:0:0:0          
> /dev/disk/by-path/ip-10.66.90.100:3260-iscsi-iqn.2001-05.com.equallogic:0-
> 8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-131842-lun-0
> 
> # virsh pool-dumpxml iscsi
> <pool type='iscsi'>
>   <name>iscsi</name>
>   <uuid>22fa5b38-07a9-42db-ae60-a5a6988af43d</uuid>
>   <capacity unit='bytes'>21485322240</capacity>
>   <allocation unit='bytes'>21485322240</allocation>
>   <available unit='bytes'>0</available>
>   <source>
>     <host name='10.66.90.100' port='3260'/>
>     <device
> path='iqn.2001-05.com.equallogic:0-8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-
> 131842'/>
>   </source>
>   <target>
>     <path>/dev/disk/by-path</path>
>     <permissions>
>       <mode>0755</mode>
>       <owner>-1</owner>
>       <group>-1</group>
>     </permissions>
>   </target>
> </pool>
> 
> 2. edit guest, add below to guest.
> ...
> <disk type='volume' device='disk'>
>       <driver name='qemu'/>
>       <source pool='iscsi' volume='unit:0:0:0'/>
>       <target dev='vda' bus='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x06'
> function='0x0'/>
>     </disk>
> ...
> # virsh edit kvm-rhel6.4-x86_64-qcow2-virtio
> Domain kvm-rhel6.4-x86_64-qcow2-virtio XML configuration edited.
> 
> 3. start guest
> # virsh start kvm-rhel6.4-x86_64-qcow2-virtio
> Domain kvm-rhel6.4-x86_64-qcow2-virtio started
> 
> 4. edit guest, add below to guest.
> ....
>  <disk type='network' device='disk'>
>       <driver name='qemu' type='raw'/>
>       <source protocol='iscsi'
> name='iqn.2001-05.com.equallogic:0-8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-
> 131842'>
>         <host name='10.66.90.100' port='3260'/>
>       </source>
>       <target dev='vda' bus='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x06'
> function='0x0'/>
>     </disk>
> ....

using the disk source like this is not related with this bug, this bug is to allow one to use the disk source with pool and volume name. there are 2 modes,
one is "host", one is "direct", defaults to "host". 

"host" mode means qemu command line will use the lun's path showed up on host.
check the qemu command line at [1], you will see it, it looks like "/dev/disk/by-path/...".

"direct" mode means qemu command line will use libiscsi uri. something like
file=iscsi://example.org:6000/iqn.1992-01.com.example/1.

check commit log for more details. 

commit 1b4eaa61950780b66aeba1c85b8a9e4f910f49bc
Author: John Ferlan <jferlan>
Date:   Thu Jul 18 07:00:19 2013 -0400

    qemu: Translate the iscsi pool/volume disk source
    
    The difference with already supported pool types (dir, fs, block)
    is: there are two modes for iscsi pool (or network pools in future),
    one can specify it either to use the volume target path (the path
    showed up on host) with mode='host', or to use the remote URI qemu
    supports (e.g. file=iscsi://example.org:6000/iqn.1992-01.com.example/1)
    with mode='direct'.
    
    For 'host' mode, it copies the volume target path into disk->src. For
    'direct' mode, the corresponding info in the *one* pool source host def
    is copied to disk->hosts[0].


> #  iscsiadm --mode discovery --type sendtargets --portal 10.66.90.100
> 10.66.90.100:3260,1
> iqn.2001-05.com.equallogic:0-8a0906-12a1f7d03-0daf49b25a84ee02-s3-kyla-131842
> # virsh edit kvm-rhel6.4-x86_64-qcow2-virtio
> Domain kvm-rhel6.4-x86_64-qcow2-virtio XML configuration edited.
> 
> 5. start the guest
> # virsh start kvm-rhel6.4-x86_64-qcow2-virtio
> error: Failed to start domain kvm-rhel6.4-x86_64-qcow2-virtio
> error: internal error: process exited while connecting to monitor: char
> device redirected to /dev/pts/1 (label charserial0)
> qemu-kvm: -drive
> file=iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic%3A0-8a0906-
> 12a1f7d03-0daf49b25a84ee02-s3-kyla-131842,if=none,id=drive-virtio-disk0,
> format=raw: could not open disk image
> iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic%3A0-8a0906-12a1f7d03-
> 0daf49b25a84ee02-s3-kyla-131842: Operation not supported
> 

i'm not sure if this problem also exists when you use "direct" mode. but you shouldn't test it like this.

(In reply to John Ferlan from comment #5)
> Well I got the non pool configuration to work in my hacked environment to
> adjust the "%3A" to ":" using:
> 
>   <disk type='network' device='disk'>
>     <driver name='qemu' type='raw'/>
>     <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/2'>
>       <host name='192.168.1.5' port='3260'/>
>     </source>
>     <target dev='vda' bus='virtio'/>
>   </disk>
>   <disk type='network' device='disk'>
>     <driver name='qemu' type='raw'/>
>     <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/1'>
>       <host name='192.168.1.5' port='3260'/>
>     </source>
>     <target dev='vdb' bus='virtio'/>
>   </disk>
> 
> NOTE: Although it doesn't read that way in the documentation, if I omit the
> <host> from the <source> I get a failure at startup:
> 
> # virsh start if18nopool
> error: Failed to start domain if18nopool
> error: internal error: iscsi accepts only one host
> #
> 
> As there is code that makes sure that at least/most 1 <host> defined for
> iscsi.
> 
> 
> However, the configuration which did not work for me was the scsi
> passthrough:
> 
>     <disk type='network' device='lun'>
>       <driver name='qemu' type='raw'/>
>       <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/2'>
>         <host name='192.168.1.5' port='3260'/>
>       </source>
>       <target dev='sda' bus='scsi'/>
>     </disk>
> 
> with
> 
>     <controller type='scsi' index='0' model='virtio-scsi'/>
> 
> eliciting the error:
> 
> # virsh start if18nopool
> error: Failed to start domain if18nopool
> error: Unable to get device ID 'iqn.2013-07.localhost:iscsi.no.pool/2': No
> such file or directory
> #
> 

hm, the error is from virGetUnprivSGIOSysfsPath, which is try to get the device 
ID "major:monior" of the device to set "unpriv_sgio", it's a bug, we should skip
the unpriv_sgio setting for "network" type disk.

(In reply to Osier Yang from comment #7)
> (In reply to John Ferlan from comment #5)
> > Well I got the non pool configuration to work in my hacked environment to
> > adjust the "%3A" to ":" using:
> > 
> >   <disk type='network' device='disk'>
> >     <driver name='qemu' type='raw'/>
> >     <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/2'>
> >       <host name='192.168.1.5' port='3260'/>
> >     </source>
> >     <target dev='vda' bus='virtio'/>
> >   </disk>
> >   <disk type='network' device='disk'>
> >     <driver name='qemu' type='raw'/>
> >     <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/1'>
> >       <host name='192.168.1.5' port='3260'/>
> >     </source>
> >     <target dev='vdb' bus='virtio'/>
> >   </disk>
> > 
> > NOTE: Although it doesn't read that way in the documentation, if I omit the
> > <host> from the <source> I get a failure at startup:
> > 
> > # virsh start if18nopool
> > error: Failed to start domain if18nopool
> > error: internal error: iscsi accepts only one host
> > #
> > 
> > As there is code that makes sure that at least/most 1 <host> defined for
> > iscsi.
> > 
> > 
> > However, the configuration which did not work for me was the scsi
> > passthrough:
> > 
> >     <disk type='network' device='lun'>
> >       <driver name='qemu' type='raw'/>
> >       <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/2'>
> >         <host name='192.168.1.5' port='3260'/>
> >       </source>
> >       <target dev='sda' bus='scsi'/>
> >     </disk>
> > 
> > with
> > 
> >     <controller type='scsi' index='0' model='virtio-scsi'/>
> > 
> > eliciting the error:
> > 
> > # virsh start if18nopool
> > error: Failed to start domain if18nopool
> > error: Unable to get device ID 'iqn.2013-07.localhost:iscsi.no.pool/2': No
> > such file or directory
> > #
> > 
> 
> hm, the error is from virGetUnprivSGIOSysfsPath, which is try to get the
> device 
> ID "major:monior" of the device to set "unpriv_sgio", it's a bug, we should
> skip
> the unpriv_sgio setting for "network" type disk.

diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 18e926c..86ed9ed 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1065,7 +1065,7 @@ qemuSetUnprivSGIO(virDomainDeviceDefPtr dev)
         disk = dev->data.disk;
 
         if (disk->device != VIR_DOMAIN_DISK_DEVICE_LUN ||
-            virDomainDiskSourceIsBlockType(disk))
+            !virDomainDiskSourceIsBlockType(disk))
             return 0;
 
         path = disk->src;

(In reply to Osier Yang from comment #8)
> (In reply to Osier Yang from comment #7)
> > (In reply to John Ferlan from comment #5)
> > > Well I got the non pool configuration to work in my hacked environment to
> > > adjust the "%3A" to ":" using:
> > > 
> > >   <disk type='network' device='disk'>
> > >     <driver name='qemu' type='raw'/>
> > >     <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/2'>
> > >       <host name='192.168.1.5' port='3260'/>
> > >     </source>
> > >     <target dev='vda' bus='virtio'/>
> > >   </disk>
> > >   <disk type='network' device='disk'>
> > >     <driver name='qemu' type='raw'/>
> > >     <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/1'>
> > >       <host name='192.168.1.5' port='3260'/>
> > >     </source>
> > >     <target dev='vdb' bus='virtio'/>
> > >   </disk>
> > > 
> > > NOTE: Although it doesn't read that way in the documentation, if I omit the
> > > <host> from the <source> I get a failure at startup:
> > > 
> > > # virsh start if18nopool
> > > error: Failed to start domain if18nopool
> > > error: internal error: iscsi accepts only one host
> > > #
> > > 
> > > As there is code that makes sure that at least/most 1 <host> defined for
> > > iscsi.
> > > 
> > > 
> > > However, the configuration which did not work for me was the scsi
> > > passthrough:
> > > 
> > >     <disk type='network' device='lun'>
> > >       <driver name='qemu' type='raw'/>
> > >       <source protocol='iscsi' name='iqn.2013-07.localhost:iscsi.no.pool/2'>
> > >         <host name='192.168.1.5' port='3260'/>
> > >       </source>
> > >       <target dev='sda' bus='scsi'/>
> > >     </disk>
> > > 
> > > with
> > > 
> > >     <controller type='scsi' index='0' model='virtio-scsi'/>
> > > 
> > > eliciting the error:
> > > 
> > > # virsh start if18nopool
> > > error: Failed to start domain if18nopool
> > > error: Unable to get device ID 'iqn.2013-07.localhost:iscsi.no.pool/2': No
> > > such file or directory
> > > #
> > > 
> > 
> > hm, the error is from virGetUnprivSGIOSysfsPath, which is try to get the
> > device 
> > ID "major:monior" of the device to set "unpriv_sgio", it's a bug, we should
> > skip
> > the unpriv_sgio setting for "network" type disk.
> 
> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> index 18e926c..86ed9ed 100644
> --- a/src/qemu/qemu_conf.c
> +++ b/src/qemu/qemu_conf.c
> @@ -1065,7 +1065,7 @@ qemuSetUnprivSGIO(virDomainDeviceDefPtr dev)
>          disk = dev->data.disk;
>  
>          if (disk->device != VIR_DOMAIN_DISK_DEVICE_LUN ||
> -            virDomainDiskSourceIsBlockType(disk))
> +            !virDomainDiskSourceIsBlockType(disk))
>              return 0;
>  
>          path = disk->src;

this typo fix should be able to fix the problem.

w.r.t  Comment 9

I can confirm that fixes the issue I saw. 

Looking back through the original changes - the bug/issue was there too, so I just blindly copied - <sigh>.

We'll need to make sure a fix for this gets into RHEL7

I'm in the process of doing some other nit changes (mostly documentation and
error messages so far) and I'll be sure this gets included, although I suppose
we'll probably need a bz

(In reply to John Ferlan from comment #4)
> Some notes based on recent testing I've done as well...  I would like to
> point out first though that steps 4 & 5 appear to be out of the scope this
> particular set of changes.  Rather those steps appear to me to be more
> related to allowing iSCSI as a network disk (git commit id '1a308ee01' and
> 'c820fbff9').  Although based on what I see from the error message, I wonder
> if the problem is related to a libiscsi bug for which I don't have a bz on,
> only email between Paolo and I. Furthermore I think I have to assume
> (although not specifically stated) that in between step 3 and 4, you
> destroyed the guest, right?  Because in step 4, it appears to my eyes that
> you are using the same iSCSI target as step 2, so rather than "adding" as
> you note - you are really editing the existing entry, correct?  I was not
> able to get that to work either, yet.  I'm not sure if there's a bz related
> to adding a network disk directly, but if there is that should be used to
> test this. It could also be that I tried to follow the pass through setup
> using a 'scsi' bus. Hopefully Paolo can elaborate further with respect to
> whether there's a bz specifically for that.  That probably could be added as
> a reference for this bz.
> 
> In any case, this bz should be more related to testing just the source pool
> usage. I have a couple of notes:
>  
> Step 1 (iscsi pool)
> 
> Your "<device path=" is quite a bit longer than what I have... Mine is
> simply:
> 
> "<device path='iqn.2013-07.localhost:iscsi.net.pool'/>
> 
yeah, ^ ^
> where
> 
> # virsh vol-list iscsi-net-pool
> Name                 Path
> -----------------------------------------
> unit:0:0:1          
> /dev/disk/by-path/ip-192.168.1.5:3260-iscsi-iqn.2013-07.localhost:iscsi.net.
> pool-lun-1
> unit:0:0:2          
> /dev/disk/by-path/ip-192.168.1.5:3260-iscsi-iqn.2013-07.localhost:iscsi.net.
> pool-lun-2
> 
> 
> Step 2 (domain def)
> 
> Your "<source pool='iscsi' volume='unit:0:0:0'/>" will result in the LUN
> that's presented to QEMU to essentially use the "Path" as seen from the
> virsh vol-list. That is, it will not use the 'source/host' path from the
> pool. This is what's known as the 'host' mode.
> 
> If you add a "mode='direct'" to your source pool xml, then the source/host
> from the pool xml would be referenced and you'd get something like
> "iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic%3A0-8a0906-12a1f7d03-
> 0daf49b25a84ee02-s3-kyla-131842/0" as the LUN to be presented. Although that
> does fail as well, but according to Paolo there is a libisci bug upstream
> that will resolve the issue. The issue being the "%3A" rather than ":".
> 
yes, but when I start the guest with qemu command, also met same error:
# /usr/libexec/qemu-kvm -name kvm-rhel6.4-x86_64-qcow2-virtio -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1  -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/kvm-rhel6.4-x86_64-qcow2-virtio.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive file=iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313/0,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0 -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

qemu-kvm: -drive file=iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313/0,if=none,id=drive-virtio-disk0: could not open disk image iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313/0: Operation not supported

Easily seen, I change "%3a" to ":" but still met same error.
> 
> 
> FWIW: Here's my 'configuration'.  I created 3 sets of targets - one to
> handle the 'host' pool, one to handle the 'direct' pool, and one to not use
> the pool.  I can get the host and direct pool working, although I needed to
> work around the "%3A" bug by changing it to a ":" in my unpushed source.  I
> have not yet figured out how to get the non pool connection to work, but
> that's a bit outside this.
> 
> For each pair of LUN's there is a 2G and a 10G file.  The 'disk2' in each
> case is used as the install/boot target.
> 
> # tail -15 /etc/tgt/targets.conf
> 
> <target iqn.2013-07.localhost:iscsi.no.pool>
> backing-store /home/tgtd/iscsi/disk1
> backing-store /home/tgtd/iscsi/disk2
> </target>
> 
> <target iqn.2013-07.localhost:iscsi.lcl.pool>
> backing-store /home/tgtd/iscsi-pool-lcl/disk1
> backing-store /home/tgtd/iscsi-pool-lcl/disk2
> </target>
> 
> <target iqn.2013-07.localhost:iscsi.net.pool>
> backing-store /home/tgtd/iscsi-pool-net/disk1
> backing-store /home/tgtd/iscsi-pool-net/disk2
> </target>
> 
> # iscsiadm --mode session
> tcp: [3] 192.168.1.5:3260,1 iqn.2013-07.localhost:iscsi.lcl.pool
> tcp: [4] 192.168.1.5:3260,1 iqn.2013-07.localhost:iscsi.net.pool
> #
> # iscsiadm --mode discovery --type sendtargets --portal 192.168.1.5:3260
> 192.168.1.5:3260,1 iqn.2013-07.localhost:iscsi.lcl.pool
> 192.168.1.5:3260,1 iqn.2013-07.localhost:iscsi.net.pool
> 192.168.1.5:3260,1 iqn.2013-07.localhost:iscsi.no.pool
> #
> 
> My pools are the same except for the <name> and <device path=> :
> 
> # cat $HOME/iscsi-lcl-pool.xml
>   <pool type='iscsi'>
>     <name>iscsi-lcl-pool</name>
>     <source>
>       <host name='192.168.1.5'/>
>       <device path='iqn.2013-07.localhost:iscsi.lcl.pool'/>
>     </source>
>     <target>
>       <path>/dev/disk/by-path</path>
>     </target>
>   </pool>
> 
> # cat $HOME/iscsi-net-pool.xml
>   <pool type='iscsi'>
>     <name>iscsi-net-pool</name>
>     <source>
>       <host name='192.168.1.5'/>
>       <device path='iqn.2013-07.localhost:iscsi.net.pool'/>
>     </source>
>     <target>
>       <path>/dev/disk/by-path</path>
>     </target>
>   </pool>
> 
> I have a 'host' guest and a 'direct' guest definition that uses the source
> pools as follows:
> 
> ...
>   <disk type='volume' device='disk'>
>     <driver name='qemu' type='raw'/>
>     <source pool='iscsi-lcl-pool' volume='unit:0:0:2' mode='host'/>
>     <target dev='vda' bus='virtio'/>
>     <alias name='virtio-disk0'/>
>     <address type='pci' domain='0x0000' bus='0x00' slot='0x04'
> function='0x0'/>
>   </disk>
>   <disk type='volume' device='disk'>
>     <driver name='qemu' type='raw'/>
>     <source pool='iscsi-lcl-pool' volume='unit:0:0:1' mode='host'/>
>     <target dev='vdb' bus='virtio'/>
>     <shareable/>
>     <alias name='virtio-disk1'/>
>     <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
> function='0x0'/>
>   </disk>
> 
> ...
> 
>   <disk type='volume' device='disk'>
>     <driver name='qemu' type='raw'/>
>     <source pool='iscsi-net-pool' volume='unit:0:0:2' mode='direct'/>
>     <target dev='vda' bus='virtio'/>
>     <alias name='virtio-disk0'/>
>     <address type='pci' domain='0x0000' bus='0x00' slot='0x04'
> function='0x0'/>
>   </disk>
>   <disk type='volume' device='disk'>
>     <driver name='qemu' type='raw'/>
>     <source pool='iscsi-net-pool' volume='unit:0:0:1' mode='direct'/>
>     <target dev='vdb' bus='virtio'/>
>     <shareable/>
>     <alias name='virtio-disk1'/>
>     <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
> function='0x0'/>
>   </disk>
> 
> Hope this helps a bit.  I am interested in figuring out why my non pool
> configuration doesn't quite work.

John, thanks a lot. Your info helps me lots.

Thanks Osier's help. I think below steps can cover this bug.

Version-Release number of selected component (if applicable):
qemu-kvm-1.5.2-2.el7.x86_64
libvirt-1.1.1-2.el7.x86_64

Steps:
1. define an iscsi pool
# virsh pool-dumpxml iscsi
<pool type='iscsi'>
  <name>iscsi</name>
  <uuid>37218096-5307-4e8f-af91-c22c45420563</uuid>
  <capacity unit='bytes'>32212254720</capacity>
  <allocation unit='bytes'>32212254720</allocation>
  <available unit='bytes'>0</available>
  <source>
    <host name='10.66.90.100' port='3260'/>
    <device path='iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>
#virsh vol-list iscsi
Name                 Path
-----------------------------------------
unit:0:0:0           /dev/disk/by-path/ip-10.66.90.100:3260-iscsi-iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313-lun-0

2. define an guest with disk configurations as below:
...
<disk type='volume' device='disk'>
      <driver name='qemu'/>
      <source pool='iscsi' volume='unit:0:0:0' mode='host'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
...
3. start guest
# virsh start kvm-rhel6.4-x86_64-qcow2-virtio
Domain kvm-rhel6.4-x86_64-qcow2-virtio started

4. edit guest, change "<source pool='iscsi' volume='unit:0:0:0' mode='host'/>" to "<source pool='iscsi' volume='unit:0:0:0' mode='direct'/>"

# virsh dumpxml kvm-rhel6.4-x86_64-qcow2-virtio
...
<disk type='volume' device='disk'>
      <driver name='qemu'/>
      <source pool='iscsi' volume='unit:0:0:0' mode='direct'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
...

5. start guest
# virsh start kvm-rhel6.4-x86_64-qcow2-virtio
error: Failed to start domain kvm-rhel6.4-x86_64-qcow2-virtio
error: internal error: process exited while connecting to monitor: char device redirected to /dev/pts/4 (label charserial0)
qemu-kvm: -drive file=iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic%3A0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313/0,if=none,id=drive-virtio-disk0: could not open disk image iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic%3A0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313/0: Operation not supported

6. try start guest with qemu command
/usr/libexec/qemu-kvm -name kvm-rhel6.4-x86_64-qcow2-virtio -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid b7a492ca-ea4a-4e8b-9526-ed1e9f0e9c37 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/kvm-rhel6.4-x86_64-qcow2-virtio.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive file=iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313/0,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0
qemu-kvm: -drive file=iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313/0,if=none,id=drive-virtio-disk0: could not open disk image iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313/0: Operation not supported

Does it mean there is a libvirt bug and a qemu-kvm bug?

Please include:

- the version of the libiscsi package

- the output of ldd /usr/libexec/qemu-kvm.

Thanks!

# rpm -q libiscsi
libiscsi-1.7.0-6.el7.x86_64
# ldd /usr/libexec/qemu-kvm 
	linux-vdso.so.1 =>  (0x00007fff8dd81000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f12d0401000)
	libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f12d01ff000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f12cfed2000)
	libiscsi.so.1 => /usr/lib64/iscsi/libiscsi.so.1 (0x00007f12cfcb7000)
	libssl3.so => /lib64/libssl3.so (0x00007f12cfa7b000)
	libsmime3.so => /lib64/libsmime3.so (0x00007f12cf84d000)
	libnss3.so => /lib64/libnss3.so (0x00007f12cf511000)
	libnssutil3.so => /lib64/libnssutil3.so (0x00007f12cf2e5000)
	libplds4.so => /lib64/libplds4.so (0x00007f12cf0e0000)
	libplc4.so => /lib64/libplc4.so (0x00007f12ceedb000)
	libnspr4.so => /lib64/libnspr4.so (0x00007f12cec9e000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f12cea81000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f12ce87d000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f12ce67a000)
	libgfapi.so.0 => /lib64/libgfapi.so.0 (0x00007f12ce466000)
	libgfrpc.so.0 => /lib64/libgfrpc.so.0 (0x00007f12ce251000)
	libgfxdr.so.0 => /lib64/libgfxdr.so.0 (0x00007f12ce03b000)
	libasound.so.2 => /lib64/libasound.so.2 (0x00007f12cdd54000)
	libpulse.so.0 => /lib64/libpulse.so.0 (0x00007f12cdb0a000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f12cd905000)
	libpng15.so.15 => /lib64/libpng15.so.15 (0x00007f12cd6da000)
	libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f12cd4bd000)
	libgnutls.so.28 => /lib64/libgnutls.so.28 (0x00007f12cd1b1000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f12ccf9a000)
	libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007f12ccd7e000)
	libaio.so.1 => /lib64/libaio.so.1 (0x00007f12ccb7c000)
	libspice-server.so.1 => /lib64/libspice-server.so.1 (0x00007f12cc85c000)
	libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007f12cc649000)
	libusbredirparser.so.1 => /lib64/libusbredirparser.so.1 (0x00007f12cc441000)
	libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f12cc198000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f12cbe96000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f12cbad6000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003794a00000)
	libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00007f12cb85c000)
	libglusterfs.so.0 => /lib64/libglusterfs.so.0 (0x00007f12cb5dc000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f12cb1fc000)
	libjson.so.0 => /lib64/libjson.so.0 (0x00007f12caffa000)
	libpulsecommon-3.0.so => /usr/lib64/pulseaudio/libpulsecommon-3.0.so (0x00007f12cad91000)
	libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f12cab8f000)
	libX11.so.6 => /lib64/libX11.so.6 (0x00007f12ca854000)
	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f12ca635000)
	libICE.so.6 => /lib64/libICE.so.6 (0x00007f12ca419000)
	libSM.so.6 => /lib64/libSM.so.6 (0x00007f12ca211000)
	libXtst.so.6 => /lib64/libXtst.so.6 (0x00007f12ca00a000)
	libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f12c9dff000)
	libsndfile.so.1 => /lib64/libsndfile.so.1 (0x00007f12c9ba0000)
	libasyncns.so.0 => /lib64/libasyncns.so.0 (0x00007f12c9999000)
	libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f12c9753000)
	libcap.so.2 => /lib64/libcap.so.2 (0x00007f12c954e000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f12c9333000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f12c90fc000)
	libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f12c8edb000)
	libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007f12c8cc6000)
	libnettle.so.4 => /lib64/libnettle.so.4 (0x00007f12c8a9b000)
	libhogweed.so.2 => /lib64/libhogweed.so.2 (0x00007f12c8888000)
	libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f12c8611000)
	libcelt051.so.0 => /lib64/libcelt051.so.0 (0x00007f12c8402000)
	libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007f12c81ae000)
	libssl.so.10 => /lib64/libssl.so.10 (0x00007f12c7f42000)
	libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f12c7d3d000)
	libjson-c.so.2 => /lib64/libjson-c.so.2 (0x00007f12c7b31000)
	libXau.so.6 => /lib64/libXau.so.6 (0x00007f12c792d000)
	libXext.so.6 => /lib64/libXext.so.6 (0x00007f12c771a000)
	libXi.so.6 => /lib64/libXi.so.6 (0x00007f12c750a000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f12c72f1000)
	libgsm.so.1 => /lib64/libgsm.so.1 (0x00007f12c70e4000)
	libFLAC.so.8 => /lib64/libFLAC.so.8 (0x00007f12c6ea0000)
	libvorbisenc.so.2 => /lib64/libvorbisenc.so.2 (0x00007f12c69d1000)
	libvorbis.so.0 => /lib64/libvorbis.so.0 (0x00007f12c67a2000)
	libogg.so.0 => /lib64/libogg.so.0 (0x00007f12c659b000)
	libattr.so.1 => /lib64/libattr.so.1 (0x00007f12c6396000)
	libfreebl3.so => /lib64/libfreebl3.so (0x00007f12c6129000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f12c5ee0000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f12c5c02000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f12c59fe000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f12c57c9000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f12c55b2000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f12c53a4000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f12c51a0000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f12c4f7c000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f12c4d18000)

I understand the cut-n-paste into the bz can make things look odd; however, what concerns me is what appears to be an extra hidden/unseen character in your output between the 3260 and the /iqn - that is perhaps a \n character.

What kind of results do you get from:

iscsi-ls -s iscsi://10.66.90.100:3260 -i iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313

or

iscsiadm --mode node --portal 10.66.90.100:3260 --target iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313


The "%3A" issue is a libiscsi problem.

I believe when you roll your own qemu command, you'll need to use the name that is show in the output of the "virsh vol-list iscsi" command rather than the one with the LUN attached as "/0" - that is instead of "/0" use "-lun-0".  I think that'll work.

(In reply to John Ferlan from comment #15)
> I understand the cut-n-paste into the bz can make things look odd; however,
> what concerns me is what appears to be an extra hidden/unseen character in
> your output between the 3260 and the /iqn - that is perhaps a \n character.
> 
> What kind of results do you get from:
> 
> iscsi-ls -s iscsi://10.66.90.100:3260 -i
> iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-
> 150313
> 
> or
> 
> iscsiadm --mode node --portal 10.66.90.100:3260 --target
> iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-
> 150313
> 
Result is as the attachment.
> 
> The "%3A" issue is a libiscsi problem.
> 
So this bug can't be verified until libiscsi problem is fixed. Should I file a libiscsi bug according this error?

> I believe when you roll your own qemu command, you'll need to use the name
> that is show in the output of the "virsh vol-list iscsi" command rather than
> the one with the LUN attached as "/0" - that is instead of "/0" use
> "-lun-0".  I think that'll work.

Try as you said, still met same error:

# virsh vol-list iscsi 
Name                 Path                                    
-----------------------------------------
unit:0:0:0           /dev/disk/by-path/ip-10.66.90.100:3260-iscsi-iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313-lun-0

 /usr/libexec/qemu-kvm -name kvm-rhel6.4-x86_64-qcow2-virtio -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid b7a492ca-ea4a-4e8b-9526-ed1e9f0e9c37 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/kvm-rhel6.4-x86_64-qcow2-virtio.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive file=iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313-lun-0,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0

qemu-kvm: -drive file=iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313-lun-0,if=none,id=drive-virtio-disk0: could not open disk image iscsi://10.66.90.100:3260/iqn.2001-05.com.equallogic:0-8a0906-9951f7d03-34cf49b25f04f94b-libvirt-2-150313-lun-0: Operation not supported

Created attachment 784308 [details]
result of two iscsi command

I'm beginning to wonder if your path is too long.  Any chance you can try a shorter name? I'm out of ideas and until the '%3A' issue is resolved I'm not sure what else to put out there.

I'm going to be away for a week, so further work from my end (libvirt) will have to wait until I get back.

The iscsi driver needs to be whitelisted.  Cloning this bug in a second.

FWIW, using /0 is the right thing to do in qemu-kvm too.

Verified with packages:
libvirt-1.1.1-10.el7.x86_64
qemu-kvm-1.5.3-10.el7.x86_64

Test steps:
1. create a domain with xml below:
    <disk type='network' device='lun'>
      <driver name='qemu' type='raw'/>
      <source protocol='iscsi' name='iqn.2013-10.com.example:iscsi/1'>
        <host name='hostname' port='3260'/>
      </source>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

# virsh create r7-qcow2.xml
Domain r7-qcow2 created from r7-qcow2.xml

# ps -ef|grep qemu-kvm| grep iscsi
qemu      7033     1  3 16:41 ?        00:00:17 /usr/libexec/qemu-kvm -name r7-qcow2 -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 1024
.......
-drive file=iscsi://10.66.7.108:3260/iqn.2013-10.com.example%3Aiscsi/1,if=none,id=drive-scsi0-0-0-0,format=raw
......

2. login to the guest can mount/read/write the iscsi disk

so verify this bug.

The steps in comment 22 do not match the steps in comment 12, moving back to ON_QA.

In fact the %3A still shows up in your -drive output.  That indicates to me that the call libvirt makes to xmlSaveUri()

The %3A is fine, it was a bug in libiscsi.

sorry for my mistake. Verify with below steps:

Version-Release number of selected component (if applicable):

qemu-kvm-1.5.2-2.el7.x86_64
libvirt-1.1.1-2.el7.x86_64

Steps:

1. define an iscsi pool

virsh pool-dumpxml iscsi-pool
<pool type='iscsi'>
  <name>iscsi-pool</name>
  <uuid>5e4d5446-18df-4133-8eee-f29ebd7c8c45</uuid>
  <capacity unit='bytes'>1967128576</capacity>
  <allocation unit='bytes'>1967128576</allocation>
  <available unit='bytes'>0</available>
  <source>
    <host name='10.66.7.108'/>
    <device path='iqn.2013-10.com.example:iscsi'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>
virsh vol-list iscsi-pool
Name                 Path                                    
-----------------------------------------
unit:0:0:1           /dev/disk/by-path/ip-10.66.7.108:3260-iscsi-iqn.2013-10.com.example:iscsi-lun-1

2. define an guest with disk configurations as below

...
<disk type='volume' device='disk'>
      <driver name='qemu'/>
      <source pool='iscsi' volume='unit:0:0:1' mode='host'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>

3. start guest and check qemu command line

# virsh start rhel6
Domain rhel6 started

check qemu command line:
..
file=/dev/disk/by-path/ip-10.66.7.108:3260-iscsi-iqn.2013-10.com.example:iscsi-lun-1,if=none,id=drive-virtio-disk0
..

4. destroy and edit guest, change "<source pool='iscsi' volume='unit:0:0:0' mode='host'/>" to "<source pool='iscsi' volume='unit:0:0:1' mode='direct'/>"

# virsh dumpxml rhel6
...
<disk type='volume' device='disk'>
      <driver name='qemu'/>
      <source pool='iscsi' volume='unit:0:0:1' mode='direct'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
...

5. start guest

# virsh start guest
Domain rhel6 started

Check qemu command line:
..
file=iscsi://10.66.7.108:3260/iqn.2013-10.com.example%3Aiscsi/1,if=none,id=drive-virtio-disk0
..

so verify this bug.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.