Hide Forgot
Description of problem: Each of the error paths for secret fetch had a slightly different message and none noted whether the failure was due to UUID or Usage lookup failure Actual results: Make the messages more common and give more of an indication of what failed. Secret processing has 2 steps - determine what is being used to find the secret and then look up the secret data. A secret can be stored either by UUID or Usage, thus if that fails the message should be "no secret matches uuid '%s'" or "no secret matches usage value '%s'" where the UUID or Usage value is filled in Once that's determine the call to the secret driver can fail. If so, the message should indicate as much as possible, such as: "could not get the value of the secret for username %s using uuid '%s'" or "could not get the value of the secret for username %s using usage value '%s'" NOTE to QA: This will be a difficult bug to "reproduce". If an iSCSI environment is set up like described on http://libvirt.org/formatsecret.html and a domain is created with a disk secret as described in http://libvirt.org/formatdomain.html#elementsDevices. Then modify the "Usage" value in the domain xml file to be "xxxlibvirtiscsi" instead of "libvirtiscsi". When a 'virsh start' is run on the domain the error should be: # virsh start dom error: Failed to start domain dom error: Secret not found: iscsi no secret matches usage value 'xxxlibvirtiscsi' error to actually fetch the secret is a bit more difficult to set up (it's more an internal failure).
Hi, John Do you think the test steps below is enough? And is the " '�~V,�Bt��bc�'" in the error message in step4 is ignorable? Reproduce on libvirt-1.1.1-2.el7.x86_64, Try to verify with package: libvirt-1.1.1-8.el7.x86_64 Test steps: 1. set iSCSI target for CHAP authentication: default-driver iscsi <target iqn.2013-10.com.example:iscsi> backing-store /dev/sdb incominguser rhat rhatrhat </target> # service tgtd restart 2. define the secret # cat iscsi-secret.xml <secret ephemeral='no' private='yes'> <description>iSCSI secret</description> <auth type='chap' username='rhat'/> <usage type='iscsi'> <target>libvirtiscsi</target> </usage> </secret> # virsh secret-list UUID Usage ----------------------------------------------------------- e97e561f-2c9f-4274-b4d7-14626319bd42 iscsi libvirtiscsi # MYSECRET=`printf %s "mysecret" | base64` # virsh secret-set-value e97e561f-2c9f-4274-b4d7-14626319bd42 $MYSECRET Secret value set 3. start a domain with xml below: <disk type='network' device='disk'> <driver name='qemu' type='raw'/> <source protocol='iscsi' name='iqn.2013-10.com.example:iscsi/0'> <host name='hostname' port='3260'/> </source> <auth username='rhat'> <secret type='iscsi' usage='***libvirtiscsi'/> </auth> <target dev='vda' bus='virtio'/> </disk> # virsh create rh7-qcow2.xml error: Failed to create domain from rh7-qcow2.xml error: Secret not found: iscsi no secret matches usage value '***libvirtiscsi' 4. start a domain with xml below: <disk type='network' device='disk'> <driver name='qemu' type='raw'/> <source protocol='iscsi' name='iqn.2013-10.com.example:iscsi/0'> <host name='hostname' port='3260'/> </source> <auth username='rhat'> <secret type='iscsi' uuid='e97e561f-2c9f-4274-b4d7-14626319b000'/> </auth> <target dev='vda' bus='virtio'/> </disk> # virsh create rh7-qcow2.xml error: Failed to create domain from rh7-qcow2.xml error: Secret not found: iscsi no secret matches uuid '�~V,�Bt��bc�'
Ah - no that's not ignorable... it should have printed a string rather than literally the uuid value. I'll need a bug for that.
Thank John! File a bug for the uuid issue: Bug 1019023 - Print a string rather than literally the uuid value in the virsh command line error message And set this bug status to verified.
Verified with package: libvirt-1.1.1-9.el7.x86_64 Test steps: 1. set iSCSI target for CHAP authentication: default-driver iscsi <target iqn.2013-10.com.example:iscsi> backing-store /dev/sdc incominguser rhat rhatrhat </target> # service tgtd restart 2. define the secret # cat iscsi-secret.xml <secret ephemeral='no' private='yes'> <description>iSCSI secret</description> <auth type='chap' username='rhat'/> <usage type='iscsi'> <target>libvirtiscsi</target> </usage> </secret> # virsh secret-define iscsi-secret.xml Secret ff47c6db-c351-43fd-b1e0-f35d2afc9895 created # virsh secret-list UUID Usage ----------------------------------------------------------- ff47c6db-c351-43fd-b1e0-f35d2afc9895 iscsi libvirtiscsi 3. start a domain with xml below: <disk type='network' device='disk'> <driver name='qemu' type='raw'/> <source protocol='iscsi' name='iqn.2013-10.com.example:iscsi/0'> <host name='hostname' port='3260'/> </source> <auth username='rhat'> <secret type='iscsi' uuid='e97e561f-2c9f-4274-b4d7-14626319b000'/> </auth> <target dev='vda' bus='virtio'/> </disk> # virsh create rh7-qcow2.xml error: Failed to create domain from rh7-qcow2.xml error: Secret not found: iscsi no secret matches uuid 'e97e561f-2c9f-4274-b4d7-14626319b000' 4. start a domain with correct uuid in xml: # virsh create rh7-qcow2.xml error: Failed to create domain from rh7-qcow2.xml error: internal error: could not get value of the secret for username 'rhat' using uuid 'ff47c6db-c351-43fd-b1e0-f35d2afc9895' 5. start a domain with xml below: <disk type='network' device='disk'> <driver name='qemu' type='raw'/> <source protocol='iscsi' name='iqn.2013-10.com.example:iscsi/0'> <host name='hostname' port='3260'/> </source> <auth username='rhat'> <secret type='iscsi' usage='***libvirtiscsi'/> </auth> <target dev='vda' bus='virtio'/> </disk> # virsh create rh7-qcow2.xml error: Failed to create domain from rh7-qcow2.xml error: Secret not found: iscsi no secret matches usage value '***libvirtiscsi' 6. start a domain with correct usage in xml: # virsh create rh7-qcow2.xml error: Failed to create domain from rh7-qcow2.xml error: internal error: could not get value of the secret for username 'rhat' using usage value 'libvirtiscsi' Test results: Get expected error messages, set the bug status to verified.
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.