In this blog I am going to describe about vRA 7.X to vRA 8.x Migration limitations.
As part of your migration preparation process. you must be aware of the limitations of the Migration Assistant tool.
The Migration Assistant tool has the following types of limitations.
· Identity and access management limitations
· Endpoint limitations
· Blueprint limitations
· Software component limitations
· vRealize Orchestrator workflows and custom properties limitations
· Subscription limitations
· XaaS limitations
· Network limitations
· Deployment limitations
1- Identity and Access Management Limitations
The following limitations apply to the identity and access management migration:
• Tenant migration is not supported. You must manually create tenants in vRealize Automat ion 8.2. vRealize Suite Lifecycle Manager simplifies the tenant creation in vRealize Automation 8.
• Both the vRealize Automation 7.x and vRealize Automation 8.2 systems should already be connected to the same authentication source (such as Active Directory).
• The migration tool does not automatically assign roles in the vRealize Automation 8.2 users and groups.
2- Endpoint Limitations
Certain endpoints are not supported, and certain features are not preserved:
• lnfoblox is the only third-party IPAM that vRealize Automat ion 8.2 supports.
• Endpoints are not assessed or migrated if they do not contain at least one active reservation.
• If a fabric group imposes restrictions on an endpoint. those restrictions are not preserved after migration.
• If you have a vRealize Orchestrator A zure endpoint, you must manually enter the key in the configuration before migration. Without the key, the endpoint migration fails.
• Endpoints become Cloud Accounts
3- Blueprint Limitations
Certain blueprints and certain features are not supported:
• Nested blueprints (parent blueprints with child blueprints) cannot be migrated.
• Lease policies are migrated, but a Minimum lease days field is not present in vRealize Automation 8.2.
• Reservation policies are migrated as tags. But if the Reservation policy no longer exists, the blueprint cannot be deployed until the tag is deleted.
• If a primary DNS server is encoded on a network in a blueprint (instead of in a network profile), the blueprint migrates but the DNS setting does not migrate.
• Blueprints become Cloud Templates.
4- Software Component Limitations
The vRealize Automation 7.x software components do not exist in vRealize Automation 8.2:
• A software component is a drag-and-drop component that can be used to install software in a blueprint.
• If you only need to install software, most software component install and configure scripts can be easily converted into YAML blueprints with cloudConfig directives.
For many of these directives, you can use cut and paste with the same commands in the new YAML blueprint (under the runcmd section of cloudConfig).
The packages directive makes installing the software easier.
• If you need a component that can be used in a drag-and-drop operation on a blueprint to install software into a virtual machine, you can create a Custom Resource. The Custom Resource can call a vRealize Orchestrator workflow to create (install), update, or destroy software.
• Software can also be installed as part of the Ansible roles.
5- vRealize Orchestrator Workflows and Custom Properties Limitations
Some vRealize Orchestrator workflows that work with vRealize Automation 7.x do not work with vRealize Automation 8.2. Custom properties are very different between vRealize Automation 7.x and vRealize Automation 8.x. Some custom properties that are defined in vRealize Automat ion 7.x do not exist in vRealize Automat ion 8.2.
• vRealize Automation 8.2 has a great deal more flexibility in the creation of custom properties.
• You can see all the properties associated with any part of a vRealize Automation 8.2 deployment directly in the user interface.
• No property groups exist in vRealize Automation 8.2.
• Custom properties that are specified in endpoints are not migrated.
• Custom properties that are specified in reservations are not migrated.
6- Subscription Limitations
The Event Broker System in vRealize Automation 8.2 is less complex and more logical than the system in vRealize Automation 7.x:
• The life cycle state phases do not exist.
• Conditional logic in a subscription that depends on anything other than the equa ls operator cannot be migrated.
Convert your logic to equal before the migration.
• If you have a subscription based on multiple or conditions, the migration tool splits the subscription into multiple subscriptions, each with a single condition.
7- Xaas Limitations
The XaaS migration has a few limitations:
• Only one XaaS blueprint or custom resource can be migrated per business group.
• If the Xaas blueprints or custom resources belong to different business groups but are configured to the same workflow, they are not detected during the migration assessment.
When migrated, the first migrated XaaS blueprint or custom resource creates the vRealize Automation 8 Xaas cloud template or custom resource.
As a result, the subsequent XaaS blueprints or custom resources are skipped during migration because the XaaS object already exists in vRealize Automation 8.
8- Network Limitations
Migration has the following network limitations:
• You can only set one CIDR and only use the corresponding IP ranges.
• The vRealize Automation 8 Migration Assistant does not support blueprints with a private network component that do not contain a private network profile for migration.
• vRealize Automation 8.2 only supports lnfoblox. No other third-party IPAM is supported.
You can use the IPAM SOK to add non supported third-party IPAMs to vRealize Automation 8.2.
9- Deployment Limitations
The Migration Assistant tool has these limitations when migrating deployments:
• The migration of a deployment is final regardless of whether it succeeded or failed. You cannot retry a deployment migration.
• After migration, you cannot change the owner of a deployment.
Migrated deployments are owned by the user that performed the migration.
The original deployment owner is added as a custom property on a machine resource post migration.
• Deployment migration migrates the associated blueprints, but they are no longer linked to the deployment post migration.
• Historical costing information is not migrated with deployments.
• You cannot migrate a source deployment if it has one or more NAT network components for NSX-T Data Center, or one or more network components routed or NAT (or both) to NSX-T Data Center.
• If your source deployment contains more than one NSX load balancer component, the deployment is migrated as a single load balancer component.
Very informative
ReplyDelete