Is anyone currently leveraging vmturbo to automate storage vmotion? If so, what is your success and or pain points?
I did have storage migrations fully automated using vmturbo while I had my evaluation key. (currently waiting on a purchase to get my keys) I was a little nervous at first, but after testing for a week on my test cluster I felt comfortable enough to enable it across the entire environment. I did not have any issues with it but before I enabled it I did create several custom policies to lock certain guests to specific groups of datastores. (i.e. disaster recovery vm's on replicated datastores were able to migrated between other replicated datastores but they were unable to be moved to non replicated datastores.) I also had a few systems I excluded from storage migrations due to internal business policies. The policies we had for our DR systems also helped insure those protected guests stayed on the designated datastores and should someone accidentally move it off it would be migrated right back. I also created custom exclusion windows for any vm or storage moves during evening security patching and backup maintenance windows. The environment I speak of consists of over 100 hosts and 2000 virtual machines for perspective. I hope this helps....
Kevin, for as much as I have trusted vmTurbo for vmotion, I have not enabled automated storage DRS with vmTurbo. We have it on in recommend mode to continue to review what it's thinking. We do have SDRS on behind it all watching really at threshold levels. I know that the SDRS recommendations from vmTurbo will bring in much more analysis, just have not got there yet.
We haven't quite started storage automation yet do to a few pain points that are being resolved first:
1)Was getting production upgraded enough to have NetApp c-mode support so our rec's were being made properly with the backend storage in mind. This has been done.
2)Is an older architecture that puts vm swap in a separate volume than the real VM data. This was originally done so that this junk data wasn't deduplicated or replicated in the event we did start swapping but now makes some things complicated for us. We can't easily make policy rules to not place VM's on that volume or to place VM's on that volume because the VM's live on 2 volumes now and it's circular logic. Second we don't exactly want to put real VM's on a volume intended for junk and that doesn't get deduplicated. Our decision was to reconfigure vm's to store swap data back with the VM itself and ultimately clear these off and remove them, create proper no-local storage policy and to enable storage move automation but we're not quite there yet.
I would really like to hear updated experiences here.
We see issues with enabling this on nfs mounts that are not NetApp (TrueNas serving as an nfs or isci 'head' for fiberchannel attached storage servicing servers that do not have fiber channel interfaces and they cannot be added).
We have it turned on fully automated on datastores that are all fiberchannel including host attachment, and it works fine.
As we complete our NetApp testing we will see whether this works as we are replacing the TrueNAS appliances with NetApp for this use-case (development and UAT environments) and will report as to how that works out.
In the meantime, something that we don't fully understand is how you tell whether your policy settings (using custom groups as the other poster mentions) are in effect or WHICH ones are in effect.
For example, if we have storage vmotion marked "manual" in the "PM's by Cluster" grouping....but we have a custom group that finds all datastores that have "corp" and "fc" and "vm" in the name and a certain datacenter prefix in the name...and we turn storage vmotion to "automated" for that group...and there is overlap with machines in "PM's by cluster"...which one "wins"?
our custom grouping regex...credit to Richard S. at our shop not to me...
Where "NY7" is a datacenter callsign used as a prefix for the datastores....
this lets us create INCLUSIONARY rules rather than EXCLUSIONARY rules....since it's much easier to just rename all your datastores in vcenter to match your regex than all the other datastores you DON'T want to move.
In response to your question about which policy settings are in effect, there are a couple of different ways in order to determine that.
First and foremost, you raise a very good point about having some overlap with groups where an entity may be set to "Manual" in one and "Automated" in another, as this is a very common occurrence and it is good to know VMTurbo's behavior in this situation. Whenever this happens, by default we will fall back to the most 'conservative' option, i.e. the option that is less likely to cause a problem. In a situation where a VM is set to both "Manual" and "Automated" in different group settings, we will default that VM to "Manual" because that is the 'safest' option for the software to commit to.
There is a way to actually see what constraint or option a VM is currently responsive to in the UI, which can help you to determine if a constraint isn't properly defined or if a VM is in a group where it shouldn't be.
If you drill down into the Policy tab, and select the drop down on the left on Action, you will get a list of the types of entities we define in the environment.
From there, select the entity you want to look at the Policy constraints for, for the sake of the example we will choose VM. Once you select VM, the middle panel will show you options to drill down to wherever the given VM you want to look at is located in the environment.
Once you find where the VM is, select the VM itself in that middle panel; the options to change the settings on the far right will disappear and instead it will show a list of attributes with what that VM is recognizing, as well as where that attribute is pulled from.
As you can see in my example, all of the settings for this VM happen to be pulled down from the Global settings, but if there were any changes, it would be reflected in the "Defined In" category.
One last thing to note regarding the precedence that VMTurbo will take is regarding "Global" vs. "Group" level setting. "Group" level settings will always take precedence over global settings; this is done to allow you to define specific settings at a granular level. When no "Group" setting is changed, the default will always be "Global", which can be changed by selecting the top level of the Action dropdown in the Policy tab, i.e. clicking the word "Action", and then making changes by entity type after selecting the type in the box in middle of the screen.
When "Group" level settings conflict, we use the behavior I described earlier, where we default to the most conservative setting. It is important to note that all settings NOT made at the "Global" level are considered "Group" level. If you have any other questions or need further clarification I would be happy to provide it!
Yes, we have enabled and works.
Retrieving data ...