views

Search This Blog

Saturday, April 17, 2021

vRealize Automation 7.x to vRealize Automation 8.x Migration Limitations

 

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. 

Friday, April 16, 2021

what is new in vRealize Automation 8.4.

 

VMware has released vRealize Suite Lifecycle Manager 8.4, vRealize Automation 8.4, vRealize Automation  on 15 April 2021. In this Blog I am going to high light what is new in vRealize Automation 8.4.

 

Let’s Start !!!!!

 

What is New :-

  • Hostname is updated in Ansible Tower
  • Support for multi-vm/disk configuration
  • Add disk with different sizes
  • Changing deployment projects for onboarded deployments
  • Documentation to configure proxy for vRA on premises Terraform environments
  • Unregister onboarded machines from vRA
  • Federal Information Processing Standard (FIPS) 140-2 compliance – SaltStack Config
  • Accessibility enhancements
  • Policy criteria support for additional Integer/String operators
  • Networking: Reconfigure Existing Security group for vSphere and VMC – Iterative and Day 2
  • Networking: Change On-Demand and Existing Security groups for VMC – Iterative and Day 2
  • Single secret store
  • Operations center: Custom roles support
  • Operations center: Cloud zone Insights enhancement
  • Operations center: Distinguish optimizable deployments
  • Specify order and SCSI controller for vSphere disks
  • Support for disks which are part of the image template
  • Disk placement should align with the VM in Workload placementMulti-VM scenario
  • Storage allocation as per full VM size
  • Simplification of onboarding workflow​
  • Onboarding action to support vSphere network interface
  • Support for Azure image gallery
  • Snapshot management for Azure disks
  • Support for Azure disk encryption sets
  • Enhanced support for Azure availability sets
  • Ansible enhancements
  • Puppet enhancements
  • Event Broker enhancements
  • SaltStack SecOps: SLES 15 Center for Internet Security Content
  • Release of vRA STD + and SaltStack SecOps addon in rest of world
  • SaltStack Config
  • ITSM Plugin
  • vRA plug-in in vRO
  • ABX Scale
  • GCP Sole Tenancy
  • IPAM registration for vRA 7.x workloads while onboarding into vRA 8.x
  • Change in Access Token API behavior
  • Force deleting deployments for the IaaS API endpoint

See the release notes here.

Deploy Windows VMs for vRealize Automation Installation using vRealize Suite Lifecycle Manager 2.0

Deploy Windows VMs for vRealize Automation Installation using vRealize Suite Lifecycle Manager 2.0 In this post I am going to describe ...