How to throttle Storage vMotion bandwith?

[xray1978]

I am migrating one large VM (2TB+) from older storage (CX4) to new storage (VNX 5200). When I try to SvMotion it,users notice dramatic performance drop on VM. I suspect that is because new storage is much faster and CX4 is struggling to keep up.

Is there a way to throttle back Storage vMotion? Note that both SANs are Fibre Channel.

[brunofernandez1]

Do you have performance impacts on storage on or network?

because SVMotion uses also network/TCP to move the vm to another datastore.

so if the inteface of your VM is on the same vswitch like your vmotion port, you will probabelly have network impacts...

[brunofernandez1]

btw. you can also use a a dvswitch to throttle vMotion traffic:

Configure and Administer vSphere Network I/O Control

for thsi you need a enterprise + license...

[depping · Accepted solution]

You could leverage Storage IO Control to limit provide throttle the VMs which create the perf problem, SvMotion is billed to the VM it is moving so that would work in this scenario.

Storage IO Control and Storage vMotion? - Yellow Bricks

[knuter]

Old thread, but it appears that Storage vMotion is no longer being billed to the VM in ESXi 6.5 build 7526125? I have limits set on the VMDKs, but during Storage vMotion those are not adhered. In older versions of ESXi I remember it worked.
Storage IO Control does very little for me since the datastore receiving the data has an acceptable latency, but the other datastores are in pain.

[depping]

Correct, this changed indeed. I will bring this up with the developers.

[depping]

did you set the limits using SIOC by the way or on the VMDK itself?

[knuter]

Thanks for bringing it up with the developers

We set it on the VMDK itself since we want to limit MB/s. SIOC v2 with the IO filter only has IOPS setting which makes it unpredictable in regards of throughput due to changing IO size, at least that's my experience with it.

The need for throttling comes from using dedupe volumes on our storage array (3PAR). The storage array is not able to keep up and the cache runs full making the whole array crawl. I've logged a case with HPE in regards of that since I was hoping it would protect its cache better. The bottleneck there actually appears to be CPU and not disk performance.

[depping]

What may work, but I have not tested it is reverting back to the old scheduler by the way.... https://kb.vmware.com/s/article/2059192

[knuter]

Getting confused now. Some times storage vmotion respects the limit set on the VMDK, but not always. Trying to find a pattern and will update with the results.

[cyberpaul]

Hi Duncan,

personally I see this as a good change 🙂 In a public cloud we sometimes set strict IO limits to prevent noisy neighbor situations and then run into trouble with storage vMotion. One has to always check the limits before starting such operation.

What I find really annoying is that if you forget to raise the limit before svMotion starts, you simply have to wait for it to finish with your VM IO performance severely deteriorated.

Cheers, Pavel

[knuter]

I've tried different VMs in different cluster and if the VM has not done a Storage vMotion or regular vMotion in the last 24 hours the next one will be without QoS limit. If I cancel the job and restart it, then it aheres to the QoS limit on the VMDKs.

The trigger seems to be less than 24 hours, but I have not found exactly how much time it is.