Bug 1254422
| Summary: | [RFE]Add option to specify the initiator for qemu-img to login iscsi target | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Qian Guo <qiguo> | ||||||
| Component: | qemu-kvm-rhev | Assignee: | Jeff Cody <jcody> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Ping Li <pingl> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 7.2 | CC: | chayang, coli, jcody, juzhang, knoel, michen, mrezanin, pezhang, sherold, virt-maint | ||||||
| Target Milestone: | rc | Keywords: | FutureFeature | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | qemu-kvm-rhev-2.9.0-1.el7 | Doc Type: | Enhancement | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2017-08-01 23:29:42 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: | |||||||||
| Attachments: |
|
||||||||
|
Description
Qian Guo
2015-08-18 05:30:52 UTC
Posted to upstream: http://patchwork.ozlabs.org/patch/516598/ This will be supported in QEMU 2.6 with Daniel P. Berrange's QCryptoSecret API work:
commit b189346eb1784df95ed6fed610411dbf23d19e1f
Author: Daniel P. Berrange <berrange>
Date: Thu Jan 21 14:19:21 2016 +0000
iscsi: add support for getting CHAP password via QCryptoSecret API
The iSCSI driver currently accepts the CHAP password in plain text
as a block driver property. This change adds a new "password-secret"
property that accepts the ID of a QCryptoSecret instance.
$QEMU \
-object secret,id=sec0,filename=/home/berrange/example.pw \
-drive driver=iscsi,url=iscsi://example.com/target-foo/lun1,\
user=dan,password-secret=sec0
Signed-off-by: Daniel P. Berrange <berrange>
Message-id: 1453385961-10718-4-git-send-email-berrange
Signed-off-by: Jeff Cody <jcody>
commit eb769f74205e0906bdb45eeeb332c40b50b1dcb7
Author: Daniel P. Berrange <berrange>
Date: Wed Feb 17 10:10:20 2016 +0000
qemu-img: allow specifying image as a set of options args
Currently qemu-img allows an image filename to be passed on the
command line, but unless using the JSON format, it does not have
a way to set any options except the format eg
qemu-img info https://127.0.0.1/images/centos7.iso
This adds a --image-opts arg that indicates that the positional
filename should be interpreted as a full option string, not
just a filename.
qemu-img info --image-opts driver=https,url=https://127.0.0.1/images,sslverify=off
This flag is mutually exclusive with the '-f' / '-F' flags.
Signed-off-by: Daniel P. Berrange <berrange>
Signed-off-by: Kevin Wolf <kwolf>
commit 3babeb153caab765e6a66ba1e0a12ff0c3b51a4e
Author: Daniel P. Berrange <berrange>
Date: Wed Feb 17 10:10:17 2016 +0000
qemu-img: add support for --object command line arg
Allow creation of user creatable object types with qemu-img
via a new --object command line arg. This will be used to supply
passwords and/or encryption keys to the various block driver
backends via the recently added 'secret' object type.
# printf letmein > mypasswd.txt
# qemu-img info --object secret,id=sec0,file=mypasswd.txt \
...other info args...
Reviewed-by: Eric Blake <eblake>
Signed-off-by: Daniel P. Berrange <berrange>
Signed-off-by: Kevin Wolf <kwolf>
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions The example in b189346eb1784df95ed6fed610411dbf23d19e1f commit message is inaccurate. Only -iscsi in QEMU command line options recognizes password-secret, which is unavailable in qemu-img. We need more work to add user/password/password-secret in upstream to support that. Probably a new version of my previous patch https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg03032.html that also includes password-secret can be proposed again. Sent a pull request upstream that contains patches for this feature: https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg04873.html Applied to qemu upstream master Hi jeff, Could you help to share the use method for specifying initiator-name via qemu-img, and give some suggestions for qe to verify this bz? Thanks in advance. Hi,
It probably makes sense to add testing for a custom initiator, with 3 scenarios:
1. No authentication required
2. Authentication passed solely via options
3. Authentication using qemu's 'object' option for the secret password
Here are examples for all three:
1). An iscsi target that does not need authentication:
qemu-img info --image-opts file.driver=iscsi,file.target=iqn.2017-01.com.quasiquark:for.all,file.transport=tcp,file.lun=1,file.portal=192.168.15.180
2). Using user/password authentication (in this example, user=redhat, password=test):
qemu-img info --image-opts file.driver=iscsi,file.target=iqn.2017-01.com.quasiquark:for.all,file.transport=tcp,file.lun=1,file.portal=192.168.15.180,file.user=redhat,file.password=test
3). Using the password secret object method with qemu-img to make it more secure:
A. First create the file with the password in it (note: do not include a newline at the end!):
echo -n "test" > password.txt
B. Now invoke qemu-img as above, but use the object mechanism and the password-secret option for iscsi:
qemu-img info --object secret,id=sec0,file=password.txt \
--image-opts \
file.driver=iscsi,\
file.target=iqn.2017-01.com.quasiquark:for.all,\
file.transport=tcp,\
file.lun=1,\
file.portal=192.168.15.180,\
file.user=redhat,file.password-secret=sec0
Created attachment 1272831 [details]
config with default initiator name iqn.2008-11.org.linux-kvm
Created attachment 1272832 [details]
config with self define initiator name iqn.2017-04.com.example:client
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 |