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.
I
hope you enjoy reading this blog as much as I enjoyed writing it. Feel free to
share this on social media if it is worth sharing.
