I received a very good question this week to which I did not have the answer, I had a feeling but that is not enough. The question was if Storage vMotion would be “throttled” by Storage IO Control. As I happened to have a couple of meetings scheduled this week with the actual engineers I asked the question and this was their answer:
Storage IO Control can throttle Storage vMotion when the latency threshold is exceeded. The reason for this being is that Storage vMotion is “billed” to the virtual machine.
This basically means that if you initiate a Storage vMotion the “process” belongs to the VM and as such if the host is throttled the Storage vMotion process might be throttled as well by the local scheduler(SFQ) depending on the amount of shares that were originally allocated to this virtual machine. Definitely something to keep in mind when doing a Storage vMotion of a large virtual machine as it could potentially lead to an increase of the amount of time it takes for the Storage vMotion to complete. Don’t get me wrong, that is not necessarily a negative thing cause at the same time it will prevent that particular Storage vMotion to consume all available bandwidth.
But what happens when you use VAAI enabled storage?
@afokkema In situations where VAAI enabled storage performs the offloaded heavy lifting, vSphere isn’t buried in the detail of the operation. It initiates the action and the storage lets vSphere know when the action has been completed. That may be a highly simplified version of the process but that is what I have gathered from EMC slideware. I would assume the storage provides progress updates along the way as vSphere tracks this progress with a % compelte bar in the vSphere Client. My assumption is that SIOC isn’t able to queue VAAI qualified actions. Perhaps Duncan or a product manager can chime in on this. I’m curious as well.
I’ve make some tests some weeks ago (but I want to repeat on a different environment to be sure on the results) and seems that VAAI “jobs” are “out of control”.
I’m also curios to see the official reply.
I haven’t asked the engineers but thinking about it my explanation would be:
SIOC throttles hosts based on the fact that a specific latency threshold is exceeded. Based on that the host itself will by using the local scheduler throttle a specific VM. However in this case the action is offloaded to the array, as such the latency will more than likely not go to that level and if it does the task cannot be throttled as it is happening on the “back-end” and not on the front end.
Hi Duncan,
Will VAAI be extended? Cause at the moment is very restricted to very few occasion. For example: cloning of a power off vm, on the same datastore… And nothing else.
Yes we are working on that. Can’t say when/what though.
By far the most useful of the VAAI functions in the first round is the block level locking as it all but eliminates the need to break up VM’s just to accommodate locking.
Thought of providing some more clarity on storage vMotion + SIOC. The explanation was going to be longer, hence decided to just blog on my website. Check it out for details: http://voiceforvirtual.com/2011/01/21/sioc-and-svmotion/
Hi Duncan,
Any word on Storage DRS? I know they said at VMworld it could be years but I can’t wait to see it.
Thanks!
Sorry, I am not allowed to talk about futures.
Hi Duncan
Now that SDRS is no longer a future, please could you update us on the impact of SIOC on SDRS-initiated Storage vMotions?
Also, is it possible to restrict the number of concurrent Storage vMotions on any given host? I believe there’s already a limit of 2 concurrent svMotions per host. Is there a way to restrict this further if there’s a concern about the load imposed on a host in a non-VAAI environment?
Thanks
Roy