Simplifying Asset Collection with Google Cloud MCDC v6.3

Brian Kudzia
Google Cloud - Community
9 min readAug 15, 2024

In my previous post, I summarized the setup details for Migration Center version 5.3. To quickly recap, Migration Center scans your assets and provides a detailed analysis on resource utilization, right-sizing recommendations, and total cost of ownership. In order to help streamline the setup process, this blog will serve as a one-stop shop to deploy Google Cloud Migration Center in your environment. This updated guide covers Migration Center 6.3.

The first thing to determine is where you plan to deploy Migration Center. Just like most Google Cloud products, Migration Center is API driven, and will need to belong to a Google Cloud Project. If you already have a Google Cloud Organization, this shouldn’t be a problem. For those that do not, you can work with your account team to get one established.

Once you have a Google Cloud project, IAM roles will need to be assigned to use Migration Center. You can assign the following roles to the user(s) or group(s) who will be setting it up:

  • Migration Center Admin (roles/migrationcenter.admin)
  • Viewer (roles/viewer)
  • Service Account Key Admin (roles/iam.serviceAccountKeyAdmin)

For more granular IAM delegation, you can review the list of Migration Center roles here. You can also create a custom role to narrow down the scope of permissions for your users by following the steps denoted in the previous link.

Once your users are given the right roles, activate the service. You can do this by navigating to the Google Cloud console, navigating to the project you wish to enable Migration Center in, then go to the Migration Center homepage to enable the API. Enabling the API can be codified in Terraform if you’re using IAC to create and manage projects. You will be prompted to select the region to store your data. Be careful here if you have data residency requirements. You can optionally add in an Expert Request number if you have been given one by your Google Cloud account team. Optionally you can set Migration Preferences, which will be used later when you run reports. You can always set these up (and change them!) later, but should look similar to this:

Once done, you’ll need to install the Discovery Client. It’s a best practice to install one Discovery Client per datacenter, so plan accordingly. The Discovery Client has hardware, OS, and browser requirements:

Hardware:

  • For scanning up to 10,000 servers: 2 CPU core, 12 GB RAM, 30 GB free space

**If scanning more than 10,000 servers, you will need multiple Discovery Clients**

OS:

  • Windows Server 2016 or higher
  • Windows Desktop client version 10 or higher (64-bit)

Browser:

  • Google Chrome: 2 latest versions
  • Microsoft Edge: 2 latest major versions

From an outbound network perspective, the VM running the Discovery Client needs minor network configuration. It will require outbound TCP 443 access to the following API endpoints in Google Cloud:

The Discovery Client VM will also need open line-of-sight to your scanned assets. For Linux VMs, it requires inbound access on TCP 22 (SSH), and for Windows VMs, it requires inbound access on TCP port 135 (WMI) and TCP inbound dynamic ports as follows:

  • Ports 49152–65535 for Windows Server 2008 and newer
  • Ports 1025–5000 for Windows Server 2003 and older

For all VM types, the Discovery Client VM requires ICMP to your scanned assets.

Lastly, if your organization uses a network proxy, you can configure these settings.

Once we have a VM that meets all installation and network requirements, you can now download and configure the Discovery Client:

  1. Download the discovery client on a Windows machine that can access the other machines in your infrastructure
  2. Run the discovery client installer as a local administrator
  3. Review and accept the license agreement
  4. Follow the instructions on the screen to complete the installation
    Please note — at the end of the installation, a restart will be required
  5. After the installation is complete, you can see a new application shortcut on your desktop.

Launch the Discovery Client. The first time you open the application, you will choose whether you want to automatically upload the collected data to Migration Center or not. If you enable data upload (connected mode), the Discovery Client automatically sends the collected data to Migration Center. This mode requires a connection to the Internet and is the recommended mode for most situations.

Alternatively, if you don’t enable data upload (disconnected mode), the discovery client stores the collected data locally and will work without an Internet connection. If you choose this option, you can opt to send the data to Migration Center later, if desired. The rest of this guide will focus on Connected Mode.

To continue with Connected Mode, click Log In to Migration Center:

Select Login with Google, and choose your authorized Google account, and enter the project name or ID where Migration Center is enabled, then click Continue.

If your organization has policy restrictions that prevent you from creating a service account or service account key, ask your organization administrator to create a service account with the Migration Center Discovery Client role assigned, then create a key for that service account. In the “Add an access key” step, check the box for “I have a service account key”, then upload the key that your administrator gave you. If you have issues with the authorization, see here for troubleshooting steps.

To complete the configuration, provide a descriptive name for this instance of Migration Center, then click Finish.

Next, review the target asset requirements. The Discovery Client can collect information about Windows VMs, Linux VMs, VMware vCenter, and databases. To recap the link, the requirements for Windows assets are:

  • WMI (Windows Management Instrumentation) Service running
  • Windows Firewall disabled
  • Alternatively, a firewall exception to allow for Remote WMI
  • Open line of sight from Discovery Client to each asset
  • An account with local administrator rights to the operating system –NOT a domain admin

