7.4
Table Of Contents
- Upgrading from vRealize Automation 6.2.5 to 7.4
- Contents
- Upgrading vRealize Automation 6.2.5 to 7.4
- Prerequisites for Upgrading vRealize Automation
- Considerations About Upgrading to This vRealize Automation Version
- Upgrade and Identity Appliance Specifications
- Upgrade and Licensing
- Understanding How Roles Are Upgraded
- Understanding How Blueprints Are Upgraded
- Upgrade and vApp Blueprints, vCloud Endpoints, and vCloud Reservations
- Understanding How Multi-Machine Blueprints Are Upgraded
- Upgrade and Physical Endpoints, Reservations, and Blueprints
- Upgrade and Network Profile Settings
- Upgrade and Entitled Actions
- Upgrade and Custom Properties
- Upgrade and Application Services
- Upgrade and Advanced Service Design
- Upgrade and Blueprint Price Information
- Upgrade and Catalog Items
- Checklist for Upgrading vRealize Automation
- vRealize Automation Environment User Interfaces
- Upgrading VMware Products Integrated with vRealize Automation
- Preparing to Upgrade vRealize Automation
- Updating the vRealize Automation Appliance
- Upgrading the IaaS Server Components After Upgrading vRealize Automation
- Upgrading vRealize Orchestrator After Upgrading vRealize Automation
- Add Users or Groups to an Active Directory Connection
- Enable Your Load Balancers
- Post-Upgrade Tasks for Upgrading vRealize Automation
- Port Configuration for High-Availability Deployments
- Reconfigure Built-In vRealize Orchestrator for High Availability
- Enabling the Connect to Remote Console Action for Consumers
- Restore External Workflow Timeout Files
- Verify That vRealize Orchestrator Service Is Available
- Reconfigure Embedded vRealize Orchestrator Endpoint
- Restore Changes to Logging in the app.config File
- Enable Automatic Manager Service Failover After Upgrade
- Run Test Connection and Verify Upgraded Endpoints
- Troubleshooting the vRealize Automation Upgrade
- Installation or Upgrade Fails with a Load Balancer Timeout Error
- Upgrade Fails for IaaS Website Component
- Manager Service Fails to Run Due to SSL Validation Errors During Runtime
- Log In Fails After Upgrade
- Catalog Items Appear in the Service Catalog After Upgrade But Are Not Available to Request
- PostgreSQL External Database Merge Is Unsuccessful
- Join Cluster Command Appears to Fail After Upgrading a High-Availability Environment
- Upgrade Is Unsuccessful if Root Partition Does Not Provide Sufficient Free Space
- Backup Copies of .xml Files Cause the System to Time Out
- Delete Orphaned Nodes on vRealize Automation
- Unable to Create New Directory in vRealize Automation
- Some Virtual Machines Do Not Have a Deployment Created During Upgrade
- Certificate Not Trusted Error
- Installing or Upgrading to vRealize Automation Fails
- Update Fails to Upgrade the Management Agent
- Management Agent Upgrade is Unsuccessful
- vRealize Automation Update Fails Because of Default Timeout Settings
- Upgrading IaaS in a High Availability Environment Fails
- Work Around Upgrade Problems
About Automatic Manager Service Failover
You can configure the vRealize Automation IaaS Manager Service to automatically fail over to a backup if
the primary Manager Service stops.
Starting in vRealize Automation 7.3, you no longer need to manually start or stop the Manager Service on
each Windows server, to control which serves as primary or backup. Automatic Manager Service failover
is disabled by default when you upgrade IaaS with the Upgrade Shell Script or using the IaaS Installer
executable file.
When automatic failover is enabled, the Manager Service automatically starts on all Manager Service
hosts, including backups. The automatic failover feature allows the hosts to transparently monitor each
other and fail over when necessary, but the Windows service must be running on all hosts.
Note You are not required to use automatic failover. You may disable it and continue to manually start
and stop the Windows service to control which host serves as primary or backup. If you take the manual
failover approach, you must only start the service on one host at a time. With automatic failover disabled,
simultaneously running the service on multiple IaaS servers makes vRealize Automation unusable.
Do not attempt to selectively enable or disable automatic failover. Automatic failover must always be
synchronized as on or off, across every Manager Service host in an IaaS deployment.
Run Test Connection and Verify Upgraded Endpoints
Upgrading from vRealize Automation 7.3 or earlier to 7.4 makes changes to endpoints in the target
environment.
After you upgrade to vRealize Automation 7.4, you must use the Test Connection action for all
applicable endpoints. You might also need to make adjustments to some upgraded endpoints. For more
information, see Considerations When Working With Upgraded or Migrated Endpoints in Configuring
vRealize Automation.
The default security setting for upgraded or migrated endpoints is not to accept untrusted certificates.
After upgrading or migrating from an earlier vRealize Automation installation, if you were using untrusted
certificates you must perform the following steps for all vSphere and NSX endpoints to enable certificate
validation. Otherwise, the endpoint operations fail with certificate errors. For more information, see
VMware Knowledge Base articles Endpoint communication is broken after upgrade to vRA 7.3 (2150230)
at http://kb.vmware.com/kb/2150230 and How to download and install vCenter Server root certificates to
avoid Web Browser certificate warnings (2108294) at http://kb.vmware.com/kb/2108294.
1 After upgrade or migration, log in to the vRealize Automation vSphere agent machine and restart your
vSphere agents by using the Services tab.
Migration might not restart all agents, so manually restart them if needed.
2 Wait for at least one ping report to finish. It takes a minute or two for a ping report to finish.
3 When the vSphere agents have started data collection, log in to vRealize Automation as an IaaS
administrator.
Upgrading from vRealize Automation 6.2.5 to 7.4
VMware, Inc. 79