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.
1 person found this helpful
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
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
2 people found this helpful
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.
That's great! Your test also applies to my environment. It's good to know how to solve this. Thanks