Hi Romain,  Thanks for your message. We believed the issue only came about because one was an extent migration straight into a thin-enabled storage-volume and, the other was an extent migration into a thin-enabled storage-volume - of a previously migrated (but committed) extent migration into a thickly rebuild storage-volume.  Dell EMC so far have said that they believe that there is nothing wrong with what we have done and that the LUN size differences between each Unity system is nothing to be concerned about - however, I'm off to check the ETA list again!  Regards,  Garth
Hi All,  I'm working with a customer that has come across an issue doing local mobility of extents as part of a backed-end SAN hardware refresh. Each virtual volume is a VPLEX Local RAID-1 device that has extents on two local Unity storage arrays.  The first round of migrations went as planned without any issues - the extents were being migrated, maintaining their 'thin' status. On the second round of migrations there was an issue regarding the thin provisioning from the VPLEX point of view in that each extent that was migrated resulted in a fully allocated LUN on the Unity - I believe this was because the storage volume was not enabled for thin-rebuild therefore during the migration phase the 'new' extent became fully provisioned on the Unity back-end.  Not great, but what would be the best course of action to take next?  We have attempted to complete another 'third' migration, by taking the existing local extent and then migrating to another local 'thin-enabled' extent from the same storage array - this resulted in the operation completing without issue however there are now size discrepancies (if you look at the sizes of the LUNs on each backend system they aren't the same size) .  Even after a commit, there are still size discrepancies between LUN sizes on each Unity - is this a weird caching issue or a symptom that what we attempted to perform as a fix is not the correct approach.  Thanks, Garth
VPLEX Local - Rebuild behavior issues