I thought this was a great article by George Crump and since I get asked this a lot I thought I would post it .. Thanks George !
vMotion is one of the most compelling features of VMware. Its ability to transparently migrate a virtual machine (VM) from one physical host to another has countless uses, from balancing performance load to enabling system maintenance. VMware offers an equivalent of vMotion for storage systems: Storage vMotion. It allows for a virtual machine’s disk image to be transparently moved from one storage platform to another without interrupting the services that the VM is providing.
Once integrators get over the “wow” factor of Storage vMotion, it is important for them to understand how to leverage this capability in the solutions they design for their customers. Toward that end, let’s first talk about how Storage vMotion works.
Storage vMotion starts by copying the metadata about the VM contained in what is described as the VM's home directory to an alternate storage location. The metadata essentially consists of configuration, swap and log files that the VM needs. Once this copy is complete, Storage vMotion begins to replicate the VM's entire disk file to the new location. It does this using VMware's changed block tracking function to maintain data integrity as the copy occurs. Once the initial replication is complete, the changed block tracking engine is polled again to see which blocks changed during the first replication. On a second replication pass, just the blocks that have changed since the first replication started will be replicated to the new location. This step continues until both copies are in sync, at which point, the VM is suspended, pointed to the new location of its virtual disk image and then resumed. During this switch and before the VM is started again, one more check for data changes is made, and any final changes are copied over. This process helps ensure data integrity. While there are several steps involved in the process, it all goes unnoticed by the users and applications. The switchover is essentially transparent.
Storage vMotion can be used for a variety of tasks within the storage infrastructure for a virtual environment. The most common use case is as a migration tool when a new storage system is purchased. Instead of suffering downtime to migrate the VMs over to the new system, you can let Storage vMotion do the work. This enables daytime storage implementations, which reduces costs, with no downtime, which keeps users productive. It also enables storage integrators to more aggressively sell new storage systems into existing accounts without having to face one of the bigger sticking points of a new purchase: data migration.
Another use for Storage vMotion is as a performance load balancer. For example, if a particular VM needs higher levels of performance or if it can't take advantage of the device it is currently stored on, Storage vMotion will enable a shift to either faster or more cost-correct storage. A good use case might be a database application that sees a high level of transaction processing during a certain period of the day or even during a particular time of year. During these times, the VM that hosts the database can be moved to a faster storage tier, possibly a solid-state drive (SSD), and then when the peak demand passes, it can be migrated back down to more cost-effective storage, freeing up the SSD for another demanding workload. Right now this move does not happen in an automated fashion. Keeping on SSD only the virtual workloads that actively need the performance capabilities of SSD is an ideal way to get the most use out of the investment.
Migrating VMs that can't take advantage of the performance capabilities of the storage they are on to less expensive, lower-performing storage is another excellent use case for Storage vMotion. This is also a good way to minimize the impact of VM sprawl. While it may be hard to get users to admit they don't need a VM anymore, moving a virtually inactive virtual machine to slower storage can be a good compromise. If the use of the VM suddenly increases, Storage vMotion can be used to promote it back to higher-performing storage.
Finally, Storage vMotion can be used to help with high availability. For example, assume that one shared array has had a drive failure, and a rebuild is needed. Because individual drive capacities are continually increasing, it now takes double-digit hours to to rebuild a RAID group. During this time, I/O performance suffers because of the rebuild effort, and, unless the system is using RAID 6, the environment is only one drive failure away from complete data loss. With Storage vMotion, the VMs, or at least the critical ones, could be migrated to a completely separate storage system, even if that system is from another vendor. Be careful, though, not to use Storage vMotion in place of a high-availability solution. Storage vMotion will help you when you have time to react to an impending failure, but a completely unexpected failure will cause downtime and you will need other solutions to protect against that.
Storage vMotion is a dream come true for storage integrators because they are best positioned to take advantage of it. Storage integrators sell solutions from a variety of vendors. Their solutions can range from high-performance SSDs to high-value, capacity storage. The integrator can leverage Storage vMotion to help a customer cost-correct their storage infrastructure, give them freedom to use a variety of storage platforms and provide another layer of protection in the case of hard drive failure.
