Comment 2 for bug 1289931

Definitely need to fix the migration.

To clarify: Snapshots are handled efficiently by the storage (efficiently in time and space), and so when you create a snapshot, the snapshot will reside on the same backend as the volume. Similarly, when you create a new volume from the snapshot, this new volume will also be that same backend because this can generally also be done efficiently. Allowing a user to assign ANY new type to the new volume may require having the volume reside on a different backend than the original volume and the snapshot (in the case where the current backend does not have the capabilities required by the type).

So our options are:
1. Use the original type, and let the user retype if necessary
2. Allow setting a new type, but fail the create operation if the backend where the snapshot resides cannot accept the type - this would be confusing to users.
3. Package retype into this and make it transparent. I'd say this would be good to do eventually, but definitely not in Icehouse, and probably not in Juno - would want to wait until migration and retype are thoroughly tested and debugged before putting them into the create_volume path.

So in summary, the migration issue should be fixed ASAP, but the bigger "issue" is wishlist IMO.