In the Kilo VMAX driver, support was added to allow the clone of multi-meta source volumes. The cloning control is handled in the emc_vmax_common-->_create_clone_v2() method. A rollback data object is not maintained in this method to allow cleanup of volumes that have been created if a subsequent operation should fail, and there is no exception handling in place here or at the caller's level. Since the loop adds each member to the base volume one at a time, there is at most 2 orphaned (not managed) volumes that need to be cleaned up: The current composite base volume and the latest target meta volume created. Please check the VMAX V3 flow as well.
Secondly, the PowerVC development team has determined that the source volume and target volume of a clone operation can reside in different pools for VMAX V2. And as discussed on prior conf calls, it is a requirement for us to allow this capability. And when the source volume is comprised of multiple metas of different sizes, the target volume does get created in the proper pool being requested per the clone volume extraSpecs. However the _create_clone_v2() has short-circuit logic at the top such that the _create_v2_replica_and_delete_clone_relationship() method is called immediately if the source is a simple volume or has metas of equal sizes, and this results in a target getting created always in the same pool as the source. This means the two cases end up with different behavior as to where the target ends up. If this can be considered a bug, we would like this fixed such that the extra specs pool is honored for every case. It's related to this defect because the rollback cleanup would then apply to those cases as well. Or if you need a separate bug opened, please let me know. Or if this is new function/bug that needs to wait until Liberty, let me know if we need to do anything to put the request in place for that release. Thanks.
Fix proposed to branch: master
Review: https:/