Hi,
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.
Regards,
-Kyle
Are there any storage actions happening on a source side like snapshots or other which increase the amount of storage necessary on the source side? I have seen in version 4.0 problems with svmotion of a .vmdk which datastore has few percentage left of free space? Has something changed in 4.1?
Sounds like you may be referring to a 4.0 issue which was fixed in 4.0 Update 2.
See http://kb.vmware.com/kb/1014176
Are there any storage restriction such as their type and lun sizes?
Example:
migrating from RAID 1 to 1+0 types. or From SATA to FC and FC to SAS..
Also what about the storage motioin plug-in? It is easier to use it and or can this be run cli?
Hi,
Keep in mind that SvMotion works at the datastore. The only requirement is that the target and destination datastores are visible to the host. There are no restrictions as to the underlying layout of the storage device (RAID 1+0, RAID5, etc) nor the storage type FC, iSCSI, etc.
You can migrate from a RAID5 LUN to a RAID1+0 LUN. You can migrate from an FC LUN to an iSCSI LUN.
Yes, SvMotion can be run from the CLI. You can use either PowerCLI or vCLI. For vCLI reference the vSphere Command-Line Interface Installation and Scripting Guide (chapt 5, pg 59).
I suppose that no shadow VM is being used during the process when pure svMotion is applied to vdisk which is not used for storing VM configuration files – am I right? I guess that if I only svmove e.g. ‘hard disk 2′ vdisk to some other datastore while VM is running, it makes no sense to create a shadow VM. Please correct me if I’m wrong. Thanks in advance!
( I probably found an answer to my question already… It seems that my conclusion was OK – certain website states that: “A. It should be noted that the shadow virtual machine is only created in the case that the virtual machine home directory is moved. If and when it is a “disks-only Storage vMotion, the virtual machine will simply be stunned and unstunned.” )