Hello andvm
"Is there any noticeable impact in the duration if I had to migrate the VM storage from an AF vSAN with dedup and comp to other SAN storage, compared to one without dedup and comp?"
I wouldn't think migrating from a deduped cluster would make this task longer as it is purely a read operation from the source side and whether that is deduped or not, it is going to be reading the same blocks - this and the fact that Storage vMotion is an asymmetric operation (pretty much pure read on one side and pure write on the other) means that the bottleneck is generally going to be on the destination as opposed to the source (assuming they have equal storage performance capabilities).
Now, where this might contribute to longer times is if it were going the other way from any cluster to a deduped one vs a non-deduped one - once the Cache-tier becomes sufficiently full to start destaging to Capacity-tier it will be processing dedupe operations and this will be extra overhead (compared to a non-deduped cluster) - whether this will cause the task to be slower or not pretty much depends on the performance of the devices in question and what kind of load they are already under (e.g. whether this enough extra work to be pushing these to or past their operational limits).
"Also is there any noticeable benefit in terms of migration duration if I had to shut down the VM (doing a cold migration) or would this be just measured in seconds?"
There shouldn't be a massive disparity unless the VM is busy and/or has fast-changing dataset.
"The consumed storage of the VM is just about 2TB and using FTT1. Is this consumed storage taking into consideration/including FTT1 and then deducting any savings from dedup and comp?"
If you are referring to on the VM summary page then this is including overhead from the FTT and FTM (and for all Objects e.g. vmdk, snapshot vmdk, vswp, vmem) but no, it does not account for dedupe as this is performed per Disk-Group not per VM. It makes sense to display it in this way as if you had 4 VMs with identical data, which one would you say is making the savings? (and it would just lead to confusion with people wondering why the 1st VM shows as 100GB and the other 3 as just a few GB).
"What would be the best way to measure such SvMotion in advance to measure duration ideally with same or similar sized VM (have a duration baseline)....Is a test Linux box and filled with urandom data a good approach or you suggest otherwise?"
So, this is where this gets a bit more complicated (and I am not sure it is relevant as per my first point above) - vmdk Objects vary widely in how much they dedupe and this can be constantly changing over time depending on what else is stored on that Disk-Group and what data is changing and/or moving, a VM with random data would actually be a bad example as this data is more likely to be unique and thus wouldn't dedupe well or at all. As with any workload tests, the best comparison would be to use a clone or a copy of the same data you plan on operating against (and preferably under similar load if possible and you want an accurate comparison).
Bob
