[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 for-2.6] block: convert iscsi target to a val
From: |
John Ferlan |
Subject: |
Re: [Qemu-devel] [PATCH v2 for-2.6] block: convert iscsi target to a valid ID for -iscsi arg lookup |
Date: |
Thu, 14 Apr 2016 07:22:09 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
[...]
>>
>> 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