Accelerate VMware Migrations using Amazon Q Developer with Application Discovery Service Agentless Collector

9 minute read
Content level: Advanced
0

Quick guide on how to deploy the Agentless Collector to enable automatic application grouping and migration waves planning for Amazon Q-assisted VMware migrations

In this post, we explore how to utilize the Application Discovery Service Agentless Collector to enable automatic application discovery and migration waves planning, using the Amazon Q Developer transformation capabilities for VMware workloads.

Amazon Q Developer is an AI-powered assistant for software development that takes the undifferentiated heavy-lifting out of complex and time-consuming application migration and modernization projects. Specifically, Amazon Q Developer transformation capabilities for VMware enables customers to easily migrate on-premises VMware workloads to cloud-native architecture and expedite cloud migrations.

The AWS Application Discovery Service Agentless Collector (Agentless Collector) is a tool that gathers information about your on-premises servers, network configurations and flow data, database engines and schema details etc. It is deployed as a lightweight virtual appliance within your on-premises VMware environment, making it possible to capture application inventory and dependencies via vCenter without needing to install agents on every workload.

Furthermore, using the Agentless Collector enables Amazon Q to perform automatic application discovery and grouping that accelerates the migration process for VMware workloads.

This guide will cover how to deploy and configure the Agentless Collector within your on-premises VMware environment. I will also demonstrate how to leverage Agentless Collector captured workload information for automatic application grouping and waves planning, through a VMware migration workflow example using the Amazon Q Developer.

 

Pre-requisites

 

Deploy the Agentless Collector

Within the AWS console, navigate to Migration Hub > Discover > Tools , where you’ll find a link to download the OVA file of the Application Discovery Service Agentless Collector. Enter image description here  

Once the file is downloaded, log into your vCenter and deploy it using the Deploy OVF Template option. Enter image description here  

Next, we’ll need to configure an IP address for the Collector so it can communicate to the vCenter for data collection. Follow this guide to configure a static IP address for the Collector based on your on-premises network environment.

Now open a browser page and navigate to https://<agentless-collector-ip-address>/ to access the Collector console.  

To activate the Agentless Collector, we’ll need to supply the AWS access-key and AWS secret-key from the Application Discovery Service IAM user as specified in the pre-requisites. Enter image description here  

This will initialize the Collector and it will automatically connect to your Migration Hub's home Region within a minute. Enter image description here  

We can also verify the Collector status from the Migration Hub > Discover > Data collectors > Agentless Collectors: Enter image description here

     
 

Set up the Agentless Collector

Within the Agentless Collector console, navigate to VMware vCenter section to enter your vCenter server management URL and credentials. Enter image description here  
You should see the vCenter Data collection status changed to “Collecting” within a minute. Enter image description here

 

We can also verify the data collection status at the Migration Hub within the AWS console. Within 5~10 mins the Agentless Collector should start populating the discovered server list (Migration Hub > Discover > Servers). Enter image description here  

We’ll now configure the network data module to start collecting TCP/IP flow information among discovered servers, which will enable Amazon Q Developer to build the application profiles for migration grouping and waves planning.

Within the Agentless Collector console, navigate to Network Data Collection and click “set up network connections”.

We’ll need to supply the SNMPv3 (Linux) and/or WinRM (Windows) monitoring account credentials for all workloads in migration scope. Note there are specific requirements for setting these SNMPv3 or WinRM accounts, as defined here. Enter image description here  
You can then verify the SNMP/WinRM collection status for each server, and (if required) to troubleshoot accordingly. Enter image description here  
To verify that the application flow data is being captured correctly, we can utilize the Network visualization tool under the Migration Hub > Servers > Network.

Use the search box to select a group of servers and verify their application flow data captured by the Agentless Collector. You can also check the inbound/listening ports for a specific sever. Enter image description here  
At this stage, we have completed the basic configuration of the Agentless Collector. Ideally you should leave the collector running for at least a week to collect enough data before proceeding to the Q Transform for migrations planning.

 
 

