vRA 7.3 has landed

[kallischlauch]

vRealize Automation 7.3

[sbeaver]

So who is going to be the first brave soul to deploy and report back?

[willonit]

I have a very simple deployment for testing that upgraded very smoothly. Upgraded through 5480 management interface. Required one reboot of vRA appliance. Once completed, I had to validate my endpoints to accept certificates. Thats about all that I have run into so far.

[sbeaver]

Thanks for the update with your experience.  Hopefully others will follow your lead

[evil242]

It Does not look like they resolved these issues:

• AD policies can't be saved if you enter a DN with the destination ObjectName that is an object number greater than ~100 for Container Names of the same name in your Active Directory.  Eg. <OU>/Servers.
• You can't bind properties from Business Groups or Blueprints to Software Components.

[kallischlauch]

frankly I'm quite annoyed right now.

update was very smooth, in my lab all components updated one after another automatically. (Iaas all components after appliance reboot)

however my endpoint configuration in vRA is missing all vCenters. I can't deploy machines.

If I do a data collection on my cluster it succeeds (inventory)  (even though there is no endpoint in UI), but state, performance and all others fail (certificate error)

when I add a new endpoint with the correct name it presents me with the cert, i can accept and save, but now even the inventory data collection fails (certificate error)

it is like there's a misconfigued endpoint in DB that I can't update from UI or some crap like that

Like I said I can't deploy. I could possibly create a new proxy agent and configure that but then again what if I delete the original proxyt agent, probably only be more mess

contacting support ... again ...

[kallischlauch]

actually its listed in known issues (with workaround) ... lets see

After you have a successful test connection and you saved the endpoint with a valid thumbprint, the vSphere agent logs or DEM logs contain error messages about a closed connection, the inability to establish a trust relationship, or a remote certificate is invalid

[nsb24]

Issue: my endpoint configuration in vRA is missing all vCenters

It appears that your iaas upgrade didn't complete successfully. Could you check your upgrade logs for IaaS?

Also If you added the same endpoint again then now you have two endpoints for the same URL.

Upgraded endpoints guidelines: vRealize Automation 7.3 Information Center

Do you happen to have a snapshot pre-upgrade? I wonder if you can re-run the upgrade again. The fact you couldn't see the endpoints in the UI post upgrade, your upgrade didn't complete successfully and I am surprised that there was no error.

[kallischlauch]

all ok now.

it's known issue listed in the readme. It took me all morning to figure out and I am quite certain this issue will affect *anyone* with selfsigned certs.

1. follow the workaround in the 7.3 release notes. the certificates have to be imported into all 'inf' machines. (DEM, agent, inf, ....). in my case it was only the single inf server.

2. go to endpoints and make sure the certificate is then trusted

3. names in certificates have to match endpoint!!! this took me a while to figure out.

example when adding NSX endpoint:

my nsx self signed certificate had the CN: NSXMGR and was in DNS of domain_A

my VRA is in domain B, so I tried to add the endpoint by IP. Works, but data collection fails: Certificate is not trusted (RemoteCertificateNameMismatch). Subject: CN=NSXMGR

So then I tried in vRA to add the endpoint as https://NSXMGR, but that fails because VRA can't resolve it (different domain). I added entry to hosts file of VRA (/etc/hosts), then I was able to add endpoint using its shortname (same as CN) and datacollection also worked.

that took a while ...

in my case the endpoints were completely missing, but still exist in DB.

I recreated them, which works  for machine deployment, but my NSX endpoint is now confused as they are 2.

Currenty investigating with support ...

Kalli

[nsb24]

Thanks for sharing with us all. However I have one correction to make in your steps:

2. go to endpoints, create if missing and make sure the certificate is then trusted

I do not advise create if missing. The endpoints weren't supposed to be missing. Upgrade should take care of migrating old endpoints. Creating same endpoint twice could cause further issues.

[kallischlauch]

it would also be the expected behaviour alright.

originally when I had no endpoint configured (after upgrade) it would still do the data-collection for 'innventory' on my cluster, but no other (state/performance)

however when I added the certs to inf server, when I did a sync with no endpoint it wouldn't work either, but worked once I added it. Very odd.

I might check with support if there are 2 endpoint now in DB

[nsb24]

Yes it will still do data collection as the endpoint is in the system for infrastructure, it is just that it is not upgraded to be shown in the new UI. FYI, The new UI is backed by a new REST API in 7.3. (Look under Endpoint Configuration Service here). Support is the right way to pursue this further. I just want to point out create if missing part is not necessary.

[kallischlauch · Accepted solution]

thx. with support now since the old entry is still in DB. works for machine provisioning, but NSX endpoint seems confused.

UI, CloudClient and vra show all the same info, but the DB still has the old items.

so essentially I have two endpoints with the exact same name, which gives problems.

So if you upgrade to 7.3 and the endpoints are _missing_, then contact support (i guess you can reference 17464522805)

Kalli

Update, just in case someone has the same problems: (case 17464522805)

