6.2
Table Of Contents
- Migrating vCloud Automation Center 5.2.3 to vRealize Automation 6.2
- Contents
- Migrating from vCloud Automation Center 5.2.3 to vRealize Automation 6.2
- Updated Information
- Understanding vRealize Automation Migration
- Preparing for Migration
- Running the Pre-Migration Task
- Performing Manual Operations After Pre-Migration
- Stop IaaS Services in Target vRealize Automation System
- Back Up the Target vRealize Automation System
- Backing Up the Target vRealize Automation SQL Database
- Disabling Access to the Source System
- Stop IaaS Services in Source vCloud Automation Center 5.2 System
- Replacing the Target vRealize Automation Database with the Source vCloud Automation Center 5.2 Database
- Update Migration Table to Parse Port Value Data
- Running the Migration Task
- Performing Post-Migration Tasks Checklist
- Troubleshooting
- Cleaning Up Migration Tables in Source 5.2 Database
- Database Name Mismatch During Pre-Migration
- User Principals Cannot be Migrated
- Cannot Connect to Model Manager Web Service
- Cannot Connect to Remote Server
- Cannot Create Application Services Reservation
- Model Manager Web Service is Offline
- Pre-Migration Fails with a Load Balancer Timeout Error
- Migration Fails when Port Number is Part of Database Server Address
- Migration Fails with a Wait Operation Timeout Error
- Migration Fails with a RepoUtil Assembly Timeout Error
- Machines Not Visible on Items Page After Migration
- Reservation Not Available After Migration
n
Global blueprints are published as shared blueprints.
n
Machine limits, lease information, and linked clone settings that are defined on blueprints and
reservations are migrated.
n
If an approval setting or policy does not have an associated blueprint, it is not captured in the pre-
migration report.
n
If a business group has no blueprints, the migration process does not create entitlements for that
business group.
n
Blueprint icons are not migrated. Migrated blueprints use the default target system icons.
The resolution at which source and target system blueprint icons are displayed differs. For better
visual representation, recreate blueprint icons in the target vRealize Automation system at the
recommended resolution of 100 x 100.
Migrating Approval Policies
Migration creates a single, default policy in the target vRealize Automation system that is configured to
require only the approval of the business group manager. The migration process adds the approval policy
to each catalog item entitlement for each blueprint that had an approval configured in the source system.
Blueprint approval settings such as machine resource settings for CPU, memory, and storage are not
migrated. However, approval information is captured in the pre-migration report. Reference the pre-
migration report when you recreate approvals in the target vRealize Automation system.
You can recreate approval policies after pre-migration and before migration by using information in the
pre-migration report. Otherwise, you can recreate approval policies after migration. For more information,
see Recreating Approval Policies.
The following approval policy considerations apply to migration:
n
The pre-migration tasks creates the default approval policy.
n
The default approval policy name is Default Approval Policy for Migration.
n
The default approval policy is entitled.
n
Policy is defined separately from blueprints in the target system.
n
Approval policies are linked to entitlements.
n
The default policy that is created during migration is linked to each blueprint for which a policy was
defined in the source vCloud Automation Center 5.2 system.
n
You cannot edit activated approval policies.
n
You can deactivate approval policies, but you cannot delete them.
The default approval policy that is created during migration contains the following field entries:
n
Name: Default Approval Policy for Migration
n
Description: Default Policy one level of business group manager
Migrating vCloud Automation Center 5.2.3 to vRealize Automation 6.2
VMware, Inc. 15