You can see the latest product updates for all of Google Cloud on the Google Cloud page, browse and filter all release notes in the Google Cloud console, or programmatically access release notes in BigQuery.
To get the latest product updates delivered to you, add the URL of this page to your feed reader, or add the feed URL directly.
May 06, 2024
The Migrate to Containers UI in the Google Cloud console, migctl, and CRDs that used processing clusters to migrate workloads to Google Cloud are no longer available.
To perform migrations, use the Migrate to Containers CLI on your local machine. For more information, see Migrate to Containers overview.
If you have any questions or require additional support, then reach out to m2c-external-feedback@google.com.
January 03, 2024
The Migrate to Containers UI in the Google Cloud console, migctl, and CRDs that use processing clusters to migrate workloads to Google Cloud are now deprecated. They are supported for existing users until May 2024, after which they will no longer be available. If you're new to Migrate to Containers, then use the Migrate to Containers CLI to perform migrations on your local machine. For more information, see Migrate to Containers CLI architecture.
November 29, 2023
Support for IBM WebSphere Application Server migrations has been enhanced. The websphere-container plugin now supports WebSphere Application Server traditional as a source and as a target.
On November 29, 2023 we released version 1.4.0 of the Migrate to Containers modernization plugins.
Learn how to Upgrade Migrate to Containers plugins.
The websphere-traditional plugin is now deprecated. For
existing customers, it is still supported till December 2023, after which it
will no longer be available. If you're new to WebSphere workload modernization,
then use the websphere-container plugin with the Migrate to Containers CLI instead.
October 30, 2023
On October 30, 2023 we released version 1.3.1 of the Migrate to Containers modernization plugins.
Learn how to Upgrade Migrate to Containers plugins.
On October 30, 2023 we released version 1.3.1 of the Migrate to Containers modernization plugins.
Learn how to Upgrade Migrate to Containers plugins.
The plugins for migrating Apache, JBoss, WordPress, and IBM WebSphere traditional applications to containers are now generally available. These plugins provide a streamlined and simplified experience for migrating applications based on these frameworks.
August 22, 2023
On August 22, 2023 we released version 1.3.0 of the Migrate to Containers modernization plugins.
Learn how to Upgrade Migrate to Containers plugins.
The following changes have been made to the IBM WebSphere Application Server migration:
Renamed the plugin from
websphere-containertowebsphere-traditional-container. This plugin now supports WebSphere Application Server Traditional as a migration source.Added support for WebSphere Application Server Liberty as a target.
The
was-homeparameter is now mandatory.
The following changes have been made to the discovery parameters for the Tomcat plugin:
- The
java-versionparameter is now added as input to Tomcat migrations. - The
catalina-baseparameter can now include multiple directories delimited with colons (:). - The
java-version,catalina-baseandcatalina-homeparameters are now mandatory.
Linux system service endpoints are no longer automatically discovered and must be manually specified while customizing the Linux migration plan.
June 27, 2023
On June 27, 2023 we released version 1.2.0 of the Migrate to Containers modernization plugins.
Learn how to Upgrade Migrate to Containers plugins.
May 22, 2023
On May 22, 2023 we released Migrate to Containers 1.15.0.
The use of migration sources based on Migrate to Virtual Machines v4 is no longer supported.
To migrate application components from VMs running on VMWare clusters, you can use Migrate to Virtual Machines v5 integration. For more information, see Adding Migrate to Virtual Machines as a migration source.
To migrate application components from AWS or Azure use Migrate to Virtual Machines v5 to migrate VMs to Compute Engine, and then use Migrate to Containers to perform a migration from the created Compute Engine instance. For more information, see the Migrate to Virtual Machines version 5.0 documentation.
The use of migration sources based on Migrate to Virtual Machines v4 is no longer supported.
To migrate application components from VMs running on VMWare clusters, you can use Migrate to Virtual Machines v5 integration. For more information, see Adding Migrate to Virtual Machines as a migration source.
To migrate application components from AWS or Azure use Migrate to Virtual Machines v5 to migrate VMs to Compute Engine, and then use Migrate to Containers to perform a migration from the created Compute Engine instance. For more information, see the Migrate to Virtual Machines version 5.0 documentation.
Enhanced the Windows features filtering to only allow features supported by Windows Docker images to work.
The legacy Linux runtime is now deprecated. The generated migration plan now uses the enhanced Linux runtime by default. You can choose to use the legacy Linux runtime, which is planned to be supported until August 2023, by setting the value of the v2kServiceManager flag in the migration plan to false.
To see how to convert existing migrations to the new Linux runtime, see Upgrade container workloads for enhanced runtime.
If you have migrated applications using the legacy runtime, you can install the legacy runtime support using the following command:
migctl setup install --runtime
For more information, see Before you begin deploying a Linux workload to a target cluster.
March 28, 2023
On March 27, 2023 we released version 1.1.0 of the Migrate to Containers modernization plugins.
Learn how to Upgrade Migrate to Containers plugins.
Preview: Added support for refactoring WordPress Servers running on Apache2 Linux to containers, which lets you deploy WordPress sites as containers on GKE, GKE Autopilot clusters, Anthos clusters, and Cloud Run.
For more information, see Migrate a WordPress site.
Introduced the following features for JBoss migration:
- Support for JBoss versions has been extended and Migrate to Containers now supports migration of JBoss EAP versions 7.0 - 7.4 to equivalent Wildfly community based container images, besides migrations of Wildfly versions 8.1.0 - 26.1.1.
- Secrets are now automatically created from extracted security realms configuration and key-stores. This new feature fixes potential security risks and lets you update secrets without having to recreate images.
- The
targetImageHomeproperty has been added to the migration plan to allow users to specify an alternative container image with a differentJBOSS_HOMElocation. - The
ExcludeFilesproperty has been added to the migration plan, which lets you explicitly exclude files and directories from the container image. - The data migration feature now automates the creation and mounting of a Persistent Volume Claim (PVC) for the
$JBOSS_HOME/standalone/datadirectory. This directory is available for use by services that require storing content in the file system.
Filtering out files located at /tmp when discovering Tomcat application dependencies.
Docker images may contain broken symlinks. Ensure that the tar archive artifacts added to dockerfile don't contain symlinks that don't resolve to another file in the archive. If they do, either retrieve the files from the source VM and add them to the dockerfile manually, or replace the symlinks in the source VM and perform extraction again.
Docker images may contain broken symlinks. Ensure that the tar archive artifacts added to dockerfile don't contain symlinks that don't resolve to another file in the archive. If they do, either retrieve the files from the source VM and add them to the dockerfile manually, or replace the symlinks in the source VM and perform extraction again.
March 20, 2023
Using Anthos for VMware processing clusters for containerisation of VMware sources is now deprecated and is planned to be supported till July 2023.
Documentation restructured to provide better visibility of high-level tasks.
The following issues were fixed:
migctl setup uninstall failure - source snapshot is not deleted. This is happening when the corresponding source provider was already deleted.- Starting a migration from the UI page "Sources & Candidates" might get stuck on a "retrying" step.
The following are open issues:
migctl migration statussometimes prints an error message before the migration table. This message does not indicate a concrete problem and can be ignored.- The UI fails when performing "Processing Cluster Add" having Resource Location Org Policy. To overcome that the processing cluster installation should be done using migctl and the target region should be provided using
--gcp-region. - Creation of multiple source providers at the same time might cause timeouts. If this happens, delete and recreate source provider objects that failed to be created.
- Replicated VM deletion might hang depending on other object deletion. To prevent this from happening, delete the Migrate to Virtual Machines (M2VM) source after deleting the corresponding Migration objects. Otherwise, if this happens, delete the M2VM replications manually.
- Generated Kubernetes deployment specifications might contain invalid (non-DNS1123 compliant) container names when such names appear in the source VM. To prevent this from happening, go over the migration plan before generating artifacts and change the names to be DNS1123 compliant.
December 06, 2022
On Dec 6, 2022 we released Migrate to Containers 1.14.0.
Support for refactoring applications running on JBoss Enterprise Application Platform or WildFly application platform to containers, which lets you deploy the application as containers on GKE, GKE Autopilot clusters, Anthos clusters, and Cloud Run, released for Public Preview. See Migrate JBoss Servers.
Support for refactoring Apache 2 Linux based applications to containers, which lets you deploy Apache 2 application components as containers on GKE, GKE Autopilot clusters, Anthos clusters, and Cloud Run, released for Public Preview. See Migrate Apache 2 Servers.
Enhanced control on the verbosity of backend logs. You can now use the migctl logging set-verbosity <verbosity> command, where verbosity 0 corresponds to info logs only and verbosity 1 shows debug logs. See migctl reference.
Containerization from AWS, Azure, and local vSphere (Anthos on vSphere) sources and local processing in AWS clusters are now deprecated and planned to be supported until April 2023.
The following are open issues:
- migctl migration status sometimes prints an error message before the migration table. This message does not indicate a concrete problem and can be ignored.
- UI fails when performing "Processing Cluster Add" having Resource Location Org Policy. To overcome that, the processing cluster installation should be done using migctl and the target region should be provided using
--gcp-region. - Two migrations from different M2VM sources on the same VM can affect each other. When using M2VM sources, users should avoid creating multiple Migration objects from different sources at the same time for the same VM.
- Creation of multiple source providers at the same time may cause timeouts. If this happens users should delete and recreate source provider objects that failed to be created.
- Replicated VM deletion can hang depending on other object deletion. To prevent this from happening users should delete M2VM source after deleting the corresponding Migration objects. Otherwise, if this happens users should delete the M2VM replications manually.
- migctl setup uninstall failure - source snapshot is not deleted. This is happening when the corresponding source provider was already deleted. If this happens users should recreate the corresponding source provider and after migrations are removed to proceed with uninstalling.
- Starting a migration from the UI page "Sources & Candidates" might get stuck on a "retrying" step. If this happens users should create a Migration using the VM name as input.
September 20, 2022
On Sep 20, 2022 we released Migrate to Containers 1.13.0
Added Kubevirt UEFI support. Virtual machines with UEFI firmware can now be migrated without user interaction. Migrations to Anthos VM Runtime that previously failed due to this limitation will need to be recreated.
Support for refactoring Tomcat applications to containers, which lets you deploy Tomcat application components as containers on GKE, GKE Autopilot clusters, Anthos clusters and Cloud Run, has moved from the Public Preview stage to General Availability.
The following issues were fixed:
Removed support for Windows SAC images following Microsoft announcement concerning Windows Server Semi-Annual Channel end of servicing.
Propagate discovery failures into the migration status.
Don't show the warning
skipping setup of default image and artifact repositories because either --json-key, --gcp-project or --gcp-region weren't specifiedwhen all parameters are given on Anthos on Bare Metal installations.The v2k-websphere image is now up-to-date (the promoted one).
Separated the logic of creating a source and validating its status. When creating an unhealthy source, the create command would succeed with an indication that there is a problem in the source.
Windows IIS Application modernization:
Added support for Windows services. This allows you to specify Windows services that should be part of the migrated Windows IIS application. With this new capability you can migrate Windows IIS applications that are dependent on other windows services.
Added support for generation of Kubernetes health probes. Health probe monitoring can help reduce the downtime of your application and provide better service monitoring. Migrate for Containers creates the required probes section in the deployment YAML. The Windows IIS health probes are enabled by default and can be disabled or modified while customizing the migration plan.
Added support for automated COM object registration. Windows DLLs that contain COM objects are copied to the target image and are automatically registered as a COM object.
New progress indication to Migrate to Containers CLI tool - Running migctl migration status displays the progress of snapshot creation stage, upload progress of generate artifact stage, and for Linux migration, the progress of packing the image file.
Added periodic health checks for migration sources to assure migration source availability and health. Migrate for Containers periodically checks the status of the source providers to reflect potential problems such as missing service accounts or lack of permissions. This enhancement helps ensure smooth operation and alerts you of failure cases.
The following are open issues:
If IIS files are not accessible to BUILTIN/Administrators, the discovery phase of IIS modernization will fail.
Support migration of Windows IIS sites where Administrator user has no permissions to access the IIS configuration files.
On Linux migrations, if the migration plan YAML is missing the Image section, the task will fail with a panic instead of an indicative message.
On Migrate for Compute Engine, source creation can fail because it's unable to find a secret caused by a race issue of the reconciler and the secret creation. Workaround: reconciler should be updated of the new secret after a few minutes.
Error: Source mysrc was created with an error: Secret <some_secret> not foundOn Tomcat, if path X is defined on excludeFiles, and its ancestor directory is defined on additionalFIles, we will migrate X instead of excluding it.
When using Migrate for Compute Engine 5 as a migration source, if two Migrate To Container sources were created referring to the same Migrate for Compute Engine source, migrations created from both sources may interfere with each other. Workaround: delete one of the sources.
July 13, 2022
List the source inventory for Google Compute Engine, local-vmware, and Migrate for Compute Engine 5.x sources
Migrate to Containers has added support for the inventory listings of VMs in connected sources. Users can list an inventory of the VMs in connected Migrate to Containers sources. The new inventory listings are available for Google Compute Engine, local-vmware, and Migrate for Compute Engine v5.0 sources.
Modernize VMs to run Anthos for VMs (A4VM)
Migrate to Containers has added a new modernization feature, which enables traditional VMs to run on Anthos for VMs. Anthos for VMs extends Anthos on bare metal (now known as Google Distributed Cloud Virtual) to let you run and manage containers and VMs on a unified, Google Cloud-connected platform in your data center or at the edge. For more information on this feature, see About Anthos for VMs.
Support for local-ovf sources
Migrate to Containers has added support for creating Anthos VM runtimes from local OVF files. This enables users to modernize VMs to the Anthos VM Runtime by importing their OVF file into their local Anthos bare metal cluster using Migrate to Containers.
June 21, 2022
Inventory retrieval for Local VMWare, Google Compute Engine, and Migrate for Compute Engine v5 source providers
A VM inventory is now available for local VMWare, Google Computer Engine, and Migrate 4 Computer Engine v5 source providers and is accessible through both Cloud Console and migctl. Using this feature, the list of candidate VMs for migration can be viewed for a given source, including the VM ID required to start a new migration.
To access the inventory through Cloud Console: go to your sources page, and select a source from the dropdown.
To access the inventory through migctl run the
migctl source list-vms <my-source>command.
Linux Service Manager health probes
Linux Service Manager deployments will use Kubernetes readiness and liveness probes by default. Users can select which services are probed while editing the migration plan. Use health probes to provide better pod management and reduce down time during scaling and rolling updates. To learn more about the available probes, see Set Linux v2kServiceManager health probes.
Tomcat health probes
Tomcat deployments will use Kubernetes readiness and liveness probes by default. Users can disable or modify those probes while editing the migration plan. Use health probes to provide better pod management and reduce down time during scaling and rolling updates. To learn more about the available probes, see Set Tomcat health probes.
Linux Service Manager health probes
Linux Service Manager deployments will use Kubernetes readiness and liveness probes by default. Users can select which services are probed while editing the migration plan. Use health probes to provide better pod management and reduce down time during scaling and rolling updates. To learn more about the available probes, see Set Linux v2kServiceManager health probes.
Migration fit assessment
Migrate to Containers offers a fit assessment tool that runs on a VM workload to determine the workload's fit for migration to a container. To learn more about the tool see, Using the fit assessment tool.
Windows features
The following functions were added to the Windows IIS migration flow:
- MSVC Runtime support - The migration flow will discover Microsoft Visual C++ runtime libraries installed on the source VM and will allow installing these runtimes on the migrated container.
- PATH environment variable extraction - The migration flow will discover additional PATH variable entries and will add them to the PATH variable in the migrated container.
migctl fails to get artifacts getting EOF from storage provider.
Migration fit assessment
Migrate to Containers offers a fit assessment tool that runs on a VM workload to determine the workload's fit for migration to a container. To learn more about the tool see, Using the fit assessment tool.
Wrong default value was set for serverautostart in Windows IIS migration. sites were not started in some cases.
In some cases where strict network policies were applied, GKE failed to apply AppArmor profiles which are needed for M2C and failed to upgrade, causing the cluster to be in an usable state.
migctl fails to get artifacts getting EOF from storage provider.
May 17, 2022
Migctl may fail installation on GKE clusters with the following error:
Error: failed creating Cloud Storage bucket (-migration-artifacts) for Migration artifacts,
googleapi: Error 400: Invalid bucket name: '-migration-artifcats', invalid
In this case, please uninstall and install with the --gcp-project and --gcp-region flags.
204879458: If image repository permissions are invalid, migration will get stuck in ExtractImage instead of UploadImage step
225638684: OpenLiberty containers may fail to run web applications deployed as WAR archives.
Uninstall might be stuck when a sourcesnapshot CRD cannot be deleted. To workaround please run kubectl edit sourcesnapshot -n v2k-system and remove all finalizers
V1 API
Migrate for Anthos and GKE API has graduated to v1 in 1.11.1 release. The v1beta2 Migration API is deprecated and will be supported until May 2023.
208361449: Artifact repository Health checks are not implemented for S3 repositories. Migctl commands that query the health state of the repository will warn that health checks cannot be performed.
224485583: null value of serverautostart for some Windows migration plans.
227137961: Prevent concurrent migration on the same migrating VM when using M4CE5.X source.
216537540: migctl cannot be used to upgrade the m2c installation newer than the migctl version. For example, if migctl is 1.9.0, it cannot upgrade a cluster to have 1.11.0.
223553376: Secrets created by migctl (for example when creating a source provider) may not always be cleaned up when the objects that depend on them are deleted (for example when issuing migctl source delete …).
220853359: ABM can be installed without specifying all of –gcp-project, –gcp-region and –json-sa. In this case the default repositories are simply not created.
Building and deploying Windows containers with Skaffold
Skaffold yamls generated as part of the migration artifacts for Windows flow now help operators to accelerate container image build and deploy to GKE and Anthos clusters.
Artifact Repository Health Checks
When creating a new artifacts repository, or updating an existing one, migctl will wait for health information and produce a warning in case the provided service account does not have permissions to upload artifacts to the specified bucket. To skip the synchronous health checks, –async can be passed to the migctl command.
When creating a new migration, migctl will query the migration's specified artifact repository (or the default if it was not specified), and produce a warning in case the provided service account does not have permissions to upload artifacts to the specified bucket.
When generating artifacts for the migration, migctl will query the migration's specified artifact repository (or the default one if it was not specified), and produce a warning in case the provided service account does not have permissions to upload artifacts to the specified bucket.
218855996: Windows global path variables and short folders names are not migrated
Uninstall might be stuck when a sourcesnapshot CRD cannot be deleted. To workaround please run kubectl edit sourcesnapshot -n v2k-system and remove all finalizers
224545749: Linux system container extraction step getting stuck in some scenarios.
March 28, 2022
Replatform Websphere applications to containers
Version 1.11 introduces a new public offering for replatforming VMs based on WebSphere applications into containers using tWAS (traditional WebSphere Server) container image or Open Liberty community images. Migrate for Anthos and GKE now enables: * Detecting VMs that host WebSphere servers * Discovering WebSphere applications using the IBM binary scanner tool * Splitting the applications into individual containers to increase agility in deployment and operation management * Generating docker file, deployment spec and other artifacts that support deployment to Google modern application platforms and Day2 operations.
Migrate for Compute Engine v5.0 as a migration support
Currently, Migrate for GKE and Anthos uses Migrate for Compute Engine 4.X to enable workload migration from VMWare on-premise, AWS EC2, and Azure VM environments to Google Cloud. To simplify setup and elevate the operator experience migrating from inventories in these environments, we now offer using the new Migrate for Compute Engine v5.X managed service. This new integration is now in public preview. For more information, see Enabling Google services and configuring service accounts.
Migrate for Compute Engine v5.0 as a migration support
Currently, Migrate for GKE and Anthos uses Migrate for Compute Engine 4.X to enable workload migration from VMWare on-premise, AWS EC2, and Azure VM environments to Google Cloud. To simplify setup and elevate the operator experience migrating from inventories in these environments, we now offer using the new Migrate for Compute Engine v5.X managed service. This new integration is now in public preview. For more information, see Enabling Google services and configuring service accounts.
In-place migration on Anthos Bare Metal Clusters
Support has been added for implementing Anthos clusters on Bare Metal as processing clusters to perform migrations for on-premise workloads. This public preview offering will serve customers who would like to deploy on-premises workloads on Anthos Bare Metal clusters allowing the migration to containers to take place on-premise as well. For more information see, Configuring a processing cluster on Anthos on Bare Metal.
Replatform Tomcat applications to containers enhancements
The Tomcat application replatforming flow now enables you to manually specify a Tomcat server installation directory before the migration. This allows you to override the related automatic discovery in cases where you know and would like to provide an exact location. For more information see, Adding a target project.
Building and deploying containers with Skaffold
Skaffold yamls generated as part of the migration artifacts for Tomcat, WebSphere and Linux system container flows now help you to accelerate container image builds and deployments to GKE and Anthos clusters
Splitting IIS sites into individual containers
Previously to break down N discovered IIS sites into individual containers, you had to manually edit the migration plan to include one site at a time and generate containers artifacts N times. This new feature enables automatic breakdown of N discovered sites into N individual containers in one iteration through a parameter on the migration plan. For more information, see Split a single VM into multiple containers.
208040681: Resolved operating system field 'disappearing' after running guest level discovery.
194186514: Resolved migrations done in Anthos on AWS might succeed even though the files were not uploaded.
216537540: migctl cannot be used to upgrade the Migrate installation newer than the migctl version. For example, if migctl is version 1.9.0, it cannot upgrade a cluster to 1.11.0.
204879458: If image repository permissions are invalid, the migration will get stuck in the ExtractImage step instead of the UploadImage step
223553376: Secrets created by migctl, for example when creating a source provider, may not always be cleaned up when the objects that depend on them are deleted. For example when issuing migctl source delete.
January 08, 2022
Windows connection strings
Migrate for Anthos and GKE supports connection strings at the site and global scopes. See Setting connection strings for a data provider for more information.
Reducing system container image size
New alerts have been added to the migration plan to alert you when files may be too large for a successful image. See Specifying content to exclude from the migration for more information.
211625398: GKE 1.22 support
December 22, 2021
Security updates
1.10.1 Security updates available. See Upgrading Migrate for Anthos and GKE for upgrade instructions.
December 08, 2021
Replatform Tomcat applications to containers
Version 1.10 introduces a new public offering for replatforming VMs based on Tomcat applications into containers using Apache Tomcat OSS community images. Migrate for GKE now enables: * Detect VMs that host Tomcat web servers and indicate their fit level for containerization. * Discover Tomcat applications as part of the migration processing and their breakdown into individual containers over the Tomcat community images.
See Migrating Tomcat Workloads Migrating Tomcat Workloads.
Fit assessment of AWS EC2 workloads
The fit assessment tool now supports assessments of AWS EC2 workloads by running the collection scripts directly on the assessed AWS EC2 VM, or through a remote SSH from the CLI. The new assessment feature enables users to inspect their workload for automated containerization to GKE, GKE AutoPilot and Cloud Run using Migrate For Anthos and GKE.
Migrate to GKE Autopilot clusters and Cloud Run now in GA
Simplified Linux service manager, which lets you deploy containers to GKE Autopilot clusters and to Cloud Run, is now the default service manager for any migrations performed with Migrate for Anthos and GKE.
See Migrating to Autopilot clusters and Cloud Run for more on these new features.
Assessment of workloads for Shift to Google Compute Engine
Added support for assessing Lift & Shift migrations to Google Compute Engine. The fit assessment tool is enhanced with additional assessment capabilities which can indicate a VM's fit score toward a Lift & Shift migration using Migrate for Compute Engine. The fit assessment report provides users recommended actions based on conditions that can impact automated migration. With the advanced details users can choose the best workloads for migration and fix issues before they impact the automated migration process.
Using RVTools output as a data source for fit assessment
The fit assessment tool now supports analyzing the RVTools .xlsx report file from a single VMware vCenter by running $./mfit discover rvtools name.xlsx. RVTools utilities are used to retrieve VMWare VSphere management data. With the RVTools data source users can easily generate detailed fit assessment reports based on their existing RVTools export.
Assessment for containerization on GKE Auto Pilot
The fit assessment tool now supports assessments of workloads for containerization to GKE Auto Pilot - A new mode of operation in Google Kubernetes Engine (GKE) that is designed to reduce the operational cost of GKE clusters. The new assessment capability allows users to inspect their workloads for automated containerization to GKE Auto Pilot using Migrate for Anthos and GKE.
Using RVTools output as a data source for fit assessment
The fit assessment tool now supports analyzing the RVTools .xlsx report file from a single VMware vCenter by running $./mfit discover rvtools name.xlsx. RVTools utilities are used to retrieve VMWare VSphere management data. With the RVTools data source users can easily generate detailed fit assessment reports based on their existing RVTools export.
Assessment for containerization on Cloud Run
The fit assessment tool now supports assessments of workloads for containerization to Google Cloud Run - A Google cloud fully managed serverless platform. The new assessment allows users to inspect their workloads for automated containerization using Migrate for Anthos and GKE.
Assessment of workloads for Shift to Google Compute Engine
Added support for assessing Lift & Shift migrations to Google Compute Engine. The fit assessment tool is enhanced with additional assessment capabilities which can indicate a VM's fit score toward a Lift & Shift migration using Migrate for Compute Engine. The fit assessment report provides users recommended actions based on conditions that can impact automated migration. With the advanced details users can choose the best workloads for migration and fix issues before they impact the automated migration process.
Fit assessment of Google Compute Engine VM workloads
The fit assessment tool now supports assessment of Google Compute Engine VM workloads by running the collection scripts directly on the assessed Google Compute Engine VM, or through a remote SSH from the CLI. The new assessment feature enables users to inspect their workload for automated containerization to GKE, GKE AutoPilot and Cloud Run using Migrate For Anthos and GKE.
190704603: Change to mFIT CLI Help text - 'Import collector script artifacts'.
205159086: On newer Ubuntu versions migrated workloads will fail.
199382909: Data migration plans will not have comments when using the UI.
205159324: Fixed a bug where services-config.yaml was not created even when the migration completed successfully in the new Linux system container runtime.
190575888: Design updates to mFIT HTML report, fonts changes, layout bugs and graphs position on report.
206772515: Fixed a bug where ** in a v2kServiceManager log path was not supported.
194186514: Migration done in Anthos on AWS might succeed even though the files were not uploaded.
Uninstall might be stuck when a sourcesnapshot CRD cannot be deleted. To workaround please run kubectl edit sourcesnapshot -n v2k-system and remove all finalizers
204879458: If your image repository permissions are invalid, migration will get stuck in ExtractImage instead of the UploadImage step.
208040681: Operating system field 'disappears' after running guest level discovery.
October 05, 2021
Fit assessment tool now in GA
The migration fit assessment tool has moved from the Public Preview to General Availability. The migrate fit assessment tool helps users assess their workloads' fit for containerization. The provides users with detailed technical insights and a fit score per workload. The HTML fit assessment report enables users to easily share assessment data offline. The JSON file report allows them to view their assessment directly on the cloud console.
Containerize to GKE Autopilot and GKE Cloud Run now in GA
Adding non-privileged lightweight system init with a simplified Linux service manager has moved from the Public Preview stage to General Availability. This feature allows you deploy containers to GKE Autopilot clusters as well as to Cloud Run. The new non-privileged system init replaces the previous design, which was based on nested containers, with a new system init based on Linux Containers (LXC) that has a smaller footprint.
198092293 [MFIT] vSphere level <-> guest level data correlation failure with certain NIC configurations.
197206783 [MFIT] Fixed failure to run guest collect script via SSH with a non-root remote user.
194605214 Use controller storage by default for pod log collection for logging migration tasks. Setup max log file size and file rotation.
197432816 [MFIT] More granular assessment of supported Windows versions.
August 17, 2021
Added support for specifying connection strings when migrating a Windows workload. Connection strings define a connection from the migrated container workload to a .NET Framework data provider.
See Setting connection strings for a data provider for more.
166014117 : The documentation has been updated to describe how to delete the migration to free up the source VM after a successful migration. See Deleting a migration for more.
171686793: The migctl setup upgrade --gkeop command no longer creates a new ImageRepositiry or ArtifactRepository object that lacked Google Cloud access credentials.
Version 1.8 added the initial support for the preview release of the fit assessment tool. The fit assessment tool for version 1.8.1 adds new functionality, including:
- Ability to collect data for a Windows VM
- Ability to remotely collect data for Linux and Windows VMs using VMware tools
- Ability to remotely collect data over SSH
See Using the fit assessment tool for more.
The cos-runtime option to the migctl setup install command has been renamed to runtime.
179028669: migctl doctor no longer crashes if a GKE cluster is currently repairing.
183564181: When you call migctl setup upgrade on Anthos clusters on VMware or Anthos clusters on AWS without the necessary platform argument (--gkeop or --gke-on-aws), migctl no longer uninstalls Migrate for Anthos and GKE.
179171930: A migrated container workload can now be deployed to a cluster running GKE 1.20 and later.
Before you run your migrated workloads, you must install migctl with runtime support for Container-Optimized OS nodes on your cluster:
migctl setup install --runtime
See Deploying a Linux workload to a target cluster for more information.
When you generate the migration artifacts, Migrate for Anthos and GKE now generates the new logs.yaml file from the migration plan. This file contains the list of log files detected on the source VM. You can now edit the logs.yaml file to configure logging and the data written to Cloud Logging.
See Customizing log data written to Cloud Logging for more.
183082390: The collection script used by the Linux discovery tool uses service --status-all to query system V services. This call no longer takes an arbitrary amount of time to return.
194186514: When using Anthos clusters on AWS as the processing cluster to perform migrations of AWS workloads, if you have insufficient credentials to create an ECR repository, sometimes the migration succeeds. However, the ECR repository is not created.
Workaround: Update your credentials, then recreate and retry the migration.
197206783: The user credentials passed to the mfit discover ssh ... command must be the credentials of the root user on the VM. Running the command as a non-root user executes the command successfully, but only collects a small part of the data required for a full assessment.
197206783: The user credentials passed to the mfit discover ssh ... command must be the credentials of the root user on the VM. Running the command as a non-root user executes the command successfully, but only collects a small part of the data required for a full assessment.
June 29, 2021
179976237: You can now create a Docker image file registry configuration with the name of a previously deleted configuration.
166014117 : If you are using Migrate for Compute Engine with Migrate for Anthos and GKE to migrate Linux workloads, after you complete a successful migration, delete the migration to free up the source VM.
Enhanced runtime support added which lets you deploy containers to GKE Autopilot clusters and to Cloud Run, and simplifies the process of deploying containers to Anthos clusters on AWS that use workload identity. This feature is in preview.
See Enhanced runtime for more.
179171930: A migrated container workload cannot be deployed to a cluster running GKE 1.20 and later.
Added support for the preview release of the fit assessment tool that is intended to eventually replace the existing Linux discovery tool. The new fit assessment tool provides you with:
- Ability to get the inventory information about VMware VMs through direct connection to vCenter.
- Enhanced HTML output that makes it easier to view the assessment results.
- New collection script,
mfit_linux_collect.sh, and new assessment tool,mfit.
See Using the fit assessment tool for more.
187922406: A migration might fail due to a LVM (Logical Volume Manager) failure.
Workaround: Recreate and retry the migration.
187922406: A migration might fail due to a LVM (Logical Volume Manager) failure.
Workaround: Recreate and retry the migration.
May 19, 2021
185975192: Webhook certificates no longer expire after one month. An expired certificate caused API requests to fail.
Following the Microsoft decision to end support for the Windows 10, version 1909 architecture, the Google Kubernetes Engine (GKE) team removed support for this architecture on its GKE and Anthos clusters. This change means that you must update all Windows containers built for this architecture.
When migrating Windows workloads, you have to perform the following:
If you have existing Windows containers that you created using Migrate for Anthos version 1.7 or earlier, then you have to rebuild the containers to create containers capable of running on supported Windows architectures.
If you are currently using Migrate for Anthos to migrate Windows workloads, you must update your Migrate for Anthos processing clusters to use version 1.7.5 and update the node pools to use the supported Windows architecture.
Rebuild deployed Windows containers
If you have existing Windows containers created using Migrate for Anthos version 1.7 or earlier, rebuild the container to use a supported Windows architecture. You require the generated artifacts folder generated for the container to make this change:
At the top of the Dockerfile in the generated artifacts folder, edit the
FROMcommand to update the image.For example, for the following
FROMcommand:FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore:1909Replace the image as shown below:
FROM mcr.microsoft.com/windows/servercore/iis:latestThe following table shows the existing image and the image used to replace it:
| Existing image name | New image name |
|---|---|
| mcr.microsoft.com/windows/servercore:1909 | mcr.microsoft.com/windows/servercore/iis:latest |
| mcr.microsoft.com/windows/servercore/iis:windowsservercore-1909 | mcr.microsoft.com/windows/servercore/iis:latest |
| mcr.microsoft.com/dotnet/framework/aspnet:3.5-windowsservercore-1909 | mcr.microsoft.com/dotnet/framework/aspnet:3.5 |
| mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-1909 | mcr.microsoft.com/dotnet/framework/aspnet:4.8 |
| mcr.microsoft.com/dotnet/framework/wcf:4.8-windowsservercore-1909 | mcr.microsoft.com/dotnet/framework/wcf:latest |
- Rebuild the container images as described at Building the container image.
Update your Migrate for Anthos processing clusters
If you are currently using Migrate for Anthos to migrate new Windows workloads, you must update your version of Migrate for Anthos to 1.7.5 and update your processing cluster to use a node pool of type WINDOWS_LTSC. Node pools of type WINDOWS_SAC are no longer supported.
To update your processing cluster:
On your processing cluster, replace the
WINDOWS_SACnode pool withWINDOWS_LTSC.Add the
WINDOWS_LTSCnew pool:--project=project-name --zone=gcp-zone --cluster=cluster-name \ --image-type=WINDOWS_LTSC --num-nodes=1 --scopes="cloud-platform" \ --machine-type=n1-standard-4```
Delete the
WINDOWS_SACnode pool:Note: You can determine the name of the node pool that each node in your cluster belongs to, as well as the name of the node
s architecture, by runningkubectl describe nodes` command while authenticated to the cluster.--project=project-name --zone=gcp-zone --cluster=cluster-name```
Removed from the legacy PV-based Migrate for Anthos versions a Webhook that was simplifying the definition of Migrate for Anthos pods. This Webhook was not being used in any subsequent versions, including the latest 1.6 and 1.7 releases.
New rule added to the Linux discovery tool to display information when multiple NICs are detected because multiple NICs can increase the effort required to migrate the workload. For a complete list of updates and information on using the new tool, see Using the Linux discovery tool.
A generated migration plan now contains entries for Service endpoints and NFS mounts discovered on the source VM. You can now edit the migration plan to add, remove, or delete these entries. See Customizing a migration plan for more.
186512095: When building a Windows container, you no longer have to edit the generated Dockerfile to change the image tag to latest.
162275866: When generating migration artifacts, you no longer see the following error:
Error: failed to update vgenerateartifactsflow.kb.io
April 06, 2021
183321483: If you are using a CRD file to create a migration source, and you include a secret in the CRD, then deleting the migration source might also delete the secret.
Workaround: Recreate the secret after deleting the migration source.
This release updates the Linux discovery tool to replace the CSV output with an HTML and JSON output. Also, the fit score of 0-10 has been replaced with a fit assessment value, new rules have been added, and more information about the source VM has been added to the report. For a complete list of updates and information on using the new tool see Using the Linux discovery tool.
183321483: If you are using a CRD file to create a migration source, and you include a secret in the CRD, then deleting the migration source might also delete the secret.
Workaround: Recreate the secret after deleting the migration source.
179028669: migctl doctor crashes if a GKE cluster is currently repairing.
Workaround: If migctl crashes, then validate that any kubectl command can run on the cluster before retrying the command.
175000470: The issue caused by adding a source when using a service account without the compute.disks.create permission has been fixed.
This release updates the Linux discovery tool to replace the CSV output with an HTML and JSON output. Also, the fit score of 0-10 has been replaced with a fit assessment value, new rules have been added, and more information about the source VM has been added to the report. For a complete list of updates and information on using the new tool see Using the Linux discovery tool.
179860971: The status error returned when you enter an incorrect VM ID in the console is not helpful:
googleapi: got HTTP response code 404 with body:
Workaround: View the error in the Events tab in the console for more information:
Click the Migrations tab to display a table containing the available migrations.
In the row for the desired migration, select the migration Name to open the Details tab.
Select the Events tab.
178469863: Running migctl setup install with either the --node-selector or --tolerations flag no longer returns an error.
156207267: When using Anthos clusters on VMware for your processing cluster, the migration might get stuck at the image extraction step, and the relevant migration pod shows volume attachment errors similar to the following:
Warning FailedAttachVolume 5s (x10 over 4m15s)
attachdetach-controller AttachVolume.Attach failed for volume migration-b849e1-dd:
Invalid configuration for device 0.
The issue is triggered by a Kubernetes in-tree vsphere driver that is unable to cleanup leftovers from previous migration operations on the same node.
Workaround: Either:
Cordon the affected node by:
- Running the following command:
kubectl cordon [node_id]- Restarting the migration.
Restart the affected node.
182208300: When building a Docker image for a Windows container, examine the logs. Sometimes an internal step can fail, even when the build command shows that the build was successful.
183082390: The collection script used by the Linux discovery tool uses service --status-all to query system V services. Depending on the services installed on the VM, service --status-all might call custom routines. In some cases, this call might take an arbitrary amount of time depending on the services installed.
By default, Migrate for Anthos automatically disables unneeded services on a VM when you migrate it to a container. You can now edit the migration plan to optionally disable additional services on the container, either services discovered by Migrate for Anthos or your own list of services. See Customizing a migration plan for more.
After completing the installation of Migrate for Anthos, run the following command to apply a required patch:
kubectl patch mutatingwebhookconfigurations.admissionregistration.k8s.io controllers-mutating-webhook-configuration --type json --patch '[{"op": "remove", path: "/webhooks/9"}]'
179171930: This release of Migrate for Anthos does not support GKE 1.20.
Workaround: Use GKE 1.19 or earlier.
183564181: When you call migctl setup upgrade on Anthos clusters on VMware or Anthos clusters on AWS without the necessary platform argument (--gkeop or --gke-on-aws), migctl uninstalls Migrate for Anthos and fails on the install.
Workaround: Rerun migctl setup upgrade with the correct argument.
February 23, 2021
180576558: Fixed an issue where the Linux discovery tool calculated an incorrect score.
180576558: Fixed an issue where the Linux discovery tool calculated an incorrect score.
February 01, 2021
Released a fix, rolling out gradually and taking full effect 2/5/2021, for a migctl crash when kubectl is not in PATH.
Released a fix, rolling out gradually and taking full effect 2/5/2021, for a migctl setup
installation that fails on a GKE cluster when the automatically created bucket
already exists.
January 25, 2021
174655315: A migration might stop responding when generating artifacts and remain in the retrying state. You might also see this error in the logs or in the verbose migration status:
D 2020-12-01T18:43:53Z SHELL ERROR: '2020/12/01 18:43:53 appending [/tarlayer/layer.tar.gz]: reading tar "/tarlayer/layer.tar.gz": flate: corrupt input before offset 681999708'
Workaround: Re-run migctl migration generate-artifacts.
174299021: When creating a migration source or executing a migration, you might see this error:
"Error: Internal error occurred: failed calling webhook "vmigration.kb.io": Post https://controllers-webhook-service.v2k-system.svc:443/validate-anthos-migrate-cloud-google-com-v1beta2-migration?timeout=30s: unexpected EOF"
Workaround: Recreate the source or migration.
171686793: The migctl setup upgrade --gkeop command might create a new ImageRepositiry or ArtifactRepository object that lacked Google Cloud access credentials.
Workaround: Use the following command to upgrade the cluster:
migctl setup upgrade --json-key key
Where key is the JSON key for the service account required for migctl installation. See Configuring service accounts.
If you delete the configuration for a Docker image file registry, create a new one with a different configuration name. You cannot recreate a configuration with the name of a previously deleted configuration.
This issue affects Docker image file registries implemented by using GCR or by using Docker registries using basic auth. It does not affect ECR. See Defining data repositories for more information.
Workaround: Use the migctl docker-registry update command to modify an existing configuration rather than deleting it and recreating it.
174299021: When creating a migration source or executing a migration, you might see this error:
"Error: Internal error occurred: failed calling webhook "vmigration.kb.io": Post https://controllers-webhook-service.v2k-system.svc:443/validate-anthos-migrate-cloud-google-com-v1beta2-migration?timeout=30s: unexpected EOF"
Workaround: Recreate the source or migration.
172414359: Exporting multiple cloned VMs simultaneously from the same source might fail.
Workaround: Re-run the migctl migration generate-artifacts command again.
If you delete the configuration for a Docker image file registry, create a new one with a different configuration name. You cannot recreate a configuration with the name of a previously deleted configuration.
This issue affects Docker image file registries implemented by using GCR or by using Docker registries using basic auth. It does not affect ECR. See Defining data repositories for more information.
Workaround: Use the migctl docker-registry update command to modify an existing configuration rather than deleting it and recreating it.
Support added for using Anthos clusters on AWS as processing clusters to perform migrations of AWS workloads. This feature is in preview. See Prerequisites for migrating Linux VMs on AWS for more.
If you try to mount a secret on a deployed pod you will not be able to access it in /run/secrets. This is typically an issue when giving workload identity permissions to the pod (where a secret is added by Kubernetes to hold the workload identity credentials).
The contents of the secrets directory are in /kubernetes-info/secrets.
Workaround: Run the following command on the deployed pod:
ln -s /kubernetes-info/secrets /run/secrets
If the /run mount gets deleted (by a process in the pod, or by a pod reset), you might have to run the command again.
Previous releases of Migrate for Anthos required that you used Google Container Registry (GCR) and Google Cloud Storage for data repositories. This release adds support for additional repositories, including ECR, S3, and Docker registries that support basic authentication. See Defining data repositories for more.
171686793: The migctl setup upgrade --gkeop command might create a new ImageRepositiry or ArtifactRepository object that lacked Google Cloud access credentials.
Workaround: Use the following command to upgrade the cluster:
migctl setup upgrade --json-key key
Where key is the JSON key for the service account required for migctl installation. See Configuring service accounts.
174655315: A migration might stop responding when generating artifacts and remain in the retrying state. You might also see this error in the logs or in the verbose migration status:
D 2020-12-01T18:43:53Z SHELL ERROR: '2020/12/01 18:43:53 appending [/tarlayer/layer.tar.gz]: reading tar "/tarlayer/layer.tar.gz": flate: corrupt input before offset 681999708'
Workaround: Re-run migctl migration generate-artifacts.
178469863: Running migctl setup install with either the --node-selector or --tolerations flag returns an error.
Note: Running the migctl setup install command with both flags succeeds. This error only occurs when using one flag.
Workaround: Run migctl setup install without the option, and then manually add the nodeSelectors or tolerations to CSI and Controller pods. See Creating and managing cluster labels and Controlling scheduling with node taints for more.
185975192: Webhook certificates can expire after one month, causing API requests to fail.
Migrate for Anthos now includes the deployment_spec.yaml file in artifacts.zip for Windows migrations. You can use the deployment_spec.yaml file to deploy your migrated Windows workloads. See Deploying a Windows workload to a target cluster for more.
175000470: When adding a source when using a service account without the compute.disks.create permission, the source becomes ready but the migration will fail to create disks.
Workaround: Make sure that service account has the compute.disks.create permission.
In many on-prem environments, outbound internet access is tightly controlled through the use of an HTTPS proxy server. If your environment uses a proxy server to control outbound internet access, then you can now configure Migrate for Anthos to use that proxy server. See Configuring an HTTPS proxy for more.
November 16, 2020
171173082: Mistakenly creating a local VMware source on a Cloud-based cluster,
normally used only in an on-prem migration, no longer
results in the source being in PROCESSING state forever but instead returns an error.
169919740: When using a custom services blocklist to disable a service in a workload, if the service was already disabled by default, the migrated container no longer can crash when deployed.
170604382: Running migctl when not connected to a cluster
no longer results in a panic error, but instead returns an error message describing the issue.
171173082: Mistakenly creating a local VMware source on a Cloud-based cluster,
normally used only in an on-prem migration, no longer
results in the source being in PROCESSING state forever but instead returns an error.
170618192: Similarly to Linux migrations, Windows migrations now add to the generate artifacts object an annotation containing the migration spec and comments.
October 08, 2020
Support for migrating Windows VM workloads has moved from the Beta stage to general availability.
This release adds full support for migrating Windows VM workloads to the Google Cloud Console, including the ability to create a Windows migration source. See Migrating a Windows VM for more.
Custom Services Blocklist support added which lets you define a list of services to disable in a migrated container. See Custom Services Blocklist for more.
Migrate for Anthos provides tools that you run on a Linux or Windows VM workload to determine the workload's fit for migration to a container. See Using the Linux discovery tool and Using the Windows discovery tool for more.
163800225: kubectl port-forward might not work properly for a deployed workload.
Please contact support for more information.
170706786: The Linux Discovery Tool might return exit code 0 even when all information was collected successfully.
Workaround: Make sure you run the tool as a 'root' user or as a user with full sudo access.
163800225: kubectl port-forward might not work properly for a deployed workload.
Please contact support for more information.
171714535: In a GKE on-prem environment configured to use an egress HTTP/HTTPS proxy, the migration process might get stuck.
Workaround: Please contact support for more information.
157062328: In some cases, adding a service to the blocklist using a configmap will not actually stop that service from running on the deployed workload.
Workaround: Disable the service using in the Dockerfile (rather than a config-map), and rebuild the image.
144896313: Migrated workloads do not support SELinux. However, if the source VM had SELinux enabled at the time of migration, and you then check the status of SELinux on the migrated workload, SELinux will appear to be enabled. This issue has no affect on migrated workloads.
171123825: In some cases, migration process might fail, and Cloud Logging indicate errors such as:
"failed to load map, error 6"
or:
"failed in domap for addition of new path sdd"
Workaround: Delete the migration and restart it. In rare cases, a re-installation of the product is required.
167656057: Installation on a GKE cluster with ACM might fail. Indication of the error can be seen in the Migrate for Anthos upgrade job, in the v2k-system namespace.
For example:
kubectl logs -n v2k-system controllers-upgrade-fzlmz
Shows this error:
failed to validate admission controller - admission webhook "validation.gatekeeper.sh" does not support dry run
Workaround:
gatekeeper is an ACM component.
Manually deleting the upgrader job fixes the issue.
For example:
kubectl delete job -n v2k-system controllers-upgrade
The image field value of the GenerateArtifactsFlow CRD defines the names and locations of two images created from a migrated VM. In previous releases, the names contained a predefined tag.
To ensure that the tag value is unique, the format of the tag has changed for this release to specify the timestamp of the migration.
You can also explicitly set the tag if you prefer to another value. See Setting the name of the container image for more.
170706786: The Linux Discovery Tool might return exit code 0 even when all information was collected successfully.
Workaround: Make sure you run the tool as a 'root' user or as a user with full sudo access.
July 28, 2020
Changed the default settings on the Cloud processing cluster for migrating Linux workloads:
You no longer have to specify the
--scopes "cloud-platform"option when creating the processing cluster.You now must create a service account, with the necessary permissions, to:
Install Migrate for Anthos
Use Compute Engine as the migration source
If you currently have a processing cluster that uses the --scopes "cloud-platform" option, your cluster will continue to work. However, for new processing clusters, you should use the new procedure. See Enabling Google services and configuring service accounts for more.
In previous releases, you used a command in the form: migctl source create ce my-ce-src --project my-project --zone zone to create a migration for Compute Engine. The --zone option has been removed when creating a Compute Engine migration. Using the --zone option in this release causes an error.
161110816: migctl migration create with a source that doesn't exist fails with a non-informative error message: request was denied.
In version 1.4, by default Migrate for Anthos installs to and performs migrations
in the v2k-system namespace. In previous release, you could specify the namespace. The option to specify a namespace has been removed.
160523841, 159106543: For Anthos GKE on-prem, in rare cases of high load, vSphere may report a failure when creating a resource even though the resource was correctly created. This may cause a snapshot or cloned VM resource leak when deleting the migration operation. The VMs or snapshots can then be manually deleted in vSphere.
You can now use the Google Cloud Console to:
- Install Migrate for Anthos on a processing cluster
- Create a migration source for a Compute Engine VM
See Installing Migrate for Anthos and Adding a migration source for more.
Added the new --json-key sa.json option to the migctl source create ce command to create a migration for Compute Engine, where sa.json specifies a service account. See Optionally creating a service account when using Compute Engine as a migration source for more.
160858543, 160836394, 160844377, 154430477, 154403665, 153241390, 153239696, 152408818, 151516642, 132002453: Unstable network in Migrate for Anthos infrastructure, or a GKE node restart, might cause migration to get stuck.
Workaround: Delete the migration and re-create it. If recreating the migration does not solve the issue, please contact support.
The migctl migration logs command has been removed. You now use the Google Console to view logs.
GKE on-prem preview: If a source was created with migctl source create using the wrong credentials, you could not delete the migration with migctl migration delete. This issue has been fixed in the GA release of on-prem support.
161110816: migctl migration create with a source that doesn't exist fails with a non-informative error message: request was denied.
153811691, 153439420: Migrate for Anthos support for older Java does not handle OpenJDK 7 and 8 CPU resource calculations.
You can now use the Google Cloud Console to:
- Install Migrate for Anthos on a processing cluster
- Create a migration source for a Compute Engine VM
See Installing Migrate for Anthos and Adding a migration source for more.
160309992: Editing a migration plan from the GUI console might fail if it was also edited using migctl.
Migrate for Anthos now includes Custom Resource Definitions (CRDs) that enable you to easily create and manage migrations using an API. For example, you can use these CRDs to build your own automated tools.
161135630: Attempting multiple migrations of the same remote VM (from VMware, AWS or Azure) simultaneously, might result in a stuck migration process.
Workaround: Delete the stuck migration.
Added the new --json-key sa.json option to the migctl source create ce command to create a migration for Compute Engine, where sa.json specifies a service account. See Optionally creating a service account when using Compute Engine as a migration source for more.
161214397: In case of a missing service-account to upload container images to the Container Registry, the migration might get stuck.
Workaround: Add the service-account. If you are using the Migrate for Anthos CRD API, delete the GenerateArtifactsTask and recreate it. If using the migctl CLI tool, delete the migration and recreate it. You can first download the migration YAML using migctl migration get to back up any customizations you have made.
You can use Migrate for Anthos to migrate Windows VMs to workloads on GKE. This process clones your Compute Engine VM disks and uses the clone to generate artifacts (including a Dockerfile and a zip archive with extracted workload files and settings) you can use to build a deployable GKE image. See Adding a Windows migration source.
In previous releases, you used a command in the form: migctl source create ce my-ce-src --project my-project --zone zone to create a migration for Compute Engine. The --zone option has been removed when creating a Compute Engine migration. Using the --zone option in this release causes an error.
Added support for Anthos GKE on-prem clusters running on VMware. On-prem support lets you migrate source VM workloads in a vCenter/vSphere environment to a GKE on-prem cluster running in the same vCenter/vSphere environment. See Migration prerequisites for the requirements for on-prem migration.
Added the node-selectors and tolerations options to the migctl setup install installation command that lets you install Migrate for Anthos on a specific set of nodes or node pools in a cluster. See Installing Migrate for Anthos.
To edit the migration plan, you must now use the migctl migration get my-migration command to download the plan. After you are done editing the plan, you have to upload it by using the migctl migration update my-migration command. See Customizing a migration plan for more.
The migctl migration cleanup command has been removed and is no longer necessary.
161104564: Creating a Linux migration with wrong os-type specification causes the migration process to get stuck until deleted.
March 30, 2020
144896313: Migration of Security-Enhanced Linux (SELinux) is not supported.
147211918: In some cases, migration from AWS or Azure as a source can be stuck with no progress. If this happens, run kubectl describe storageclass to view related events. You can also check the status of the matching Cloud Details in Migrate for Compute Engine.
149900626: Some file systems not listed in Compatible VM operating systems may fail to migrate. When running migctl migration logs migration-name, the logs in Cloud Logging may show a message such as:
failed to mount - exit status 32 - mount: /tmp/bootdir: unknown filesystem type 'LVM2\_member'.
The Migrate for Anthos software runtime layer now offers a compatibility
feature for older Java versions that are not container aware by reflecting the
correct resource allocations in the container's /proc file system.
Migrate for Anthos v1.0 Marketplace deployment is now removed. Migrate for Anthos v1.3 allows installation in v1.0 compatibility mode where needed.
151505531, 150052607: In some cases, migration can be stuck with no progress. When running migctl migration status migration-name --verbose, you might see an event such as this:
could not find attached GCE PD
Workaround: Delete the migration using migctl migration delete and re-create it.
GKE on-prem preview: If a source was created with migctl source create using the wrong credentials, migrations will fail. Attempts to delete the migration with migctl migration delete may hang in a "Terminating" state, as in the following example:
ubuntu@gke-on-prem-admin-appliance-1:~/$ ./migctl migration list
NAME PROCESS STATE STATUS PROGRESS AGE
my-vm-01 generate-artifacts createSourceSnapshots TERMINATING [2/13]
Preview features -- contact your Google Sales representative to enroll.
- Migrating Windows VMs with IIS ASP.NET web applications to Windows 2019 containers on GKE.
- Processing migrations in Anthos on-prem.
146699220: When the source VM has a systemd service with a NICE config property, the service might not start when running in a container.
Workaround: Remove the NICE property in the source VM before the migration.
Migrations are defined and operated using a Kubernetes CRD.
146699220: When the source VM has a systemd service with a NICE config property, the service might not start when running in a container.
Workaround: Remove the NICE property in the source VM before the migration.
Migrate for Anthos v1.0 Marketplace deployment is now removed. Migrate for Anthos v1.3 allows installation in v1.0 compatibility mode where needed.
148334068: When Migrating a physical VM from on-premises connected via Migrate for Compute Engine, Migrate for Anthos attempts to optimize network utilization and discards (rather than stream) blocks that are not in use on the source VM file system. In some cases, this might cause VMware storage sessions to time out. For assistance, please contact support.
The Migrate for Anthos software runtime layer now offers a compatibility
feature for older Java versions that are not container aware by reflecting the
correct resource allocations in the container's /proc file system.
Introducing a unified migration workflow across all supported VM sources -- VMware, AWS EC2, Azure VMs and Compute Engine VMs.
151505531, 150052607: In some cases, migration can be stuck with no progress. When running migctl migration status migration-name --verbose, you might see an event such as this:
could not find attached GCE PD
Workaround: Delete the migration using migctl migration delete and re-create it.
December 19, 2019
When specifying a mixed-case value for the clone_vm_disks script's -A <var>app-name</var> argument, the YAML file generated by the script would include a workload name that could not be deployed.
The command now checks for a valid input value.
Using configuration YAML from a version prior to 1.0 caused the pod to enter a crashloop stage.
An error message now is now displayed to request that you update to the latest definition.
Resolving source storage devices would sometimes fail without error if one of the devices has no partitions.
Deleting a StatefulSet attached to a persistent volume would leave the volume in an attached state./p>
Migrate for Anthos CSI drive would sometimes fail connecting to the migrated VM.
When resolving block devices in a multipath device, the operation appeared to succeed even if there was an error with one of the block devices.
The Migrate for Compute Engine password could be inadvertently logged in Stackdriver Logging.
Migrate for Anthos failed to recognize a reference to a disk specified as a PARTUUID in the fstab file. PARTUUID is now supported.
Using kubectl exec on a migration pod would sometimes display superfluous bash warnings about LC_ALL.
November 13, 2019
Using a ConfigMap, you can have content from application log files you specify written to Stackdriver Logging (a default list is included). For more, see Configuring logging to Stackdriver Logging.
Deleting a StatefulSet attached to a persistent volume will leave the volume in an attached state.
When specifying a mixed-case value for the clone_vm_disks script's -A <var>app-name</var> argument, the YAML file generated by the script includes a workload name that can not be deployed.
To work around this issue, specify the argument's value in lowercase only.
VMs using EFI configurations are not compatible for migration with this release.
VMs using EFI configurations are not compatible for migration with this release.
Resolving source storage devices would sometimes fail without error if one of the devices has no partitions.
Using kubectl exec on a migration pod sometimes displays superfluous bash warnings about LC_ALL. These are only cosmetic.
Migrate for Anthos fails to recognize a reference to a disk specified as a PARTUUID in the fstab file.
The Migrate for Compute Engine password can be inadvertently logged in Stackdriver Logging.
The kubectl cp command fails when copying files to the migrated pod.
When resolving block devices in a multipath device, the operation appears to succeed even if there was an error with one of the block devices.
On the Migrate for Compute Engine portlet in VMWare vCenter, VMs will be shown as Managed by Migrate for Compute Engine during migration process. Only the cache and storage migration status are updated in this view. Other functionality, such as Migrate for Compute Engine actions, may not be functional.
Migrate for Anthos supports migrating existing VMware, Amazon EC2, Azure, and Compute Engine VMs to containers on Google Kubernetes Engine. For more information, see Benefits of Migrate for Anthos.
For known issues and workarounds, see Troubleshooting Migrate for Anthos.
Using configuration YAML from a version prior to 1.0 causes the pod to enter a crashloop stage.
To work around this, update your YAML file to conform to the latest definition.
Migrate for Anthos CSI drive may sometimes fail connecting to the migrated VM.
You can monitor export of short-term storage to a persistent volume using kubectl. For more information, see Exporting streaming PVs to permanent storage.
Resolving source storage devices would sometimes fail without error if one of the devices has no partitions.