For Linux:

  • SSH enabled with support for the following encryption algorithms:
    – RSA and DSA in PEM format
    – ECDSA 256/384/521, ED25519 in OpenSSL or PEM formats
  • Open line of sight from Discovery Client to each asset
  • An account with user-level access (no sudo or root privileges required)

For vCenter:

  • Version 5.5 or later
  • TLS version 1.2 or later
  • The credentials required to access vCenter
  • The vCenter URL
    – Optionally, the vCenter Inventory Path to limit the scope of the collection
    – You can add up to 100 vCenter sources (URL + inventory path)
  • The machine running the Discovery Client must be able to connect to your vCenter and ESX hosts
  • The user provided needs read-level access to the ESX hosts and the VMs

Lastly, the data you collect with this method depends on the settings for statistics in vCenter:

  • Level 1 exposes only CPU and memory performance
  • Level 2 exposes the network performance
  • Level 3 exposes input/output operations per second (IOPS)
  • Level 4 exposes all the available metrics

By default, the statistics level is set to level 1. Levels 1 and 2 let you collect partial data about your infrastructure, while level 3 lets you collect everything you need to generate a complete total cost of ownership (TCO) report. Please note that after the statistics level is changed in vCenter, it might take several hours for performance data to become available.

For databases:

***Please note v6 doesn’t support discovery and collection of database assets. See this document for more information on how to discover and import database data.***

Once your assets can meet these requirements, input credentials into the Discovery Client. You will need credentials for each type of asset you are scanning. From the Discovery Client UI, for OS Scan credentials:

  1. Click Credentials in the Discovery Client UI:

2. Click Add OS Credentials from the blue box if its the first time running:

3. For subsequent credentials, click Add credentials -> Add OS Credentials:

4. Enter a name for your credential, then select one of the credential types available.

5. Username & Password: applicable to both Windows and Linux collections.
– Enter domain accounts as DOMAIN\USERNAME.
– Enter local accounts as .\USERNAME.

6. SSH Key / Certificate (Linux only): you can SSH into a Linux machine with a certificate-based authentication instead of using a username and password combination. Select a previously uploaded certificate, or upload a new private key in the PEM format.

7. Click Save to finish, or Save and create another to add additional credentials

For vSphere:

  1. Click Credentials from the UI

2. Click Add credentials -> Add vCenter Credentials

3. Enter a name for your credential

4. Enter your vSphere username and password

5. Click Save and add vCenter

6. Select your vSphere credentials, the hostname / IP address of your vCenter, supply the inventory path (if necessary), and select your Linux and Windows credentials:

7. Click Save

Once all of your credentials have been entered, add your assets. The most common method is by adding IP address ranges, but please be aware of some limitations:

  • Each Discovery Client can scan up to 10,000 servers max
  • You can add up to 100 IP ranges, and each can have at most 65,536 IPs (/16 CIDR blocks)
  • Only supports IPv4

In the Discovery Client UI:

  1. Click Discovery

2. Click IP Addresses, then Add IP Addresses, and notice the options:
Manual Ranges — add IP ranges you wish to scan one by one
Ranges via CSV — download a template to add multiple ranges en masse
IP Addresses via CSV — download a template to add individual IP addresses instead of full ranges

3a. To add IP ranges manually:
– Click Add IP Addresses -> Add ranges manually
– Click to accept the conditions
– Enter the starting and ending IP addresses for each range, then click save

3b. To add IP ranges via a CSV template:
– Click Add IP Addresses -> Add ranges via CSV
– Download the template from the link provided
– Populate the template with your IP address information
– Upload the template for scanning

3c. To add IP addresses via a CSV template:
– Click Add IP Addresses -> Add address list via CSV
– Download the template from the link provided
– Populate the template with your IP address information
– Upload the template for scanning

Once your asset information has been uploaded, the Discovery Client will take care of the rest! It will poll your assets for specific data at the following intervals:

  • Guest-level system data - every 24 hours
  • Guest-level performance & network data - every 10 minutes
  • vCenter inventory-level data - every 24 hours

If you wish to adjust the scanning frequency, this can only be done via an “opt-out schedule.” These can be configured in the UI:

  1. In the application, go to the Servers tab
  2. From the list of available servers, select those you want to customize the schedule, then click Configure schedule
  3. You can choose between existing opt-out schedules you’ve created or create a new opt-out schedule
  4. For new:
    – Enter a name for your opt-out schedule
    – Select the days when the collection shouldn’t run
    – For each day, select the two-hour time slots when the collection shouldn’t run
    – To confirm your opt-out schedule, click Save

The details will be available in the Migration Center UI inside your Google Cloud Project. The Summary menu will display high-level information about the data collected, and you can navigate to the Report Catalog to run reports to pull out information relevant and important to you. For more information on how to interpret this collected data, see my article here.

If you’ve made it to the end, I hope you found this summarization helpful, and this kickstarts your migration to Google Cloud!

--

--

Google Cloud - Community
Google Cloud - Community

Published in Google Cloud - Community

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Brian Kudzia
Brian Kudzia

Written by Brian Kudzia

I'm a Google Cloud InfraMod Engineer. I help customers adopt and migrate to our platform.