I recently posted on how how vMotion works and figured it would be good to follow-up with a similar blog covering Storage vMotion (svMotion).
Many people think svMotion is new, but the ability to migrate a running VMs disk files to a new datastore (DS) was first introduced in VI 3.0 as an upgrade tool to help with VMFS upgrades. In VI 3.5 it was officially given the name Storage vMotion, but only had CLI support. GUI support was finally added in 4.0 and with 4.1 there were several performance improvements.
Under the covers svMotion is a 6-step process. Once a VM has been selected to have its disk files moved to a new DS using svMotion the following will take place:
1. The VM home directory (config, log, swap, snapshots) is copied to the destination DS
2. A “shadow” VM gets started on the destination DS using the copied files. The “shadow” VM idles waiting for the copying of the VM disk file(s) to complete
3. An initial copy of the VMs disk file(s) is made to the target DS, during the copy changes made to the source are tracked (change block tracking)
4. svMotion iteratively repeats this process of copying the changed blocks from the source DS to the destination DS
5. When the amount of outstanding changed blocks is small enough, svMotion invokes a Fast Suspend and Resume (FSR) of the VM (similar to vMotion) to transfer the running VM over to the idling shadow VM. Like regular vMotion, this transfer will normally happen so quickly that it will be completely transparent to the VM.
6. After the FSR completes the old home directory and VM disk files are deleted from the source DS.
With that let’s consider a few common questions:
Q. Do I need to backup my VM prior to using svMotion?
A. No, svMotion is as safe and reliable as it's vMotion counterpart. Where vMotion transfers memory, svMotion transfer storage. They employ the same FSR logic to transfer control of the running VM.
Q: Do we check for adequate free disk space on the destination DS before beginning Storage vMotion?
A: Yes, checks are made before we initiate the svMotion to ensure that adequate disk space is available on the destination DS. If there is not enough space, the svMotion request fails with no impact to the running VM.
Q: What happens to the VM if you run out of storage on the destination DS?
A: If an out-of-space condition is hit svMotion will clean up the destination DS and the VM will continue to run on the source.
Q: What happens if the iterative coping of the changed blocks fails (i.e the VM is very write intensive)?
A: If the VM is generating disk I/O faster than svMotion can copy, the svMotion will eventually fail leaving the VM running on the source.
Q: Does all the svMotion traffic get copied over the vMotion network?
A. No, a DataMover (DM) module built into the VMkernel, which is optimized for transferring large disk files, is used to copy the disk data. The swap files are also copied using the DM.
Q: What is the threshold when the number of outstanding changed blocks is small enough to proceed with stunning the VM and switching to the destination DS?
A: It depends on the disk copy throughput. svMotion continuously monitors the copy throughput during each copy iteration, when it detects that the time needed to copy the outstanding dirty blocks is less than the target downtime (default 5 secs), it proceeds with the switchover. Note that the 5 seconds is only the time to copy the remaining disk blocks, it does not include the FSR time.
