Networking requirements

Google Cloud VMware Engine offers a private cloud environment that's accessible to users and applications from on-premises environments, enterprise-managed devices, and Google Cloud services like Virtual Private Cloud (VPC). To establish connectivity between VMware Engine private clouds and other networks, you use networking services such as Cloud VPN and Cloud Interconnect.

Some network services require user-specified address ranges to enable functionality. To help you plan your deployment, this page lists networking requirements and their associated features.

Before you begin

  • Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  • In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  • If you're using an existing project for this guide, verify that you have the permissions required to complete this guide. If you created a new project, then you already have the required permissions.

  • Verify that billing is enabled for your Google Cloud project.

  • Enable the Cloud DNS and VMware Engine APIs.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  • In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  • If you're using an existing project for this guide, verify that you have the permissions required to complete this guide. If you created a new project, then you already have the required permissions.

  • Verify that billing is enabled for your Google Cloud project.

  • Enable the Cloud DNS and VMware Engine APIs.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

    •

    Required roles

    To get the permissions that you need to complete this quickstart, ask your administrator to grant you the VMware Engine Viewer (roles/vmwareengine.vmwareengineViewer) IAM role on the project. For more information about granting roles, see Manage access to projects, folders, and organizations.

    You might also be able to get the required permissions through custom roles or other predefined roles.

    VMware Engine private cloud connectivity

    For an overview of private cloud networking, see Private cloud networking for VMware Engine.

    The connection from your VPC network to a Standard VMware Engine network uses VPC Network Peering.

    Global address resolution using Cloud DNS

    If you want global address resolution using Cloud DNS, you must complete Cloud DNS setup before you create your private cloud.

    CIDR requirements and restrictions

    VMware Engine uses set address ranges for services like hosting management appliances and deploying HCX networks. Some address ranges are mandatory and others depend on the services that you plan to deploy.

    You must reserve address ranges such that they won't overlap with any of your on-premises subnets, VPC network subnets, or planned workload subnets.

    Additionally, your workload VMs and vSphere/vSAN subnet CIDR range must not overlap with any IP addresses in the following ranges:

    • 127.0.0.0/8
    • 224.0.0.0/4
    • 0.0.0.0/8
    • 169.254.0.0/16
    • 198.18.0.0/15
    • 240.0.0.0/4

    vSphere/vSAN subnets CIDR range

    VMware Engine deploys management components of a private cloud in the vSphere/vSAN subnets CIDR range that you provide during private cloud creation. IP addresses in this range are reserved for private cloud infrastructure, and can't be used for workload VMs. The CIDR range prefix must be between /24 and /20.

    Each node in the private cloud has 5 VMkernel ports for VMware system use: ESXi management, vMotion, vSAN, NSX-T, and HCXIX. Each of these VMkernel ports consumes one IP address from the vSphere/vSAN subnets CIDR range.

    Subnets CIDR range division versions

    Private clouds created after November 2022 adhere to IP address layout (IP Plan) version 2.0 subnet allocations. Almost all private clouds created before November 2022 adhere to IP Plan version 1.0 subnet allocations.

    To find out which version your private cloud adheres to, complete the following steps:

    1. In the Google Cloud console, go to the Private clouds page.

      Go to Private clouds

    2. Click Select a project and then select the organization, folder, or project where the private cloud is located.

    3. Click the private cloud you want to review.

    4. Look for IP Plan version to find out what version this private cloud uses.

    The version number is displayed under IP Plan version.

    vSphere/vSAN subnets CIDR range size

    The size of your vSphere/vSAN subnets CIDR range affects the maximum size of your private cloud. The following table shows the maximum number of nodes you can have, based on the size of the vSphere/vSAN subnets CIDR range.

    Specified vSphere/vSAN subnets CIDR prefix Maximum number of nodes (IP Plan version 1.0) Maximum number of nodes (IP Plan version 2.0)
    /24 26 10
    /23 58 20
    /22 118 40
    /21 200 90
    /20 N/A 200

    When selecting your CIDR range prefix, consider the node limits on resources in a private cloud. For example, CIDR range prefixes of /24 and /23 don't support the maximum number of nodes available to a private cloud. Alternatively, CIDR range prefixes of /20 support more than the current maximum number of nodes available to a private cloud.

    Example management network CIDR range division

    The vSphere/vSAN subnets CIDR range you specify is divided into multiple subnets. The following tables show examples of the breakdown for allowed prefixes. The first set of examples use 192.168.0.0 as the CIDR range for IP Plan version 1.0, and the second set of examples use 10.0.0.0 for IP Plan version 2.0.

    Function Subnet mask/prefix (IP Plan version 1.0)
    vSphere/vSAN subnets CIDR range 192.168.0.0/21 192.168.0.0/22 192.168.0.0/23 192.168.0.0/24
    System management 192.168.0.0/24 192.168.0.0/24 192.168.0.0/25 192.168.0.0/26
    vMotion 192.168.1.0/24 192.168.1.0/25 192.168.0.128/26 192.168.0.64/27
    vSAN 192.168.2.0/24 192.168.1.128/25 192.168.0.192/26 192.168.0.96/27
    NSX host transport 192.168.4.0/23 192.168.2.0/24 192.168.1.0/25 192.168.0.128/26
    NSX edge transport 192.168.7.208/28 192.168.3.208/28 192.168.1.208/28 192.168.0.208/28
    NSX edge uplink1 192.168.7.224/28 192.168.3.224/28 192.168.1.224/28 192.168.0.224/28
    NSX edge uplink2 192.168.7.240/28 192.168.3.240/28 192.168.1.240/28