3 Replies Latest reply on Jul 2, 2018 1:05 AM by thomas_root

    vRA 7.3.1 - Force data collection for specifc items

    thomas_root Enthusiast



      we have around 300 blueprint in our vRA-Designer. These blueprints represent our different test environments of our software versions. All blueprints consist only of some vcenter vms and a network. The vcenter vms are frequently updated because we often change our software version on the vms (CI/CD). Therefore we have to change the vm reference of the blueprint to a new updated vm (the old reference will be deleted). This is done by an orchestrator workflow that updates the blueprint after a "Advanced force data collection"-workflow has finished which runs first. The data collection part takes approximately 10 minutes. So due to our update frequency its very likely that multiple blueprints must be updated in a 10 minute period and the long running "Advanced force data collection"-worklow runs multiple times. If this is the case the "Advanced force data collection"-workflow run time is much longer or a Dead-Lock-Situation appears. As a result the blueprint must be manually updated after the vRA-Built-In-Data-Collection completed successfully (configured to run every 15 minutes in our environment).


      I would like to ask if its maybe possible to update a specific entry of the vRA-Data-Collection (e. g. a virtual machine) and not the whole cluster? Could anybody help me with this?


      Please find the "Advanced force data collection"-workflow here: https://communities.vmware.com/docs/DOC-28063


      Kind regads



        • 1. Re: vRA 7.3.1 - Force data collection for specifc items
          Robert ¯\_ツ_/¯ Enthusiast

          Hello Thomas!


          I had a similar problem and ended up with a complete different solution and maybe this also works for you. I think its better with a generic example:


          Your software VM is "vm_v001". But instead of using "vm_v001" in the vRA Blueprint create a new VM/Template ("vm_temp") with the same settings (CPU, Memory, HDD, OS...). This new VM is just a placeholder and will be completely empty and its just used for the Blueprint to get the base settings. Mine took only a few KB on the storage - I never started it or installed an OS on it. Now add a custom property ("this.is.the.base.vm") with the Name of the real Template -> "vm_v001"


          After that you need a "Workflow Subscription"...



          ...and a vRO workflow who changes the value of the Property "__clonefrom" to the value of "this.is.the.base.vm".


          In this scenario there is no need to run the data collection. You just create your new VM ("vm_v002") and change the value of the "this.is.the.base.vm"-Property to the name of the new VM -> "vm_v002".


          Hope this helps



          Drink coffee.. Do stupid things faster with more energy...
          • 2. Re: vRA 7.3.1 - Force data collection for specifc items
            thomas_root Enthusiast

            Hi Robert!


            Thank you for the quick response  


            I think this solution could also work for my problem. We are using „Link-Clone“ as clone method but the snapshot which is used for cloning has always the same name. So it should also work for this use case.


            Unfortunately I’m on vacation this week. Therefore I can’t test it until next Monday. But I will post here as soon as possible if this works.


            Kind regards



            • 3. Re: vRA 7.3.1 - Force data collection for specifc items
              thomas_root Enthusiast

              Hi Robert!


              Thank you very much for the hint. I just changed your solution a little so that it worked in our environment. After creating a new VM version we store the vm name in a database. So if this new vm is ordered via a selfservice portal a rabbit-mq message is generated. An AMQP-Subscription triggers our vRO and the vRO than starts the blueprint deployment. Here we can manipulate directly the blueprint deployment request and set the cloneFrom property with the vm name stored in our database while the blueprint still refers to the old version. Finally the version in the blueprint is also updated every night with a vRO job.


              Kind regards