Bug 957295
Summary: | support direct connection to an iSCSI LUN using pool/volume sources | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Paolo Bonzini <pbonzini> | ||||
Component: | libvirt | Assignee: | John Ferlan <jferlan> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 7.0 | CC: | acathrow, cwei, dallan, dyuan, jferlan, juzhang, knoel, mzhan, pbonzini, shyu, weizhan | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | libvirt-1.1.1-1.el7 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1058598 (view as bug list) | Environment: | |||||
Last Closed: | 2014-06-13 09:30:35 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: | 923843 | ||||||
Bug Blocks: | 957294, 1058598, 1059006 | ||||||
Attachments: |
|
Description
Paolo Bonzini
2013-04-26 22:04:00 UTC
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. |