Comment 10 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 is a very long way from being an iSCSI-only system - we have SMB, NFS, iSCSI, ceph, sheepdog, REST and other transfer technologies. If your view of cinde ris that it is a shim over iSCSI, I'm afraid you way wrong. There are already API rules in that don't need to apply to some drivers, but we maintain a consistent API across them all so that workloads are portable and can work on any backend, at least if you stick to the core API (which includes snapshots). The only way to implement generic support for create-from-snap-of-a-different type is to fall back to dd, which if people /really/ want to do then fine, I don't like it, the performance will suck but at least we stick to the core value of 'no vendor lock-in'. Otherwise I'm going to continue to push back hard against a supported option that breaks workload compatibility.