Leverage Agentless Collector data for Amazon Q VMware Migration Planning

Once you are ready to kick off the migration workflow, follow this awesome blog post to setup an Amazon Q Developer: Transform workspace and create a VMware migration job.

We’ll first need to connect to a source AWS account to collect your on-premises discovery data, and this is the same account where the Agentless Collector is connected to.

After the source account connection is established, you should see the following message indicating you are ready to send Agentless Collector discovered data to Amazon Q for automatic application grouping and migration wave planning. (NOTE: Here you also have the option to upload a RVtools import. However, Amazon Q won't be able to provide automatic application grouping and waves planning since RVtools doesn't include live network connection data).

Next, click “Send to Q” to import the ADS collected data to Amazon Q for analysis. Enter image description here  
However, if you are getting the below message indicating missing network-connection data, you’ll need to check the Agentless Collector network data module configuration, and collection status for those discovered servers. If everything looks fine you might just need to let the collector run for a longer period to collect more connection data. Enter image description here  
Once Amazon Q has received imported data, we'll get a quick summary including how many servers are ready for application grouping, or how many are missing connection data etc. We can also download the full report as CSV exports.

Based on the summary, we have the option to send the existing data to finalize analysis, or to re-evaluate if we need to troubleshoot the Agentless Collector, or wait for it to collect more data and try again. Enter image description here  
After the existing data is sent to Q, we'll soon receive the recommendations for application grouping and wave planning.  

Download the recommendation file (CSV format), review and then update it as per your migration planning requirement:

In my example:

  • Q Transform was able to pick up the 3x demo apps (a mixture of LAMP and WISA stacks), and automatically group them into 3x migration waves. (No action is required here but I've renamed the application waves to Wave1/2/3 for illustration purposes)
  • Server 7 to 10 do not belong to a typical application stack (i.e. a Kubernetes cluster), and I can update the CSV file to provide an application name and place them into a separate application wave.
  • Server 11 to 13 are on-premises management appliances (including the Agentless Collector itself). These workloads will not be migrated so I will simply delete them from the list.

Enter image description here  
I then upload the updated CSV file and send it back to Amazon Q to finalize the application groups and waves planning. These data will also be sent to and processed at the Migration Hub. Enter image description here  
Navigate back to Migration Hub > Applications, we can see the 10x in-scope workloads are now grouped into 4x applications and waves as per our migration planning. Enter image description here  
We are now ready to move onto the next phase of the Amazon Q migration workflow (i.e. build VPC configurations in the target account, and execute migration waves via AWS Application Migration Service (MGN)).

Refer to this blog post for further details to complete your migration workflow.

 
 

Clean Up

If you are running the Amazon Q Migration workflow within a test/demo environment, you might need to clean up the discovered data within the Migration Hub.

  • Remove the Agentless Collector: Before you can clean up the server list, first stop data collection or simply power off the Agentless Collector appliance. This will stop the collector from continually feeding live data to your account. After that, use the AWS CLI tool to remove the Agentless Collector from your Migration Hub: aws discovery batch-delete-agents --delete-agents agentId="agentless-collector-id",force=TRUE  
  • Remove Servers: To remove discovered servers from Migration Hub, you can use this AWS sample tool: ads-cleanup-resoruces. First, tag the servers in Migration Hub with a key/value pair (e.g “delete:yes”), and then use the tool to remove them: cleanup-ads-resources python3 cleanupads.py -k delete -v yes  
  • Remove Applications: simply navigate to Migration Hub > Applications, select the Applications and click Action > Remove application.

 
 

Conclusion

This post walked through an example of deploying the Application Discovery Service Agentless Collector, which enables Amazon Q to perform automatic application discovery and waves planning for accelerating VMware migrations.

To learn more, refer to these additional resources: