Re: [Qemu-devel] [PATCH v2 for-2.6] block: convert iscsi target to a valid ID for -iscsi arg lookup

[John Ferlan <jferlan@redhat.com>]

[...]
>>
>> Figured I'd chime in since I tripped across this today...
>>
>> I think the one thing that concerns me about this '_' approach is we'd
>> be "stuck" with it. Eventually if 'initiator-name' is added to the
>> -drive command (as well as being able to parse the 'user=' and
>> 'password-secret='), then needing to add -iscsi wouldn't be required for
>> libvirt. Whether this patch would be required after -drive is modified
>> was the other question rattling around. So I figured I'd see if I can
>> get things to work without it...
>>
>> Using the v1 of this patch series did work for libvirt if I passed the
>> "id=" shown above using the '_' instead of ':'; however, taking the Pino
>> Toscano's series in mind, I can also start a domain using the
>> "initiator-name=" and "id=" parameters for '-iscsi' as follows:
>>
>> ...
>> -object
>> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-jaf/master-key.aes
>>
>> ...
>> -iscsi
>> id=iscsi-chap-netpool,initiator-name=iqn.2013-12.com.example,user=redhat,password-secret=virtio-disk1-ivKey0
>> -drive
>> file=iscsi://192.168.122.1:3260/iqn.2013-12.com.example%3Aiscsi-chap-netpool/1,format=raw,if=none,id=drive-virtio-disk1
>> -device
>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=1
>>
> 
> I don't believe that is doing what you think it is doing.
> 
> QEMU will still be using the "iqn.2013-12.com.example:iscsi-chap-netpool"
> string as an ID to lookup the corresponding -iscsi arg. It will not
> find it because your arg uses ID of "iscsi-chap-netpool". So, the code
> will now be falling backk to just using the /first/  -iscsi arg in the
> list.
> 
> IOW, if you add multiple iSCSI disks to the VM, they will all be using
> the first -iscsi arg, which is certainly not what we want
> 

Hmm.. OK, I see... Myopia was thinking get one done first, then think
about two... Anyway, assume XML such as:

    <disk type='network' device='disk'>
      <driver name='qemu' type='raw'/>
      <auth username='redhat'>
        <secret type='iscsi' usage='libvirtiscsi'/>
      </auth>
      <source protocol='iscsi'
name='iqn.2013-12.com.example:iscsi-chap-netpool/1'>
        <host name='192.168.122.1' port='3260'/>
      </source>
      <target dev='vda' bus='virtio'/>
    </disk>
    <disk type='network' device='disk'>
      <driver name='qemu' type='raw'/>
      <auth username='redhat'>
        <secret type='iscsi' usage='libvirtiscsi'/>
      </auth>
      <source protocol='iscsi'
name='iqn.2013-12.com.example:iscsi-chap-netpool/2'>
        <host name='192.168.122.1' port='3260'/>
      </source>
      <target dev='vdb' bus='virtio'/>
    </disk>

When building the source "path" for the qemu argument, libvirt uses the
complete "name" parameter for the -drive "file=" argument.  With my
recent patches, I would add the "-iscsi id=..." using the same path.

If I use the "name" parameter as is without changing it, then even with
this patch, I get the "Parameter 'id' error...".  If I modify the name
for the "id=" to change both ":" and "/" into "_", then I can start a
vm. If I only change one, then I get the "Parameter 'id' error..."

If I try to remove the "/#", then yes, I get the "Duplicate ID
'iqn.2013-12.com.example_iscsi-chap-netpool' ..." message.

If I go back to using the "initiator-name" approach, but instead of
chopping off the "/#" lun, I convert the "/" to a "_", then I can start
the vm again, thus having:

-iscsi
id=iscsi-chap-netpool_1,initiator-name=iqn.2013-12.com.example,user=redhat,password-secret=virtio-disk0-ivKey0

and

-iscsi
id=iscsi-chap-netpool_2,initiator-name=iqn.2013-12.com.example,user=redhat,password-secret=virtio-disk1-ivKey0


If the "/#" isn't provided, the libvirt documented behaviour is to use
lun0... I haven't tried that yet, but would suspect given this approach
(e.g. convert "/" to "_"), I'd still have unique names.

I haven't tried a pass with only adding one "-iscsi" per initiator and
target name.  That is, prescan the iSCSI devices (for both disk and
hostdev) adding one "id=" and seeing if both disks can use it.

Thanks -

John