How can I take a dynamic group and tell it to 'rediscover' entities using REST API and base it off of tags that I assigned to VMs within vCenter? I don't see a 'vmsByTag' xmlId entity anywhere.
My understanding is that you can't do this via the API. If you notice, you also don't do this via the Groups Management user interface. The xmlId values you can provide correspond with the search criteria you can specify in the user interface. Group Management is not where you set up groups by tags.
You set up annotations in a Discovery policy (Policy View > Discovery > VC Annotations). Operations Manager creates the associated groups automatically. They are contained by a parent group named VC Annotations... If you get groups via the API, the parent annotations group looks like this:
<TopologyElement creationClassName="Group" displayName="VC Annotations" name="GROUP-VC-ANN" uuid="_GBIGQMvSEeCHAdVb0k7XJQ"/>
Child groups will have display names that match the tag:value that they're tied to. For example, assume:
tag = department
value = Development
Then the resulting group will have a display name of department:Development.
There is no API method to specify tag discovery. You have to specify that via the user interface. Also, there's no way to kick of incremental discovery via the API. You have to wait for Operations Manager to perform its regular cycles of discovery, where discovery is how Operations Manager keeps track of the entities in your environment. (Note that periodic discovery is for tracking the existence and state of entities... It does not affect how often each entity analyzes its cost for resource utilization.)
I hope this is helpful!
Thank you Chris.
The issue that I ultimately have is that I have multiple ESX hosts that have VMs with enabled pass-through devices. These VMs will not be able to migrate from one host to another because of this. Thus, if VMTurbo attempts to migrate these VMs, they will not be able to and from what I have been told the system will error out, but I don't know what that looks like from a VMTurbo point of view.
The solution that we had was to create a tag on each VM labeled "HBA" (Host Bus Adapter) and to create a group within Group Management in the user interface.
I also went as far as to create a PowerCLI script that would "refresh" the tags within the environment in case another VM gets a pass-through device or if one is removed at any given time. I then set up a task to execute this script once every hour to keep the tag data fresh.
Perhaps using tags as a criteria is new with the latest version which we are running as it does appear to show up in the UI. Unfortunately, if I want to update VMTurbo with these changes, I need to physically log into VMTurbo, go to the group, and click on "Find matches" to rediscover the VMs with this tag. Then, I need to click on "Apply Member Change" to commit the update:
I may be able to create a new annotation with the key:value pairs as you suggested, but I would like to make sure that once my PowerCLI script is kicked off, it ends with an API call to VMTurbo telling it to also refresh this data to keep the list accurate. That way, if a migration were to happen, we can tell it to ignore all VMs with this tag so no errors occur.
Am I on the right track with regards to this? Are VC Annotations probed when Operations Manager performs its regular cycles of discovery? Is there an easy way to modify these cycle times? If so, would there be any significant drawback such as a high load on the VM running VMTurbo? I can assume that it varies from environment to environment, but I need to ask.
Thanks again for the assist!
Just to make sure we're on the same page, here's the setup for tag discovery -- We're discovering the Department tag (among others):
And here I've set up an action policy that disables moves for any VM in the Development department:
Note that the scope for the policy is VMs > VC Annotations > Department > Department:Development... I disabled moves for any VM tagged Department:Development. So you can see that as long as the tags are up to date, you can get the results you desire.
One point here is that Operations Manager already manages the group based on tagging -- you don't need to create a new group to do this. I'm not 100% on how often the group gets updated. I suspect there's a 10 minute polling cycle and it can't be more immediate than that. I'll ask around to see if this is correct. That would still leave a 10-minute window where a move could fail.
You can use the API to rediscover, and that would kick off a regroup. I don't know if kicking off a regroup for your environment would be a wise choice. For a large environment a regroup can take a significant amount of time... So issues of scale would be inevitable.
Another approach you might consider... Instead of tagging the VMs (or along with that activity), why not create a static group, and call the API to add new VMs to it as you discover the driving criterion? Since you already are using a process to modify the given VM, why not add it to a group at that moment? Could that be a way to go?
Thank you again Chris.
I was able to create a new attribute as a key/value pair as you suggested. I will test things out and mark this thread as successful once I confirm that it automatically changes as the environment/attributes change. Even if it is every 10 minutes between polls, that is still better than the one-hour updates that I set up within the environment.
I think that the reason for why we went with a tag is because VMware does not appear to be maintaining any long-term plans for custom attributes. For example, in vSphere Web Client I see the following message on the screen when I attempt to edit a custom attribute:
I can only assume that this is VMware's way of pushing people to use tags instead of custom attributes. Hence our reason for creating a tag.
If this works for now, then that is okay for us. Lets just hope that VMware does not completely do away with them or we may have some unexpected issues to sort out in the future.
My fingers are crossed in the meantime and let you know how this goes.
Thank you for the help.
Yes Ethan... Please let me know! I did verify with dev, and it's supposed to update on our regular polliing cycle, which should be 10 minutes.
The good news is that I was able to create a new annotation that identifies all VMs with a passthrough device. VMTurbo also automatically adapts (after about 10 minutes) if I remove the attribute from any given VM! (YES!!)
So that's the good news. The bad news is that the list maxes out at around 196 VMs. Unfortunately, we have a few more than that which should be on the list, but do not appear to be showing up.
Do you have any other ideas as to how this can be corrected? Is there a way to increase the limit of these VC Annotation groups to include all VMs that have this specific annotation?
Hi Ethan... My instinct at this point is that you should talk with Technical Support. This seems like an arbitrary limit. If you open a support case, you might learn that the limit isn't really there, or there's a workaround, or perhaps we need to make an enhancement request.
I'm glad that up to that limit the feature works as advertised.
Retrieving data ...