1) it does not matter, svmotion is vSphere functionality. 2) you svmotion the whole VM,  you don't have to svmotion all VMs at once (you wouldn't want to anyway) 3) take into consideration the extra load on storage that svmotion creates, i did mine late in the evening, 2-3 VMs at once. 4) not that i know off, be conservative ...dont' bring your array down to its knees [IMAGE] 5) explain ? what kind of clusters, location of cluster nodes 6) 100% online for virtual disks, not sure about RDMs ..doubt you can do RDM online. 7) dosn't matter, VMs will not know that storage underneaths them changed. 8) it depends, how busy your array/host/fabric is, run a couple of test migration to get a baseline 9) this is what we did: We can not procure storage as fast as some organizations can so we decided that we did not want to be surprised when all of a sudden some VMs grew by 80% and all of a sudden our thin pool on VMAX is 95% full. So when we create thin devices, they are fully allocated, but on the VMware side ..all VMs are built as thin VMs. This way i shifted responsibility of watching space utilization to the VM admin [IMAGE] 10) if you have svmotion ..use it, 100% uptime.
Hi All,  The questions are
ESX server migration to VMAX using SVMotion