5 Replies Latest reply on Jul 5, 2019 5:56 AM by agbiront

    Deploy VM from OVA/OVF Template blueprint network issues

    agbiront Novice



      I'm trying to create a new blueprint to deploy VMs from an OVA. It's a common task where I work, as some of our providers send us pre-configured OVAs for us.


      I've tried the most simple blueprint, a new VM from the "ImportOvfWorkflow" connected to an existing network. The OVF automatically loads the required Custom Properties:






      and so on...


      I have two issues with this. Firstly, the most simple solution would be to ask the values on the request. I've tried this, but it fails. It successfully configures FQDN and IP Address but it fails to set the values for Gateway, Subnet Mask, DNS Servers and Search Domains. The VM fails to power-on because these are mandatory values and afterwards the VM gets deleted.


      The other issue that I have is that manually configuring the IP address on request is not as ideal as I would want it to be. Is there a way to tell the Custom Properties to get the Network configuration from what VRA is going to set to the Network0?


      Any help is appreciated.

        • 1. Re: Deploy VM from OVA/OVF Template blueprint network issues
          _mduchaine_ Novice

          Hi Agbiront, team!


          Did you manage to solve your issue?

          From what you wrote, it looks to me like the issue is with the values you gave the custom properties - since at least some of them (fqdn, ip) got through.

          In my case, it doesn't look like the ovf custom properties get passed-on at all.

          If someone could tell me which logs to check to figure this out, would really appreciate it.


          To address the issue of the IP@, my approach was to design a little VCO action to fetch all available IPs from a given network reservation, and hook it to a drop-down.

          I've used this approach on blueprint based on template cloning, using property definitions (associate VirtualMachine.Network0.Address to a dropdown with external values / script).

          During the allocation process, if the IP is within the network reservation ranges, it get's automatically allocated.


          With the OVF deployment, it's not working

          Dropdown get's populated fine but once I submit the request, the first available IP from the network profile gets allocated, not the one I selected in the drop-down.

          VRA "knows" it must allocate an IP for the given reservation because I've added an external network to my blueprint, but it doesn't consider the OVF custom property in which I stored the IP from the dropdown, unlike what happens with Virtualmachine.Network0.Address. What would be the proper approach to resolve this issue?


          My blueprint, fairly simple:

          erog_lab is my external network, a plain distributed portgroup

          and these are the custom properties I've gotten after validating the OVF:


          I've hardcoded most of them, made them overridable and visible only because I'm debugging the thing, later I'll have most of them hidden.


          I've defined VMware.Ovf.Configuration.ip0 in the dictionary and hooked up the VCO action script getAvailableIPfromNetworkProfile



          Proceeding with a deployment, I select an IP from the range (not the first one available).

          This is the data from the request:



          But as you can see, it's allocated the first available:



          Nothing pops up in the log, or in the audit log ...



          And when checking in vCenter the vApp options that should have been filled with the data from VRA, it's empty:


          The VM came up with DHCP by the way. Not a total loss, but almost .


          Passing OVF params should be a walk in the park, I must be making a simple mistake along the way.

          I sure hope you guys can help me out here.



          • 2. Re: Deploy VM from OVA/OVF Template blueprint network issues
            agbiront Novice



            Are you running vRA 7.4? The issue I had was a bug that got fixed on patch 3. I've already migrated my install to 7.5 and my lab to 7.6, and last time I checked the issue was fixed. The problem was vRA not populating any vApp Options

            1 person found this helpful
            • 3. Re: Deploy VM from OVA/OVF Template blueprint network issues
              _mduchaine_ Novice

              Hi !

              Indeed I was running VRA 7.4, so I upgraded to 7.6.

              After overcoming an absurd situation regarding the OVF boolean property "preferIPv6", I finally got my VRLI OVA deployed - yeay!


              But, I still have the same situation with the network profile:

                   - VRLI got the IP address I specified from the dropdown

                   - internal IPAM allocated the first IP of the range



              • 4. Re: Deploy VM from OVA/OVF Template blueprint network issues
                _mduchaine_ Novice

                Hi Agbiront, team!

                In the end I fixed my problem.


                For those of you who followed the thread, I was populating a dropdown with the list of free IP addresses from a given Network Profile (VRO Action).

                By assigning this IP@ to the custom property of the OVF (VMware.Ovf.Configuration.vami.ip0.VMware_vCenter_Log_Insight in my case),

                I would get my OVF (VRLI) deployed with the right IP, but in the network profile always allocated the first available IP, regardless.


                I ended up adding "Virtualmachine.Network0.Address" to the blueprint's custom properties, and assign it the same value as the one in the OVF custom property.

                Doing so resolved the allocation discrepancy.


                hope this helps others.

                Agbiront, I think it would be good to mark this thread as closed, I believe all open points got addressed.



                2 people found this helpful
                • 5. Re: Deploy VM from OVA/OVF Template blueprint network issues
                  agbiront Novice

                  That's great! Your test also applies to my environment. It's good to know how to solve this. Thanks