a) if endpoints are missing, then as nsb24 stated, something went wrong (even though upgrade is successful, the endpoints were not upgraded and are therefore missing). VMware can supply you (probably KB soon, reference case) with a commandline that runs the upgrade again. However if it failed before it will happen again, but you will get to see more detail on error. In my case I accidentally added an orchestrator endpoint property onto my vCenter (the required priority property). That caused it to fail. In the case we removed it from DB. In production infra I'll remove all properties from vCenter and re-add after upgrade 😄 (just in case)

b) i did create a new one, which is a problem as there are 2 with the same name (confuses NSX endpoint), support have moved all items from newly created one to the old one (MSSQL DB). Then deleted the new one, then upgraded the old one. So best you do not create new endpoints if they are missing after upgrade

c) CN name (not discussed in case). the NSX certificate was self signed and CName was hostname. I had to add the endpoint as FQDN  in vRA, as it is in a different domain. therefore the endpoint and CName don't match, which is now a problem in 7.3 (no problem in 7.2!). To get it to work you have to match it up. I do not want to change NSX Manager cert (probably breaks a lot more things), so I added a hosts entry in vra va so it can resolve the NSX manager using the same name as in cert. add endpoint accept cert and then without doing any certificate checking (don't hit the button I changed it back to FQDN). worked for me. but currently also discussing with VMware on what is the proper thing to do here ...

[rvp1001]

This question is Not Answered.(Mark as assumed answered)

I am taking the parallel upgrade path rather doing the in place upgrade method of vRealize Automation 7.3.

I just "vRealized" it much easier to failback then doing the snapshot method.

Will let everyone know if there are bad or good..

it should be fine.

Notes

vRealize Automation 7.3

What's in the Release Notes

The release notes cover the following topics:

• What's New
 
• System Requirements
• Installation
• Before You Upgrade
• Resolved Issues
• Known Issues
• Previous Known Issues

What's New

The vRealize Automation 7.3 release includes resolved issues and the following new capabilities.

Parameterized Blueprints to Enhance Reusability and Reduce Sprawl

• Introduced component profiles for defining both size and image attributes, enabling "T-shirt sizing" as a request item 
  • Component profiles provided for image and virtual machine size including CPU, memory, and storage size
• Efficiently manage blueprints by leveraging abstracted component profiles
• Increase reusability while significantly reducing blueprint sprawl
• Trigger approval policies on size or image conditions
• Import or export of component profiles using vRealize CloudClient
• Automatically substitute component profile values

[meda1983]

I successfully upgraded my homelab thats loadbalanced using NSX.   i only ran into one issue, where the replica appliance failed to upgrade.

Functionality wise everything is up and running excep that replica node.  Trying to figure out whats going on.  uploaded my log file if anyone is interested to look at it. 

[Bidondo]

Same here, upgrade went smooth and no errors; completed in about one hour.  We started with a fresh 7.2 install from last week, then upgraded.  Able to provision and see all resources after fixing the known certificate issue with the vCenters.

One annoying bug: when using "display location on blueprint", the API calls to the IaaS service are failing with an http 400.  Anyone else seeing this?  This was working in vRA 7.2.  Tried creating new blueprints and also created reservation policies, but same deal.  The Datacenterlocations.xml file is valid and intact.

Failed API call

10.75.9.116 [22/May/2017:15:44:50 +0000][6 ms] "GET /iaas-proxy-provider/api/data-center-locations?_dc=1495467884656&query=&platformTypeId=vsphere&groupId=5ef8ae51-cf41-4d55-a174-123d8d6ba107&page=1&start=0&limit=2147483647&%24orderby=value HTTP/1.1" 400 173 [tomcat-http--15]

Stack trace in catalina.out

2017-05-22 16:36:27,501 vcac: [component="cafe:iaas-proxy" priority="ERROR" thread="tomcat-http--49" tenant="vsphere.local" context="0ie0hF42" parent="" token="0ie0hF42"] com.vmware.vcac.platform.service.rest.resolver.ApplicationExceptionHandler.handleExceptionInternal:1008 - Required String parameter 'reservationPolicyName' is not present

org.springframework.web.bind.MissingServletRequestParameterException: Required String parameter 'reservationPolicyName' is not present

[nsb24]

Looks like a breaking change, you can find it here: vRealize Automation IaaS Proxy Provider Service API - VMware API Explorer - VMware {code}

Add the &reservationPolicyName= to make it work.

e.g. GET /iaas-proxy-provider/api/data-center-locations?_dc=1495467884656&query=&platformTypeId=vsphere&groupId=5ef8ae51-cf41-4d55-a174-123d8d6ba107&reservationPolicyName=

[Bidondo]

Thanks for the recommendation.  Since this call was embedded in vRA UI itself, the quick fix was to actually set reservation policies at the Reservation and Blueprint levels; it seems to be passing the proper attribute through MVC now.  Again, this was not needed before, but the API explorer is now showing as a required attribute.  The deprecation notice is a little concerning though.