Comment 8 for bug 1289931

Let me clarify again. iSCSI to iSCSI is completely compatible. As stated above, an iSCSI protocol compatible export is completely compatible with another block to block. We are dealing with blocks of data not file systems remember. It doesn't matter the hardware backend for the export. It can be a usb stick, floppy drive, lvm, sparse image, hard drive, anything and as long as that storage hardware is compatible with iSCSI standards and drivers and able to export there is no need for type restriction. To the connecting device, they look the same and react the same. Which is why this restore to a different type has been working this way without, supposedly, the type restriction working. If you're going to have Cinder handle type restrictions, you are in fact limiting this product to a select set of hardware compatibly matrix and you're asking the Cinder community to systematically evaluate every hardware backend for compatibility.

Cinder has no place in that area, it should simply be an iSCSI handling API and kept simple. If there is any hardware backend which does not support compatible iSCSI commands and protocol, and for which I can't think off the top of my head as its likely impossible, it should be the driver implementation which either ignores that request or returns an error.

The compromise, which I agree with John Griffith above, is allowing for an option, on by default for those using only one type of backend, but able to be disabled for those that are and are aware of the compatibility between types for which they will be responsible. To just cut off this ability just seems to punish only those who do have multiple back ends, for the vast majority of the rest of the community, it will never become an issue. For those that do though, its a huge problem being restricted in this way.