VMware Cloud Community
Katherines01
Contributor
Contributor
Jump to solution

Refreshing VM CPU/Memory values in GUI as part of ASD action

I have a custom vRO worfklow publsihed as an ASD resource action that allows the user to resize their provisioned VM based on a set of preconfigured sizes, which the user can select from as part of the ASD request form. This is to replace the built in reconfigure option so that users can't select random sizes for their VMs, all catalog items are configured with predefined sizes as well.

The end result is that whatever the user selects corresponds to a set of CPU and RAM values e.g. Small = 2vCPU 2GB RAM, and these values are then used to change the vCPU and RAM values on the underlying vCenter VM, before the vCAC VM entity properties for CPU.Count and Memory.Size are updated using the line System.getModule ("com.vmware.library.vcac").addUpdatePropertyFromVirtualMachineEntity(host,virtualMachineEntity,"VirtualMachine.CPU.Count",cpuCount,propertyIsHidden,propertyIsRuntime,propertyIsEncrypted,doNotUpdate); for example for the CPU.

This works fine, the VM is reconfigured in vCenter and the CPU.Count and Memory.Size values are updated on the VM in vRA, but when you look at the VM under Items it's CPU and RAM boxes still display the old values. These are updated to reflect the new values when the inventory jobs in vRA next run but at this could be up to an hour later in my system.

I was wondering if there is a way to update these GUI items as part of my workflow, I can think of three possiblities:

  1. Add a force data collection workflow at the end (would be ok while I'm working in a small environment, but don't think this would scale to larger environments)
  2. Rework my workflow so that it uses the inbuilt reconfigure option to resize the VM based on the users selected value (this would probably work but I would have to redesign most of my worflow and test again)
  3. I've missed a property or attribute somewhere which controls the values displayed in the gui and these just need to be included in the workflow

Is anyone else providing a custom action to do something which affects the values displayed in the GUI , if so how do you currently do the update part or does anyone have alternative options which might require less effort to implement?

This is on vRA 6.2.1 with external vRO appliance running 6.0.1, screenshots showing the situation...

vRA GUI.JPGvRA VM properties.JPG

Reply
0 Kudos
1 Solution

Accepted Solutions
SeanKohler
Expert
Expert
Jump to solution

>>>> Add a force data collection workflow at the end (would be ok while I'm working in a small environment, but don't think this would scale to larger environments)

Right or wrong.... This is what we are doing at the end of our CPU, Mem, and Storage increase workflows.  We haven't run into a problem yet.  It will be proportionally relative to the size of your environment in some ways... but in reality it would be more relative to the quantity of change requests.  (less likely in properly sized requests)

>>>>>Rework my workflow so that it uses the inbuilt reconfigure option to resize the VM based on the users selected value (this would probably work but I would have to redesign most of my worflow and test again)

I don't like this idea.... though it is the method I am using to Change Owner.  (user ID lookup, gather request and machine binding values, run Request a Resource Action workflow) You can give the vRO/vRA plugin service account permission to Reconfigure across your environment. (I don't remember our initial blueprint configurations in particular... but currently in our environment Reconfigure doesn't allow me to change CPU/MEM/Storage.)

>>>>> I've missed a property or attribute somewhere which controls the values displayed in the gui and these just need to be included in the workflow

Well if you find it... I really hope you share.  :smileylaugh:

View solution in original post

Reply
0 Kudos
12 Replies
SeanKohler
Expert
Expert
Jump to solution

>>>> Add a force data collection workflow at the end (would be ok while I'm working in a small environment, but don't think this would scale to larger environments)

Right or wrong.... This is what we are doing at the end of our CPU, Mem, and Storage increase workflows.  We haven't run into a problem yet.  It will be proportionally relative to the size of your environment in some ways... but in reality it would be more relative to the quantity of change requests.  (less likely in properly sized requests)

>>>>>Rework my workflow so that it uses the inbuilt reconfigure option to resize the VM based on the users selected value (this would probably work but I would have to redesign most of my worflow and test again)

I don't like this idea.... though it is the method I am using to Change Owner.  (user ID lookup, gather request and machine binding values, run Request a Resource Action workflow) You can give the vRO/vRA plugin service account permission to Reconfigure across your environment. (I don't remember our initial blueprint configurations in particular... but currently in our environment Reconfigure doesn't allow me to change CPU/MEM/Storage.)

>>>>> I've missed a property or attribute somewhere which controls the values displayed in the gui and these just need to be included in the workflow

Well if you find it... I really hope you share.  :smileylaugh:

Reply
0 Kudos
SeanKohler
Expert
Expert
Jump to solution

Had a thought.  Changed Memory on a machine within VC. (so out of band)

Verified the wrong 'current' memory value in vRA.

Submitted a Reconfigure in vRA without changing any options.

And....

It didn't do anything, Smiley Happy

So don't try that.

Reply
0 Kudos
Katherines01
Contributor
Contributor
Jump to solution

Thanks Sean, good to get confirmation that I'm not the only one who can't find a property to force the gui to update, I can stop looking for that. Also good to know forcing a data collection hasn't caused any issues for your environment, and I suppose you are right it's less about the size of the environment and more about how often the users will run the resizing action. If we educate them correctly to start with they should choose the correct size the majority of times and then won't need to make frequent use of the action.

