Bug 2217204

iscsi:// alone is not a valid path, it requires a valid path to an iscsi device (like host_device requires a valid path to an existing host block device).

The error message might be a bit confusing, though. While the 'iscsi' driver doesn't implement image creation, it does support 'qemu-img create' from the user's perspective.

Anyway, Hanna, it's your code, so you get to decide whether you want to change anything or not.

Thanks Kevin's explanation. I will set lower priority for the bug then.

And yes, the error message is a bit confusing, because as I tried with other protocal, like rbd, it will not prompt the protocal is not supported.

# qemu-img create -f raw rbd://xxx 1G
Formatting 'rbd://xxx', fmt=raw size=1073741824
qemu-img: rbd://xxx: error opening pool : No such file or directory

Note that a difference with rbd is that rbd can actually create new block devices, iscsi can only use existing devices.

But of course, the error message is still confusing.

(In reply to Kevin Wolf from comment #3)
> Note that a difference with rbd is that rbd can actually create new block
> devices, iscsi can only use existing devices.
> 
> But of course, the error message is still confusing.

Ah, get it. Thanks for the clarification.

I’m not sure how the error message can be improved.  As far as I understand, it is completely true that our iscsi driver does not support creating a new image, so it only allows using an existing image for “creation”.  The error message reflects this: New images cannot be created, and no existing image can be found under the given URL.

Should the error message simply not say that new images cannot be created?  I would find that confusing, too, when I try to create a new image (e.g. `qemu-img create nbd://localhost/new_image 64M`) and the error message only tells me that no such existing image can be opened, when clearly, I’m trying to create a new one.

Should it be more verbose?  E.g. "Protocol driver '$DRIVER' does not support creating new images, so an existing image must be selected as the target; however, opening the given target as an existing image failed: $REASON"?

(In reply to Hanna Czenczek from comment #5)
> I’m not sure how the error message can be improved.  As far as I understand,
> it is completely true that our iscsi driver does not support creating a new
> image, so it only allows using an existing image for “creation”.  The error
> message reflects this: New images cannot be created, and no existing image
> can be found under the given URL.
> 
> Should the error message simply not say that new images cannot be created? 
> I would find that confusing, too, when I try to create a new image (e.g.
> `qemu-img create nbd://localhost/new_image 64M`) and the error message only
> tells me that no such existing image can be opened, when clearly, I’m trying
> to create a new one.
> 
> Should it be more verbose?  E.g. "Protocol driver '$DRIVER' does not support
> creating new images, so an existing image must be selected as the target;
> however, opening the given target as an existing image failed: $REASON"?

This would be clear enough for me. 

And "Protocol driver '$DRIVER' does not support new image creation, so an existing image must be specified as the target;
however, opening the given target failed: $REASON"?" would be also good for me.

Thanks.

(In reply to Hanna Czenczek from comment #5)
> Should it be more verbose?  E.g. "Protocol driver '$DRIVER' does not support
> creating new images, so an existing image must be selected as the target;
> however, opening the given target as an existing image failed: $REASON"?

Yes, I think this would be much clearer. The problem with the current message is that the command is 'qemu-img create', so "creating" is likely to be understood as "'qemu-img create' can't work for this protocol". With your change, it's clear that this is not what is meant.

Closing this BZ: I’m not planning to (explicitly) fix this for 8.x.  To have a BZ for 9.4, we’d need to clone this one, which doesn’t make much sense now with the transition to Jira.

I’ve set the linked Jira issue’s “Fix Version/s” to 9.4.0, and I’ll continue to track progress there (https://issues.redhat.com/browse/RHELPLAN-160669).