V-IT, I AM GOING THROUGH IT

Vmotion moves a running VM from one host to another. (VC Client GUI, means by "Migrate...")

SVmotion moves a running VM (files belong to that VM) from one vmfs storage to another. (have to be done through CLI. No VMware supported GUI so far.)

Both should not inturrupt VM. VMs can be up and running during the process.
Note: If you can power off the VM, you can use VC Client GUI ("Migrate") to move both!

The most famous Third-Party GUI tool (a VI Client plug-in) for S-Vmotion recognized by VMWare is developled by Andrew Kutz: http://communities.vmware.com/thread/126141

The beauty of VCB is "LAN-Free", which eliminats the traditional backup window. You can back up your machine whenever you want, in theory. Also, yous ycan do image level backup which enables you to restore it in no time. With huge RDMs attached, the VM being backed up through VCB is becoming impossible (limit space on VCB Proxy) and the worst senario happened to me, the VM hung up and left LUNs unaccessible. (Big time!)

Eventually I put all my RDMs to "Independent Virtual Compatibility" mode, therefore VCB will skip those RDMs automatically and back up OS part only. Then I use regular DP agent to backup data part (RDMs), of course nightly.

Note: DP6.0 doesn't support VCB1.1, yet as I am writing this post.

I found RDM is flexiable. You can hook it up with a physical machine down to the road if in need. Somebody reported RDM could be faster than VMFS. Also, RDMs are right allocated from SAN, therefore they are easier to grow (up to 2T). For my situation, we have such quite a few big data storage (2T, 1T, 600G, ) for the file server, I am afraid it's not a good idea to make such big VMFS disks.