7.4
Table Of Contents
- Migrating vRealize Automation to 7.4
- Contents
- Migrating vRealize Automation
- vRealize Automation Environment User Interfaces
- Migration Prerequisites
- Pre-Migration Tasks
- Review Changes Introduced by Migration from vRealize Automation 6.2.x to 7.x
- Apply Software Agent Patch
- Change DoDeletes Setting on the vSphere Agent to False
- Check Templates in Your vRealize Automation 6.x Source Environment
- Prepare vRealize Automation Virtual Machines for Migration
- Gather Information Required for Migration
- Obtain the Encryption Key
- List Tenant and IaaS Administrators
- Add Each Tenant from the Source Environment
- Create an Administrator for Each Added Tenant
- Synchronize Users and Groups Before Migration to a Minimal Environment
- Synchronize Users and Groups Before Migration to a High-Availability Environment
- Run Data Collection in Source
- Manually Clone the Source Microsoft SQL Database
- Snapshot the Target Environment
- Migration Procedures
- Post-Migration Tasks
- Add Tenant and IaaS Administrators
- Run Test Connection and Verify Migrated Endpoints
- Run Data Collection on Target
- Reconfigure Load Balancers After Migration
- Migrate an External Orchestrator Server
- Reconfigure the vRealize Automation Endpoint
- Reconfigure the vRealize Automation Infrastructure Endpoint
- Install vRealize Orchestrator Customization
- Reconfigure Embedded vRealize Orchestrator Endpoint
- Reconfigure the Azure Endpoint
- Migrate Automation Application Services
- Delete Original Target vRealize Automation IaaS Microsoft SQL Database
- Update Data Center Location Menu Contents After Migration
- Upgrading Software Agents to TLS 1.2
- Validate the Target vRealize Automation 7.4 Environment
- Troubleshooting Migration
- PostgreSQL Version Causes Error
- Some Virtual Machines Do Not Have a Deployment Created during Migration
- Migration Log Locations
- Catalog Items Appear in the Service Catalog After Migration But Are Not Available to Request
- Data Collection Radio buttons Disabled in vRealize Automation
- Troubleshooting the Software Agent Upgrade
3 Use this command to update the Software Agent using the node file from step 1 and the plan file from
step 2.
/usr/lib/vcac/server/webapps/ROOT/software/updateSoftwareAgents.py -a <$DestinationVRAServer> -t <
$tenant> -tu <$TenantUser> --component_windows Software.WindowsAgentUpdate74 --component_linux
Software.LinuxAgentUpdate74 --plan_file /usr/lib/vcac/server/webapps/ROOT/software/plan --
plan_index 0 --node_file /usr/lib/vcac/server/webapps/ROOT/software/node --source_cloud_provider
azure --action plan_batch -S <$SourceVRAServer>
As an alternative, you can use this command to run one node at a time from the node file by providing
a node index.
/usr/lib/vcac/server/webapps/ROOT/software/updateSoftwareAgents.py -a <$DestinationVRAServer> -t <
$tenant> -tu <$TenantUser> --component_windows Software.WindowsAgentUpdate74 --component_linux
Software.LinuxAgentUpdate74 --plan_file /usr/lib/vcac/server/webapps/ROOT/software/plan --
plan_index 0 --node_file /usr/lib/vcac/server/webapps/ROOT/software/node --source_cloud_provider
azure --action execute_node -S <$SourceVRAServer> --node_index <0 through n-1>
As you perform this procedure, you can tail logs from the vRealize Automation virtual appliance and
host machine to see the Server Agent upgrade process.
After upgrade, the upgrade process imports a software update script for Windows or Linux to the
vRealize Automation 7.4 virtual appliance. You can log into the vRealize Automation virtual appliance
host to ensure that the software component is imported successfully. After the component is
imported, a software update is sent to the old Event Broker Service (EBS) to relay software update
scripts to the identified virtual machines. When the upgrade completes and the new Software Agents
become operative, they bind to the new vRealize Automation virtual appliance by sending a ping
request.
Note Useful Log Files
n
Catalina output for source vRealize Automation: /var/log/vcac/catalina.out. In this file, you see the
upgrade requests being made as the agent migrations are made. This activity is the same as
running a software provisioning request.
n
Catalina output for destination vRealize Automation: /var/log/vcac/catalina.out. In this file, you see
the migrated virtual machines reporting their ping requests here to include version numbers 7.4.0-
SNAPSHOT. You can tally these together by comparing the EBS topic names, for example, sw-
agent-UUID.
n
Agent update folder on destination vRealize Automation machine master upgrade log
file: /var/log/vmware/vcac/agentupdate/updateSoftwareAgents.log. You can tail this file to see
which upgrade operation is in progress.
n
Individual logs available under tenant folders: /var/log/vcac/agentupdate/{tenant}/{subtenant-
UUID}. Individual nodes are listed here as lot files with failures and in-progress extensions.
n
Migrated VMs: /opt/vmware-appdirector/agent/logs/darwin*.log. You can spot check this location
which should list the software update requests being received as well as the eventual restart of
the agent_bootstrap + software agent.
Migrating vRealize Automation to 7.4
VMware, Inc. 51