I'll head down the force data collection route for now and hope that future versions remove the need to do this, thanks for your help.

Reply
0 Kudos
bdamian
Expert
Expert
Jump to solution

I know that this thread is marked as "answered", but I think the solution is not the best.

Run a data collection is out off the question. It is unreasonable.


What you are seeing in the "Properties" tab are Custom Properties. If you can run the "System.getModule ("com.vmware.library.vcac").addUpdatePropertyFromVirtualMachineEntity" module, then you can also update the custom properties manually.


D.

---
Damián Bacalov
vExpert 2017-2023 (7 years)
https://www.linkedin.com/in/damianbacalov/
https://tecnologiaimasd.blogspot.com/
twitter @bdamian
Reply
0 Kudos
SeanKohler
Expert
Expert
Jump to solution

Sooo...  I agree that a data collection is unreasonable.

What we are talking about is the ACTUAL values in the IaaS tab... not the custom properties.

We have been updating custom properties using that mechanism for some time now...

customProperty.jpg

And it does INDEED update custom properties.  (no I don't have 5 CPU... just showing that it can be written to anything... which is then fixed on data collection)

customProperty2.jpg

But it does nothing for the actual machine information.  We have only been able to change this through data collection.

(Though I admit we have quit looking for other ways as I can run the Force Data Collection workflow 20 times back to back and it doesn't impact anything.  It is a lot less concerning than one might think.)

customProperty3.jpg

We can consider this less than ideal, but until another way is illuminated, I don't know that we have a choice.  Do you have another way that actually does work?

Edit:

customProperty4.jpg

Reply
0 Kudos
bdamian
Expert
Expert
Jump to solution

The "Force Data Collection" workflow just starts the process and finish his execution. But the Data collection process can take several minutes and it will process all the Compute Resources you have defined in vRA.

I you have a large platform or you have more than one Compute Resource, this will impact in the performance. Remember that "inventory" data collection is set to run once a day.

D.

---
Damián Bacalov
vExpert 2017-2023 (7 years)
https://www.linkedin.com/in/damianbacalov/
https://tecnologiaimasd.blogspot.com/
twitter @bdamian
Reply
0 Kudos
SeanKohler
Expert
Expert
Jump to solution

>>>The "Force Data Collection" workflow just starts the process and finish his execution.

Yes. Sorry, this is understood. The point is that the data collection trigger can run over and over without impact.  If you have multiple change events through the day, it could indeed cause a running data collection all day long.

>>>>I you have a large platform or you have more than one Compute Resource, this will impact in the performance.

We have not seen this impact you speak of... or our servers are scaled properly... or we have not hit that critical threshold where performance is an issue.

>>> Remember that "inventory" data collection is set to run once a day.

Both the OP and us have this set to hourly and not daily.

Remember that we are trying to get appropriate reporting back to our end users of a requested and implemented CPU/MEM/Storage change. Telling our users to wait a day to see their reflected changes is also not ideal.

So in your case(s), you would err on the side of data collection being a performance risk and accept a poor user experience on the presentation end.  We have not *experienced* this performance risk and have a good user experience for changing these values, though I admit that the performance implication IS (and has been for a year+) at the forefront of our concerns, and we will address a performance impact when/if it happens -OR- if there is REAL capability shared that will update the values for a single VM without the need for a full data collection.

Please, remember you are arguing from a position that has no supportable/elucidated solution present.

Share a working solution to update those values, and we would gladly use that solution.  (as would the original poster, I presume)

Reply
0 Kudos
pizzle85
Expert
Expert
Jump to solution

Just a point of reference. We went with the first option initially and saw issues. We are a hosting provider where we see tens of machines created in a day and have about 4000 VMs in our vCenters. It did not scale. We eventually settled on a SLE where we set the compute resource inventory to scan every hour. Everyone has been happy with that.

Reply
0 Kudos
SeanKohler
Expert
Expert
Jump to solution

Makes sense.

Reply
0 Kudos
burtond
Contributor
Contributor
Jump to solution

I see this thread is a bit cold, but I want to ask if anyone has any update on refreshing VM data without a full compute resource inventory?  The option to scan on demand (when changes are made) or even every hour are both out of the question for us due to our cluster sizes.  Full inventories take 45-60 min each with 500-800 VMs per cluster and ~10 clusters per vCenter.  Now we could set things to scan every 2 hours, but this is still far less than ideal.

Any updates would be great.

Reply
0 Kudos
GrantOrchardVMw
Commander
Commander
Jump to solution

Nothing new, but there is some work occurring to improve data collection.

Grant

Grant http://grantorchard.com
Reply
0 Kudos
pedjono
Enthusiast
Enthusiast
Jump to solution

HI GrantOrchardVMware​  I know this is an old question, but I am hitting the same situation and wondering if the "work occurring" you mentioned has happened?

This question has been asked again here... Single Resource Inventory Update (Data Collection)  but no real option...

Thanks

Reply
0 Kudos