Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network so that they can communicate with each other securely and efficiently using internal IPs from that network.
When you use Shared VPC, you designate a project as a Shared VPC host project and attach one or more service projects to it. The VPC networks in the Shared VPC host project are called Shared VPC networks. Eligible resources from service projects can use subnets in the Shared VPC network.
Use Shared VPC with Migrate to Virtual Machines
When your Migrate to Virtual Machines environment uses a Shared VPC, you must ensure that you have configured permissions correctly so that you can deploy a migrated VM to the Compute Engine target project.
For example, you have the following environment:
- Project A - Migrate to Virtual Machines host project
- Project B - Shared VPC host project and subnet definitions
- Project C - Migrate to Virtual Machines target project and Shared VPC service project
In this example, you define a Shared VPC in Project B. Project B is referred to as the Shared VPC host project.
You then migrate a VM to a Compute Engine instance in Project C, the Migrate to Virtual Machines target project, where Project C accesses the Shared VPC. In this example, Project C is referred to as the Shared VPC service project. You must have already configured Project C to function as a service project of Project B, as described in Provisioning Shared VPC, before you deploy the Compute Engine instance.
However, before you can deploy the Compute Engine instance, you must also
ensure that the Migrate to Virtual Machines default service account on Project A has
the required permissions. Specifically, Migrate to Virtual Machines requires the
compute.networkUser
role on the subnetworks in the Shared VPC host
project.
The following section describes how to configure the Migrate to Virtual Machines default service account.
Configure the Migrate to Virtual Machines default service account
A default service account is created on the host project during the creation of the first migration, as described in Install the Migrate Connector.
To deploy a Compute Engine instance to a target project that accesses a
Shared VPC, you must add the compute.networkUser
role on the
subnetworks in the Shared VPC host project to the Migrate to Virtual Machines
default service account. You have two options for how you add this role:
Assign the Migrate to Virtual Machines default service account to be a Service Project Admin with access to only some of the subnets in the Shared VPC host project. This option provides a granular means to define Service Project Admins by granting them the
compute.networkUser
role for only some subnets in the Shared VPC host project.See Service Project Admins for some subnets for the steps to this procedure.
Allow the Migrate to Virtual Machines default service account to be a Service Project Admin with access to all subnets in the Shared VPC host project. In this case, you grant the role of
compute.networkUser
for the Shared VPC host project to the Migrate to Virtual Machines default service account. The default service account then has access to all the existing and future subnets in the Shared VPC host project.
To configure the Migrate to Virtual Machines default service account for access to all subnets in the Shared VPC host project:
Open the Migrate to Virtual Machines page in the Google Cloud console:
Select the Targets tab.
At the top of the page is an information box showing the email address of the Migrate to Virtual Machines default service account in the form:
service-M4CE_HOST_PROJECT_NUMBER@gcp-sa-vmmigration.iam.gserviceaccount.com
Copy the email address.
Use that email address to grant the
compute.networkUser
role on the Shared VPC host project to the Migrate to Virtual Machines default service account:gcloud projects add-iam-policy-binding VPC_HOST_PROJECT_ID \ --member=serviceAccount:service-M4CE_HOST_PROJECT_NUMBER@gcp-sa-vmmigration.iam.gserviceaccount.com \ --role=roles/compute.networkUser
For more on assigning roles and permissions to a user account, see Granting, changing, and revoking access to resources.