如果遷移至虛擬機器環境使用共用虛擬私人雲端，您必須確保已正確設定權限，才能將遷移的 VM 部署至 Compute Engine 目標專案。
舉例來說，假設您有以下環境：
專案 A - Migrate to Virtual Machines 主機專案
專案 B：共用虛擬私有雲主機專案和子網路定義
專案 C - Migrate to Virtual Machines 目標專案和共用虛擬私有雲服務專案
在本例中，您會在專案 B 中定義共用虛擬私有雲。專案 B 稱為共用虛擬私有雲主專案。
接著，您將虛擬機器遷移至 Project C 中的 Compute Engine 執行個體，也就是「遷移至虛擬機器」目標專案，Project C 會存取共用 VPC。在本例中，專案 C 稱為共用虛擬私有雲服務專案。您必須先按照「佈建共用虛擬私人雲端」一文的說明，將 Project C 設為 Project B 的服務專案，才能部署 Compute Engine 執行個體。
不過，您必須先確認專案 A 的「Migrate to Virtual Machines」預設服務帳戶具備必要權限，才能部署 Compute Engine 執行個體。具體來說，如果要遷移至虛擬機器，共用虛擬私有雲主機專案中的子網路必須具備 compute.networkUser 角色。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],null,["# Configure permissions for a Shared VPC\n\n[Shared VPC](/vpc/docs/shared-vpc) allows an organization to connect\nresources from multiple projects to a common [Virtual Private Cloud (VPC) network](/vpc/docs/vpc)\nso that they can communicate with each other securely and efficiently using\ninternal IPs from that network.\n\nWhen you use Shared VPC, you designate a project as a\n*Shared VPC host project* and attach one or more *service projects* to\nit. The VPC networks in the Shared VPC host project are\ncalled *Shared VPC networks* . [Eligible resources](/vpc/docs/shared-vpc#resources_that_can_be_attached_to_shared_vpc_networks_from_a_service_project)\nfrom service projects can use subnets in the Shared VPC network.\n| **Note:** Both Migrate to Virtual Machines and Shared VPC use the term *host* project. For Migrate to Virtual Machines, you use the *host* project to perform migrations. For Shared VPC, you use the *host* project to define the VPC network.\n\nUse Shared VPC with Migrate to Virtual Machines\n-----------------------------------------------\n\nWhen your Migrate to Virtual Machines environment uses a Shared VPC, you must\nensure that you have configured permissions correctly so that you can deploy a\nmigrated VM to the Compute Engine target project.\n\nFor example, you have the following environment:\n\n- Project A - Migrate to Virtual Machines host project\n- Project B - Shared VPC host project and subnet definitions\n- Project C - Migrate to Virtual Machines target project and Shared VPC service project\n\nIn this example, you define a Shared VPC in Project B. Project B is\nreferred to as the Shared VPC *host project*.\n\nYou then migrate a VM to a Compute Engine instance in Project C, the\nMigrate to Virtual Machines target project, where Project C accesses the\nShared VPC. In this example, Project C is referred to as the\nShared VPC *service project* . You must have already configured Project C\nto function as a service project of Project B, as described in [Provisioning Shared VPC](/vpc/docs/provisioning-shared-vpc#create-shared), before you deploy the Compute Engine\ninstance.\n\nHowever, before you can deploy the Compute Engine instance, you must also\nensure that the Migrate to Virtual Machines default service account on Project A has\nthe required permissions. Specifically, Migrate to Virtual Machines requires the\n`compute.networkUser` role on the subnetworks in the Shared VPC host\nproject.\n\nThe following section describes how to configure the Migrate to Virtual Machines\ndefault service account.\n\nConfigure the Migrate to Virtual Machines default service account\n-----------------------------------------------------------------\n\nA default service account is created on the host project during the creation of\nthe first migration, as described in [Install the Migrate Connector](/migrate/virtual-machines/docs/5.0/migrate/migrate-connector).\n\nTo deploy a Compute Engine instance to a target project that accesses a\nShared VPC, you must add the `compute.networkUser` role on the\nsubnetworks in the Shared VPC host project to the Migrate to Virtual Machines\ndefault service account. You have two options for how you add this role:\n\n- Assign the Migrate to Virtual Machines default service account to be a\n *Service Project Admin* with access to only some of the subnets in the\n Shared VPC host project. This option provides a granular means to\n define Service Project Admins by granting them the `compute.networkUser` role\n for only some subnets in the Shared VPC host project.\n\n See [Service Project Admins for some subnets](/vpc/docs/provisioning-shared-vpc#networkuseratsubnet)\n for the steps to this procedure.\n- Allow the Migrate to Virtual Machines default service account to be a\n *Service Project Admin* with access to all subnets in the Shared VPC\n host project. In this case, you grant the role of `compute.networkUser` for\n the Shared VPC host project to the Migrate to Virtual Machines default\n service account. The default service account then has access to all the\n existing and future subnets in the Shared VPC host project.\n\nTo configure the Migrate to Virtual Machines default service account for access to\n**all subnets** in the Shared VPC host project:\n\n1. Open the Migrate to Virtual Machines page in the Google Cloud console:\n\n [Go to the Migrate to Virtual Machines page](https://console.cloud.google.com/compute/mfce)\n2. Select the **Targets** tab.\n\n At the top of the page is an information box showing the email address of the\n Migrate to Virtual Machines default service account in the form:\n\n `service-`\u003cvar translate=\"no\"\u003eM4CE_HOST_PROJECT_NUMBER\u003c/var\u003e`@gcp-sa-vmmigration.iam.gserviceaccount.com`\n3. Copy the email address.\n\n4. Use that email address to grant the `compute.networkUser` role on the\n Shared VPC host project to the Migrate to Virtual Machines default service account:\n\n ```\n gcloud projects add-iam-policy-binding VPC_HOST_PROJECT_ID \\\n --member=serviceAccount:service-M4CE_HOST_PROJECT_NUMBER@gcp-sa-vmmigration.iam.gserviceaccount.com \\\n --role=roles/compute.networkUser\n ```\n\nFor more on assigning roles and permissions to a user account, see\n[Granting, changing, and revoking access to resources](/iam/docs/granting-changing-revoking-access)."]]
